| Summary: | gentoo-sources-2.6.18-r1 - ehci_hcd module hangs upon hotplug | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Dijital Munky <dijital.munky> |
| Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | major | CC: | dijital.munky |
| Priority: | High | ||
| Version: | 2006.1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch for drivers/usb/host/ehci-pci.c | ||
|
Description
Dijital Munky
2006-11-10 21:33:36 UTC
Upon researching this issue on the big ol' net, I came across this link: http://groups.google.ca/group/linux.kernel/browse_thread/thread/adf460ef7a1d0452/eb4f8be0e1fcf961?lnk=st&q=ehci_hcd&rnum=2#eb4f8be0e1fcf961 I added the spin_lock_init(&ehci_lock); call to the appropriate place in drivers/usb/host/ehci-pci.c:ehci_pci_setup(). Upon re-compiling, rebooting and mod-probing the ehci_hcd module, USB2 hotplug functionality seems to be corrected. I will add a patch for this once I get a chance to make it (it is my first time making a patch to submit as part of a bug). Created attachment 101648 [details, diff]
patch for drivers/usb/host/ehci-pci.c
This isn't a valid fix, that report is from over a year ago. Please revert the patch, enable CONFIG_USB_DEBUG, and post debug logs from after a hang has occurred. (In reply to comment #3) > This isn't a valid fix, that report is from over a year ago. Please revert the > patch, enable CONFIG_USB_DEBUG, and post debug logs from after a hang has > occurred. > Perhaps you could explain why this isn't valid?? I applied it and it works, so from my POV it is valid. Just because something is a bit older, doesn't mean it is useless or invalid, if that were the case I would've stopped talking to my parents and grandparents years ago.... Whether it is a good idea or merely just a hack is another question. My understanding is that it is more of the latter, however, if it fixes it until the kernel guys fix it properly, what's the issue?? Perhaps it could be a use flag that people could enable?? I will however turn CONFIG_USB_DEBUG on and try to get a better log from when the hang happens. I assume that this logging all happens in the kernel log?? The patch there is for an unrelated problem - spinlock corruption. It also is not a fix for that problem, it is a hackish workaround (it simply confirmed the symptoms, the real fix for that bug was very different]). Also, that patch results with the spin lock being initialized twice therefore the state after the first invocation is forgotten/ignored at some point. This is bad, effectively overwriting important state data. In this case, the spin lock is already initialised in ehci_init() which is called by ehci_pci_setup() (the function you modified). That aside, the fact that the hang is related to this lock may be a useful observation later, when more information has been provided. To answer the other questions, we do not apply hack patches, we do not apply non-upstream patches (other than in exceptional circumstances) and we do not apply patches based on USE flags. What we will do is ensure that a proper fix is developed and is included in the upstream Linux kernel. For more info on our patching style see http://dev.gentoo.org/~dsd/genpatches/ This may seem a little inefficient in terms of speedy fixes but is the only way we've found a beast as big as the kernel to be maintainable with so few resources in the long term. If we had more resources and developers maybe we'd be able to rethink our maintenance style, right now it's just 2 people and typically only myself working on the bug reports. Okay, I did the following steps: 1. emerge -C =gentoo-sources-2.6.18-r1 2. rm -r /usr/src/linux-2.6.18-gentoo-r1 3. emerge -av gentoo-sources (ensured symlink on the USE variable was enabled) 4. cd /usr/src/linux 5. gzcat /proc/config.gz > .config 6. mount /boot 7. make oldconfig && make menuconfig 8. enabled CONFIG_USB_DEBUG. 9. Added -nopatch to the kernel version to ensure that I was running the unpatched version. 10. make && make modules_install && make install && reboot 11. uname -r to ensure that I was using the unpatched kernel. Once rebooted, I plugged and unplugged all of the devices that would hang before. This time everything looked after itself. So I rebooted and tried the same thing again. It appears that perhaps the patch didn't fix it after all, but rather, that while reading that thread (or another) I enabled something that my hardware required in order for USB 2.0 to work properly. I am going to leave my kernel as is for a few days and reboot occasionally (till at least Friday just in case I am having a fluke ATM. In the original problem, occasionally USB 2.0 would work upon reboot, but it would usually stop working at some point), and if I have no more problems with USB 2.0, I'll resolve as INVALID. BTW, I appreciate your help and patience. Especially the explanations I asked for. They were a great help to a relative kernel code newb like me. I also completely agree with your policy regarding patches... OK - please reopen if the problem is reproducible |
