Output (USB Unload) ------------------- ...
So clearly EHCI loaded OK. In the absense of ACPI resume (or suspend?), nothing went wrong. And in the absence of any USB code _at all_ running during the ACPI suspend cycle, something gets deeply broken ... so it's clear that ACPI is, all by itself, badly breaking something PCI-related.
Output (Resume + modprobe ehci-hcd): ------------------------------------ ... Mar 16 13:11:35 localhost kernel: Restarting tasks...<6>e1000: eth0 NIC Link is Up 10 Mbps Half Duplex Mar 16 13:11:35 localhost kernel: done Mar 16 13:11:43 localhost su: (to root) niella on /dev/pts/35 Mar 16 13:11:43 localhost su: pam_unix2: session started for user root, service su Mar 16 13:12:01 localhost kernel: core] Mar 16 13:12:01 localhost kernel: [__crc_ide_task_ioctl+321817/2376065] usb_hcd_pci_probe+0x0/0x4e0 [usbcore] Mar 16 13:12:01 localhost kernel: [<e1afd990>] usb_hcd_pci_probe+0x0/0x4e0 [usbcore] Mar 16 13:12:01 localhost kernel: [pci_device_probe+171/416] pci_device_probe+0xab/0x1a0 Mar 16 13:12:01 localhost kernel: [<c026cf4b>] pci_device_probe+0xab/0x1a0 Mar 16 13:12:01 localhost kernel: [bus_match+59/128] bus_match+0x3b/0x80 Mar 16 13:12:01 localhost kernel: [<c02d87cb>] bus_match+0x3b/0x80 Mar 16 13:12:01 localhost kernel: [driver_attach+79/144] driver_attach+0x4f/0x90 Mar 16 13:12:01 localhost kernel: [<c02d89df>] driver_attach+0x4f/0x90
That's mangled/incomplete -- useless. Something broke, but it's not at all clear what or why. Since it didn't loop forever, it's clearly not the same thing that broke before, so that patch at least improved the symptoms.
Try running just "dmesg"; /var/log/messages has all sorts of useless information, and clearly lost essential data. Maybe something obvious will turn up.
Well clearly (a) something _did_ start at least one module, (b) there's bogus data in the controller's PCI config space, and (c) the EHCI driver would seem to need to defend itself against such bogus data.
If you "modprobe ehci_hcd" after (or during) a normal boot, rather than after ACPI suspend, does this happen? If not, that would seem to suggest that (b) is caused by ACPI.
OK, so this time (a) was your script. And it seems like ACPI is causing more problems than USB can recover from. Any patch addressing (c) clearly can't be more than papering over a deeper bug ... and it seems likely there's more than one such bug, in the (b) category.
I suggest you involve some ACPI folk here. (b) should never happen, and you've already shown that it happens after the ACPI resume. Seems like ACPI has at least one bug to fix, although there may be additional USB issues to sort out.
- Dave
...
The attached patch should address (c); please let us know.
- Dave
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
