Summary: | sys-kernel/zen-sources-2.6.34_p1-r1 enabling BFQ causes kernel panic | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robert Cabrera <robcab666> |
Component: | [OLD] Core system | Assignee: | Markos Chandras (RETIRED) <hwoarang> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | posta_paolo, wired |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | .config from my running kernel (without BFQ enabled) |
Description
Robert Cabrera
2010-07-08 01:19:32 UTC
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! |