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 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/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:16 EST