Bug 9026
Summary: | PROBLEM: kernel hang in ohci init (pci-quirks) | ||
---|---|---|---|
Product: | Drivers | Reporter: | Satyam Sharma (satyam) |
Component: | PCI | Assignee: | Greg Kroah-Hartman (greg) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | protasnb, yyyeer.bo |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.22 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 5089 |
Description
Satyam Sharma
2007-09-16 05:49:44 UTC
[ Getting bugzilla up to speed with later discussion on the original LKML thread at http://lkml.org/lkml/2007/7/12/64 ] David Brownell: > > > (file linux/drivers/usb/host/pci-quirks.c) kernel freezes in this > > section: > > Note that hangs in that file almost always mean "your BIOS is goofy". > Hunt for BIOS settings related to USB, and change them. As a rule, if > you tell your BIOS to ignore USB devices (mostly keyboards and disks), > it will have even less of an excuse to break like that. Timo Lindemann: > > > Note that hangs in that file almost always mean "your BIOS is goofy". > > Hunt for BIOS settings related to USB, and change them. > > This laptop's BIOS only offers "legacy support" enabled or disabled, > both of which lead to frozen kernel. > [...] > > It is just odd that up to (not including) the 2.6.21-series every kernel > boots, and after that, they just freeze. Satyam Sharma: > > Hey, just try git-bisect already :-) Timo Lindemann: > > To sum this up: > > the userspace 2.6.20.6 (the "good" kernel) and 2.6.22 (the "bad" kernel) > were compiled in is exactly the same setup. I recompiled "good" to check > for that, earlier, but "good" also works then. > > "good" does not exhibit the printks I placed in the section (the same > ones I did for "bad"), making it plausible that the section is not > executed at all. > > dmesg is not captured to disk, netconsole and serial console also do not > work (they both did in the "good" kernel). Also, my keyboard does not > work with "bad" during that phase -- Magic SysRq is also not working then. > > I can try to hook up the laptop to an external monitor to capture some > more dmesg, and just shoot a photo, but I am right now trying to work > with git, as Satyam suggested. David Brownell: > > Thing is, pci-quirks.c runs early > enough in the boot process -- before the OHCI driver can even > run!! -- that you can probably rule out the USB stack as being > the cause of this regression. Disable the USB host controllers > in your config, and see what happens... > [...] > > Where the subsystem in question is early PCI/ACPI initialization, > before the drivers start binding to PCI devices... it's always > annoying when changes in that area cause USB to break, since the > only involvement of USB is to display a "rude failure" symptom. > It took a long time to get the IRQ setup glitches fixed! > > One thing you might do is enable all the ACPI debug messaging and > disable the usb/host/pci-quirks.c stuff (just comment it all out), > assuming you can boot without USB keyboard/mouse. Then compare > the relevant diagnostics between "good" and "bad" kernels. It's > likely something interesting will appear. One theory about what's going wrong: somethings interfering with SMI handling, and that's required for the BIOS to do its part of that handoff. Any updates on this problem please? It looks like reporter is not giving any more feedback, unless someone has been working with him directly. On Mon, 11 Feb 2008, bugme-daemon@bugzilla.kernel.org wrote: > > ------- Comment #3 from protasnb@gmail.com 2008-02-11 20:29 ------- > Any updates on this problem please? It looks like reporter is not giving any > more feedback, unless someone has been working with him directly. Apologies for the late reply, but I haven't really been keeping up with kernel development in a big way for the last few months. Regarding this particular issue, I was contacted by the original reporter (Timo Lindemann) maybe a month back and he said the latest kernel seems to be booting/working fine on his laptop now. Hard for me or others to confirm considering the problem was reproduced only on the original reporter's laptop. Moreover, it is not known whether Timo built the latest kernel using the same .config or a new one. We could probably request him to do a git-bisect to find both the buggy commit (and the one that resolved it "automagically") to really get down to the bottom of this, but otherwise I guess we may have to close this one (or keep as is) for lack of further information ... Thanks, Satyam Great, thanks for the update. I think on this positive note we can close it now, taking into account how much fixes/updates went into the subsystem. Please reopen if the problem confirmed with latest kernel. |