[OLPC-devel] Thoughts on S3 resume.

Mitch Bradley wmb at firmworks.com
Mon Aug 7 22:18:24 EDT 2006


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.
>>     




More information about the Devel mailing list