Hi Thomas,
I found something that looks strange behaviour while profiling the
resume-from-RAM path on OLPC.
A little explanation on traces: they have been gathered using Arnaldo's
refactoring of latencytrace patches
From 3e81bb2749ab132f7ff68a22880754e206d7986a Mon Sep 17 00:00:00 2001
From:
On Sun, Sep 02, 2007 at 01:03:12PM -0400, Marcelo Tosatti wrote:
On Sun, Sep 02, 2007 at 12:50:03PM +0100, David Woodhouse wrote:
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote:
Note: ohci_pci_resume does msleep 20.
Hm. It's just waiting for the hardware to settle, right? Do
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote:
This interrupt scheduled for 233-40ms is what sounds wrong. It should
just continue to blaze off the EHCI resume path.
... after 20ms have passed, not almost 200.
Ah, right. Sorry, I missed the order of magnitude discrepancy. Are
On Mon, 2007-09-03 at 09:27 +0100, David Woodhouse wrote:
On Mon, 2007-09-03 at 04:05 -0400, Marcelo Tosatti wrote:
This interrupt scheduled for 233-40ms is what sounds wrong. It should
just continue to blaze off the EHCI resume path.
... after 20ms have passed, not almost 200.
Ah,
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote:
Note: ohci_pci_resume does msleep 20.
Hm. It's just waiting for the hardware to settle, right? Do the resume
functions for the devices themselves actually have to wait until this is
complete, before they can do anything?
It really
On Sun, Sep 02, 2007 at 12:50:03PM +0100, David Woodhouse wrote:
On Sun, 2007-09-02 at 04:10 -0400, Marcelo Tosatti wrote:
Note: ohci_pci_resume does msleep 20.
Hm. It's just waiting for the hardware to settle, right? Do the resume
functions for the devices themselves actually have to wait
On Wed, 2007-08-29 at 08:31 -0400, Marcelo Tosatti wrote:
What you think is the easier/proper way to postpone this console work
to happen after the resume process is finished?
It's spending all its time waiting for characters to be sent out a
serial port which isn't even going to have anything
