I was anxious to try out the new Zen kernel with the BFQ IO scheduler enabled as the last few versions did not have the patch set available, but previously it did. I compiled my kernel using my previous config with the only change being to enable the BFQ scheduler. The kernel and modules seemed to build and install fine, but booting off new kernel proved impossible as the kernel panicked. After reading the changelog I noticed that there must have been a second version released today correcting an error from earlier as it read "fixed bfq patch not applying properly" So I waited a few hours resynced portage, then re-emerged zen-sources-2.6.34_p1-r1 thinking that maybe the mirror wasn't up to date when I emerged. Compiled and installed kernel using the freshly emerged sources, but again kernel panicked while booting. I'm on a ~x86 laptop Results are repeatable
Created attachment 238073 [details] .config from my running kernel (without BFQ enabled) I tried again last night but with the same results. Kernel appears to panic while detecting my drives. I'm attaching my kernel .config from my running kernel (without BFQ the scheduler) I hope this helps.
We need an exact message just before the kernel panic. You could write it down or take a photo?
(In reply to comment #2) > We need an exact message just before the kernel panic. You could write it down > or take a photo? > I'll try and take a photo later (screen capture is impossible). It panics while detecting my drives, but before the RC startup process is started. If I'm not mistaken the last line before crashing mentions my DVD/Burner (an NEC 6650A). Then it locks up tighter than a drum. Compiling using the exact same sources, but without enabling BFQ I get no negative verbose output at all and it boots up perfectly. As I mentioned, I'll try to get back with a photo. Today is a busy day (World Cup) and working on my motorcycle. Please note that with previous Zen-sources that had BFQ scheduler I was able to enable without any issues. So this a new bug, or configuration error. Perhaps there is an additional kernel option that now needs to be activated for it to work properly? My config has been posted above as an attachment. TIA
(In reply to comment #3) Was bfq the default scheduler in the config that let your kernel panic? If so, set another scheduler as the default and check if the kernel boots successfully. If it does not panic, switch to bfq for each of your drives and see what happens (possibly stress the drives a little bit, with e.g. an ls -lR /). Instead, if bfq was not the default scheduler, the photo is probably the only solution. In fact, apart from a trivial init, in this case bfq's code is not executed at all.
You could try to apply the bfq patches on vanilla-sources-2.6.34 and see if it fails as well
FIX / TEST-REQUEST The cause of the panic was probably the following: as an additional check, bfq controls whether the lock on the device queue has been taken when it is asked to insert a new request. Before the fix, bfq did it through a BUG_ON on the return value of the spin_is_locked function. Unfortunately this function returns always false if CONFIG_SMP is not set (as in the config files of the two guys reporting the oops). This caused the BUG_ON to deceptively fire. I replaced the BUG_ON with a call to assert_spin_locked, which should work with any configuration. I just updated all the faulty patches on bfq site. The fix should be tested on the system affected by the panic.
2.6.34_p1-r2 committed, using the updated patch. please rename the patches the next time you update them :) thanks!
