Arch Linux User Repository

I made a patch[1] to this repo to get it building again on the latest kernels.

[1] https://gist.github.com/SeamusConnor/90394a58cdc1d30c396a1c43f206768e

I guess they will fix it upstream. Meanwhile i suggest you to use linux-lts.

Please add patches for kernel 5.6

https://github.com/dm-vdo/kvdo/issues/29#issuecomment-592686755

Kernelswitching is a good point, hadn't that in mind. With the next upstreamrelease i will apply the patch unconditionally.

@zapp-brannigan Thanks for integrating that! It works great, though with a caveat:

You're conditionally applying the patch and printing the warning in the PKGBUILD package() function based on the config of whichever kernel is running at the time of packaging. And because this is a DKMS package, one copy of the source code is installed in /usr/src/, which is then later compiled for potentially all the different kernels that a user may have installed on their system.

So, as an example, if a user happens to have booted with linux-lts and builds the package at that time, then they won't get the warning message, and the module source code installed to the system won't have the patch. So if that user also has stock linux installed and decides to reboot into that, they won't have a working kvdo module: the DKMS build for that kernel will fail / have failed.

The best course of action, I think, would be to apply the patch unconditionally (seeing as it has no effect on the other CONFIG_HZ values anyway). And then maybe see if there's an easy way to move the warning message into the DKMS config file, or perhaps one of the Makefiles, or something like that, such that it gets printed at the time of dkms build / dkms install. (Or maybe just leave the warning in package(), print it unconditionally, and trust that users will take note of it if they believe it concerns their setup.)

But anyway. For the simple case of always booting with the stock linux kernel, and running the makepkg for this while running under that kernel, the package does currently do basically the right thing.

Updated the pkgbuild. @jgottula maybe you can test it (i'm on linux-lts...)?

The build problem with the stock Arch Linux kernel is 100% due to the stock Arch kernel config using CONFIG_HZ=300.

This kernel module currently does some timing calculations (for histograms etc) assuming on an integer number of jiffies-per-millisecond (i.e. ticks per millisecond)... and it just so happens that 1000 does not divide evenly by 300. (CONFIG_HZ=100, =250, =1000 are all fine because those do divide evenly: 10, 4, 1 jiffies-per-ms respectively.)

In the upstream bug thread regarding this exact problem, it's mentioned that this is a temporary limitation that should be fixed in an upcoming version, hopefully relatively soon. (And in fact, there are also a few places in the code itself where it's mentioned that an assumption is being made which won't necessarily be true for all kernel configs, and that that needs to be fixed up.)

In addition, that thread provides a recommended workaround for the build failure: simply remove or comment-out the STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0); line (vdo/kernel/histogram.c:600), and then the module will no longer fail to build against CONFIG_HZ=300 kernels. With this workaround, the histogram and timing stats will be slightly skewed on CONFIG_HZ=300 kernels: the calculations will assume that tick intervals are 4ms long, rather than the actual 3.33ms, since the jiffies_to_msecs function in the kernel rounds up when a strictly-integral division result isn't possible. But the real core functionality of the kernel module won't be adversely affected at all.

Given the above, I'd suggest that the best course of action for now (until the upstream devs get around to fixing their integer problem) would be to add a patch to this package that implements the workaround described above (i.e. removing the problematic STATIC_ASSERT line). Then, at least users of the stock Arch kernel (or any other kernel with CONFIG_HZ=300 set, for that matter) will be able to actually build and use this package (albeit with a 20% inflation of the reported timing stats relative to what they should be, due to the 4ms-vs-3.33ms discrepancy). And then, when the upstream devs do finally decide to fix their code, we can ditch the patch at that point.

(Maybe we could even throw in a warning message as the package builds to inform the user about the side-effect on the reported timings they will get if they are building for a CONFIG_HZ=300 kernel, if we wanted to be super-duper-thorough.)

Thoughts? @zapp-brannigan

I'm 99% sure it's related to the CONFIG_HZ kernel config, to fix the build issue compile linux-ck with CONFIG_HZ=1000 or use linux-zen where it is the default.

but it builds fine against 4.19.92-1-lts (my backup kernel) ;)

i just ran into another problem against kernel 5.4.7-arch1-1 (x86_64):

  LD [M]  /var/lib/dkms/kvdo/6.2.2.24/build/uds/uds.o
In file included from /var/lib/dkms/kvdo/6.2.2.24/build/vdo/../uds/memoryAlloc.h:30,
                 from /var/lib/dkms/kvdo/6.2.2.24/build/vdo/kernel/histogram.c:24:
/var/lib/dkms/kvdo/6.2.2.24/build/vdo/kernel/histogram.c: In function ‘makeLogarithmicJiffiesHistogram’:
/var/lib/dkms/kvdo/6.2.2.24/build/vdo/../uds/permassert.h:114:5: error: duplicate case value
  114 |     case expr:              \
      |     ^~~~
/var/lib/dkms/kvdo/6.2.2.24/build/vdo/kernel/histogram.c:600:3: note: in expansion of macro ‘STATIC_ASSERT’
  600 |   STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);
      |   ^~~~~~~~~~~~~
/var/lib/dkms/kvdo/6.2.2.24/build/vdo/../uds/permassert.h:113:5: note: previously used here
  113 |     case 0:                 \
      |     ^~~~
/var/lib/dkms/kvdo/6.2.2.24/build/vdo/kernel/histogram.c:600:3: note: in expansion of macro ‘STATIC_ASSERT’
  600 |   STATIC_ASSERT((MSEC_PER_SEC % HZ) == 0);
      |   ^~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:265: /var/lib/dkms/kvdo/6.2.2.24/build/vdo/kernel/histogram.o] Error 1