Wednesday, May 18, 2016

Pre-release of v4.6_0469_vrq0 patch

Pre-release of v4.6_0469_vrq0 patch is available now.

It is the first BFS/VRQ patch for kernel 4.6, a few things haven't been done yet, including the cpufreq_util adaptation in BFS and some possible enhancement during 4.6 sync-up, which will require more time to be completed.

Again, there is no new changes comparing to the v4.5 vrq branch, just the sync-up code for v4.6.

Time to have fun with 4.6 kernels. :)

BR Alfred


  1. At first: Also this patch works for me, no issues when compiling, kernel boots up and seems to work under KDE as fine as the VRQ0 for 4.5.

    Unfortunately, the other patch-makers aren't as fast as Alfred. My patch combination for this test:
    * Paolo Valente called the 4.5 related patches to be safe on 4.6, included
    * Slightly modified writeback patches from postfactum's pf-4.5 included
    * I even managed to adapt my earlier mentioned & linked '4.3.3 TuxOnIce for 4.5.3' for 4.6, but utterly failed with the changed crypto funtions, as I lack programming knowledge. So this adaption only works with TOI's checksumming disabled. But then it works.

    @Alfred: I hope you haven't omitted too many "possible enhancements" for 4.6 and am looking forward to the coming improvements on 4.6 VRQ and VRQtest.

    BR Manuel Krause

  2. Compilation fails at bfs_debug.c if CONFIG_SCHED_DEBUG=n is set.

    1. The quick fix for this issue would be

      diff --git a/kernel/sched/Makefile b/kernel/sched/Makefile
      index ba86992..d120d39 100644
      --- a/kernel/sched/Makefile
      +++ b/kernel/sched/Makefile
      @@ -16,7 +16,8 @@ CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer

      ifdef CONFIG_SCHED_BFS
      -obj-y += bfs.o bfs_debug.o clock.o
      +obj-y += bfs.o clock.o
      +obj-$(CONFIG_SCHED_DEBUG) += bfs_debug.o
      obj-y += core.o loadavg.o clock.o cputime.o
      obj-y += idle_task.o fair.o rt.o deadline.o stop_task.o

  3. Unfortunately, this also hangs for me after several days of using, and disabling NMI watchdog did not help — I simply do not get anything via netconsole.

    For now, really sticking to vanilla kernel to test it at least for one week to find out what causes such hangs.

    1. @pf
      It seems that it will take your some time to find out the cause.
      I remember that you said there is no such issue at 4.4 VRQ, is that correct?

      BR Alfred

    2. Having the same issues with it hanging after using it for some time.

    3. @All
      Once @pf had confirmed that the hang issue is related to BFS/VRQ, I will start the process to find out the cause. It maybe a long way to archive the cause considering the time to reproduce the issue. So, be patience. :)

      BR Alfred

    4. Vanilla 4.5.4 uptime is 8+ days now, and I'm going to switch to -ck1 (without VRQ) to test it as well.

    5. @pf
      -ck1 would be a good start point. If -ck1 goes well, please checkout the -gc commits till this commit(, this excludes the major VRQ features. This two steps all most costs 2 weeks to verify.
      At the same time, as my 7*24 server run well with VRQ kernel, the only unstable issue in my known list was VRQ kernel on raspberry pi(which hangs after about 1 days uptime, so it still runs on 4.1-gc kernel), I will set up another system for the rpi2 for VRQ kernel testing, this most updated official kernel is at v4.4.x as I checked last week. It's a long shot but hopefully fixing the issue on arm arch also help with x86 arch.

      And @pf, would you please email me your kernel config file and the crash dmesg log? I could also try to adapter your kernel config to my 7*24 server and try to reproduce the issue.

      BR Alfred

    6. Quite sad news above. :-( But maybe by this lengthy way you're able to pin down and fix the underlying issue.

      On my machine I had the 4.5.5 +VRQ0 +BFQ +my 4.3.3 TOI port running very well for 5+ days, until I decided to reboot (due to unrelated software updates).

      I wish good luck to both of you, and BR,
      Manuel Krause