Messages in this thread | | | Date | Tue, 15 Oct 2002 19:39:28 +0200 | From | Nicolas Mailhot <> | Subject | Re: [linux-usb-devel] 2.5.42-ac1, 2.5.42, 2.5.41 boot hang with CONFIG_USB_DEBUG=n |
| |
On 2002.10.15 19:10 David Brownell wrote: >> Procedure was following : >> 1. reboot the computer (software reboot if ok kernel, else reset) >> 2. go through bios (long initiation with memory testing) >> 3. when the bootloader shows up (might hang just before, my disks >> really do not like being stopped before reboot) / when the system >> hangs, press reset >> 4. go through bios initialization (bis) >> 5. when grub shows up, play a bit in the menus (up-down...) then >> choose a kernel >> >> With this protocol I got a 100% boot rate on the original kernel and >> an almost-always hang with the kernel where debuging was undefed in >> drivers/usb/host/ohci-hcd.c. It did boot two times (out of maybe >> 10-15 tries) but that doesn't count since both times the keyboard >> was dead. > > Well, I've seen USB getting annoyingly flakey results in recent > kernels. > That's a little bit outside the bounds of the inconsistency I've seen, > but (I hate to say) not unrealistically so, since you're kicking init > sequences in different ways. That makes troubleshooting harder!
Well, I knew AMD 756 + USB was a bit risky, guess I was too much in a 2.5 mood when I bought this keyboard.
> There are some one-liners floating around that make it a lot better, > like making drivers/base/core.c found_match() "return error != 0" > (true == matched) instead of "return error" (true == failed). That > one might not be your issue at all, but I've seen it to fix failures > that closely resemble your "dead devices" mode.
I"ll try this.
>> No such luck. It really looks like ohci is the culprit:( > > Maybe not, given that you did report (in an earlier note): > > > + ... Unfortunately I've found out today not even CONFIG_USB_DEBUG > > + was sufficient, since I had a boot hand (cold boot) with my debug > > + kernel today (warm boot afterwards was ok, though). > > Even if it isn't one of the bugs causing generic flakiness, a > warm-vs-cold boot problem that's ohci-specific isn't something > that should have appeared in recent kernels. I'd be curious. > Was 2.5.38 behaving OK for you? Or earlier 2.5 kernels?
I'm afraid I didn't try any 2.5 kernel before 2.5.41. If you have a particular version you'd like me tot test, I'll do it (provided it's not one of the disk-eating ones).
I *think* there is a problem in 2.5, and cold booting make it worse, enabling usb debug makes it better. *If* I had not both RH8 2.4.18 and w2k booting happily on my hardware (both cold and warm boots) I would suspect it but that's not the case.
>> P.S. >> >> I don't know if it's important, but I had to enable usb keyboard >> legacy mode in the bios to have keyboard support in the bootloader >> stage. I had a bad feeling about the option though, a good bios is a >> lean bios. > > Unless your boot loader has a small USB stack, leave that emulation > enabled in the bios. Linux will disable it when you bring up USB. > > But it'd be worth seeing if there were any problems with that. In > fact, > in drivers/usb/host/ohci-hcd.c there is one dbg() that could affect > init timing. Experiment: leave all debug messages off, but change > the first dbg() call in hc_reset() into an err() call. Does that make > things better?
I'll do this now, then the found_match thing, and post the results.
Thanks for the suggestions,
-- Nicolas Mailhot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |