[lkml]   [2003]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [linux-usb-devel] OHCI problems with suspend/resume
Pavel Machek wrote:
> Hi!
>>Here's a patch that makes things slightly better. ....
>>Where "better" means that it seems functional after the
>>first suspend/resume cycle, and re-enumerates the device
>>that's connected ... but there's still strangeness. And
>>I can see how some of it would be generic.
> For me it:
> reports problem after first suspend, and ohci stops working

When you say "reports problem", what do you mean?

I can see problems _during_ the suspend, before any USB
suspend calls are even made. Only if the controller has
work to do, so it's scanning the schedules (DMA) ... it's
fine until the suspend starts, then the controller gets
an "Unrecoverable Error" IRQ, which I'm used to seeing
for DMA errors. (As if something started shutting down
hardware before the driver had a chance to clean up.)

If there's no DMA action before the suspend starts, the
current code behaved OK for me -- on an APM D3cold
suspend/resume cycle, which isn't so different from what
you'll see with swsusp.

That makes me think I'll be better off waiting for some
of those PM updates to get merged, before I spend much
more time looking at the usb parts of these issues.

> oopses in hcd_panic during second suspend (IIRC).

Likely because resuming a halted controller is nonsense,
and the code needs to reject such attempts.

Of course, if the controller weren't going bonkers before
it's told to start suspending, these particular faults
wouldn't be happening ... :)

- Dave

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.093 / U:31.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site