[OLPC-devel] Thoughts on S3 resume.

[Jim Gettys]

I stand corrected.  Thanks Mitch, for the catch.  I'm too used to the
iPAQ, where we had CF cards and the fact it was IDE was all too
apparent.

My point remains: both IDE and SCSI have very long timeouts for drive
detection, that makes the measurements uninteresting except as an
academic exercise.
                             Regards,
                               - Jim

On Mon, 2006-08-07 at 16:18 -1000, Mitch Bradley wrote:
> Jim Gettys wrote:
> > Chris,
> >
> > USB flash devices are IDE devices; you are not only pulling in whatever
> > the USB stack is doing to you, but also the IDE driver both.
> It's actually even more complicated than that.
> 
> At the hardware interface layer, a Compact FLASH card looks like an IDE 
> drive; an IDE to CF adapter is just wires and connectors.  But that is 
> not true of all types of plug-in FLASH storage.
> 
> USB FLASH devices, whether they are "pen drives" or adapters that let 
> you plug in various flavors of memory cards, look like SCSI devices at 
> the software command set level.  The fact that the CF variant presents 
> an IDE hardware interface is hidden.
> 
> So the basic point - that there's an additional driver on top of the USB 
> one - is correct.  But it's the SCSI driver, not the IDE driver.
> 
> Mitch
> >   Spending
> > any time measuring suspend/resume on this configuration isn't going to
> > tell us much of anything useful.
> >
> > The measurement that is interesting is when the kernel is executing off
> > of the internal flash, and nothing plugged into USB.  I'd like to have
> > two numbers: with and without the USB stack loaded (I know, it will be
> > painful to get the second number until the PS/2 interface is easy to
> > use).
> >
> > This measurement would be then be comparable to what I did on the iPAQ
> > handheld a few weeks ago, and we can go see where we have problems we
> > care about.  On the iPAQ, the time was under .5 seconds worst case, all
> > but 10 milliseconds of which was the hardware doing god only knows what
> > before Linux started running.
> >                           Regards,
> >                                     - Jim
> >
> > On Tue, 2006-08-08 at 00:06 +0100, Chris Ball wrote:
> >   
> >>>> On Sun, 06 Aug 2006 01:12:53, Chris Ball <cjb at mrao.cam.ac.uk> said:
> >>>>         
> >>    > I'm having trouble getting into S3 on my A-test board, using the
> >>    > devel image.  dmesg is attached; I'm seeing ACPI errors and
> >>    > /proc/acpi/sleep doesn't exist, although the rest of /proc/acpi is
> >>    > intact and functional.  I booted with acpi=force into kernel
> >>    > 2.6.17-1.2396.fc6.
> >>
> >> Sleep is working for me now, using /sys/power/state rather than
> >> /proc/acpi/sleep.  So, to sleep on an A-test board, on devel image
> >> 42 or later after booting with acpi=force:
> >>
> >>    date -d "2 minutes" +"%Y-%m-%d %H:%M:%S" > /proc/acpi/alarm
> >>    echo -n "mem" > /sys/power/state
> >>
> >> The resume will fall over if you're booted from USB, since the USB 
> >> root disk is ejected/reinserted by the kernel, and has a new device
> >> node after resume.  This is a pain.
> >>
> >> I made some quick power measurements.  This is for the board and one 
> >> USB flash drive, all other USB is being powered by a hub:
> >>
> >> 0s:    700mA # hit return, screen blanks, power constant at 700mA until..
> >> 20s:   100mA # light on board starts blinking.  What did we do for 20s?
> >> 2m:    700mA # light on board turns solid, but pressing keys does nothing
> >> 2m27s: 700mA # VGA returns, with ext3 errors and disk detection scrolling
> >>
> >> These times would be more reliable if I were on serial rather than VGA,
> >> so I'll get that going.  It does appear that we have at least 20 seconds
> >> before the board hits S3 (on my board), though, and at least 20 from
> >> when the board wakes up (power light solid, full power draw) to when 
> >> the kernel resumes doing basic things like new device detection.
> >>
> >> - Chris.
> >>     
> 
-- 
Jim Gettys
One Laptop Per Child