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
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.
ReplyDeleteUnfortunately, 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
Compilation fails at bfs_debug.c if CONFIG_SCHED_DEBUG=n is set.
ReplyDeleteThe quick fix for this issue would be
Deletediff --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
endif
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
else
obj-y += core.o loadavg.o clock.o cputime.o
obj-y += idle_task.o fair.o rt.o deadline.o stop_task.o
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.
ReplyDeleteFor now, really sticking to vanilla kernel to test it at least for one week to find out what causes such hangs.
@pf
DeleteIt 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
Having the same issues with it hanging after using it for some time.
Delete@All
DeleteOnce @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
Vanilla 4.5.4 uptime is 8+ days now, and I'm going to switch to -ck1 (without VRQ) to test it as well.
Delete@pf
Delete-ck1 would be a good start point. If -ck1 goes well, please checkout the -gc commits till this commit(https://bitbucket.org/alfredchen/linux-gc/commits/8b909533684d5f5f6549902f73508f58c4b62dee?at=linux-4.5.y-test), 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
Quite sad news above. :-( But maybe by this lengthy way you're able to pin down and fix the underlying issue.
DeleteOn 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