Messages in this thread | | | Date | Thu, 24 Jul 2003 12:24:32 +0200 | From | Pavel Machek <> | Subject | Re: [linux-usb-devel] OHCI problems with suspend/resume |
| |
Hi!
> >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.
> >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 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?
> >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...
Pavel -- When do you have a heart between your knees? [Johanka's followup: and *two* hearts?] - 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/
| |