Re: [linux-usb-devel] OHCI problems with suspend/resume

[Pavel Machek <pavel@suse.cz>]

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?]