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 <[EMAIL PROTECTED]> 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.
_______________________________________________
Devel mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/devel
