Hi!
Good morning to you too!
In 2.6.0-test1, OHCI is non-functional after first suspend/resume, and kills machine during secon suspend/resume cycle.
Hmm, last time I tested suspend/resume it worked fine. That was 2.5.67, but the OHCI code hasn't had any relevant changes since then.
Evidently your system used different suspend/resume paths than mine did ... :)
Can you try echo 4 > /proc/acpi/sleep? echo 3 breaks it, too, but that is little harder to set up.
I usually test with "apm -s" ... since I've yet to come up with an ACPI configuration that works properly. IRQ misconfiguration for USB is still a blocking issue for many people (not just me).
Going through ACPI would certainly explain some breakage; it's been sufficiently troublesome with USB that it's not gotten much testing at all. I happened to notice this morning that ACPI's USB IRQ problems are one of the longest-standing open 2.6 bugs: http://bugme.osdl.org/show_bug.cgi?id=10 ... and it's now been migrated into the 2.4.22-pre series (sigh).
Could you try reproducing this failure using just APM? I could believe there's a generic PM issue (I've been expecting 2.6-test to eventually start shaking PM out); but given the amount of trouble ACPI has caused, we should first rule that factor out.
What happens is that ohci_irq gets ohci->hcca == NULL, and kills machine. Why is ohci->hcca == NULL? ohci_stop was called from hcd_panic() and freed ohci->hcca.
Then the problem is that an IRQ is still coming in after the HCD panicked.
Actually, as PCI interrupts are shared, I do not find that too
surprising.
I do. Sharing is irrelevant. If it's been cleaned up, then the IRQ should no longer be bound to that device.
I believe that we should
1) not free ohci->hcca so that system has better chance surviving hcd_panic()
Not ever????
It's freed in exactly one place, after everything should be shut down. If it wasn't shut down, that was the problem.
Could you instead figure out why it wasn't shut down?
In case of hcd_panic(), where is interrupt deallocated?
I'll have to check that out, but I noticed that one of my usual development machines (on which suspend/resume can actually be made to work) is now unusable due to some PCI initialization issue with Cardbus.
and
2) inform user when hcd panics.
The OHCI code does that already on the normal panic path (controller delivers a Unrecoverable Error interrupt), but you're right that this would be better as a generic KERN_CRIT diagnostic. (But one saying which HCD panicked, rather than leaving folk to guess which of the N it applied to...) And I'd print that message sooner, not waiting for that task to be scheduled.
That would be good. I definitely had another failure path, where it did not tell me that hcd is no K.O...
I'll likely submit that to Greg in the next few days, cc you.
- Dave
Pavel
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
