on boot, usb is killed when acpi wakes up devices, this is similar to findings in: http://lkml.org/lkml/2004/6/6/58 and here: http://lkml.org/lkml/2004/6/6/63 dmesg and lspci outputs to follow as attachments will show that usb is found, and usb will find my mouse only if usb mouse legacy support is turned on in bios which limits usage of mouse's features if legacy support is not on, mouse will lose power when acpi wakes up everything and when plugged back in power to sensor is on, but solid state power for always on leds and such is off note:the forcedeth driver doesn't get shutout by acpi, it works perfectly, only the usb gets killed Reproducible: Always Steps to Reproduce: 1.boot 2.6.10-r6 with acpi on 2. 3. Actual Results: usb is dead Expected Results: usb to stay awake or get revived by hotplug or coldplug A7N8X-X motherboard with nForce 2 acpi on
Created attachment 49646 [details] dmesg output
Created attachment 49647 [details] lspci output
Created attachment 49648 [details] .config file for kernel
Comment on attachment 49648 [details] .config file for kernel also take note of what Deawin says in this thread about the patch from a relatively older kernel to another relatively older kernel fixing an apparently identical problem
Comment on attachment 49648 [details] .config file for kernel http://forums.gentoo.org/viewtopic.php?t=65671&highlight=a7n8xx
Could you please test 2.6.11_rc2?
works lovely, acpi no longer kills usb using development-sources 2.6.11_rc2 as suggested, gentoo-dev-sources should hopefully get whatever the difference here is, and in reverse gentoo-dev-sources actually lets me build my ati drivers, while this doesn't, but that'll be another bug report
Hmm. I can't immediately see any patches that would have solved this since 2.6.10. If you wish to investigate further you could do whats called a "binary search", something like: Try 2.6.11_rc1. If the problem exists in that kernel, then you know that the fix was included somewhere between 2.6.11-rc1 and 2.6.11-rc2. So you would now try one of the daily snapshots, you would try one that came roughly halfway inbetween -rc1 and -rc2. As there were 9 of them, you'd now choose to test (say) 2.6.11-rc1-bk4 If -rc1-bk4 does not exhibit the problem, then you now know it was fixed somewhere between -rc1 and -rc1-bk4. You'd then test -rc1-bk2, ..... get the idea? Once you have identified the exact daily snapshot which fixes it we can then look at testing individual patches. Let me know if you are going to try this and need more details. I understand that this is a lot of work and very time consuming -- you may just prefer to wait until 2.6.11. Infact, maybe someone else will find this bug and contribute some info to it.
apparently somewhere in my travels ohci didn't properly get put in into gentoo-dev each time i compiled, i worked backwards until i managed to get gentoo-dev to work with it, i'm sorry this seems like a waste, but in fact your showing me a safe way to reason in a field i'm new too has shown me how to go about fixing my unresolved problem (no ati compilation with vanilla-dev while older gentoo-dev works =\ we'll see) and no, the time is worth it, you can only make it better if you know more about it, so i'll put the efforts into the open bug on the ati drivers (80046 btw)
