> ...the biggest > problem area in terms of suspending and not coming back is the > network, and without "wake-on-precisely-what-i'm-waiting-for", > that's problematic.
Most wireless and Ethernet chips can be configured to interrupt or wake on precisely what you're waiting for. They discard all packets for other network addresses. They discard 98% of multicasts that you aren't listening for. They even discard broadcasts if you ask them to. The really smart ones can ignore all broadcasts except for ARPs that are for this machine (there's already a kernel interface for this, "ethtool -s wol a", which we got working late in the XO-1.) I don't know what wireless chip made it into the XO-1.5 (the XO-1.5 hardware spec wiki page just says a "QMI WLAN module" with no data sheet, and the PDF page is even less informative), so I don't know just how fancy its wake-on-lan configuration is. If our new chip is not fancy, it might even be possible to cheat with a mite of code to the resume sequence in Open Firmware. This would look for an incoming ARP that wasn't for us, and quickly put us back to sleep before turning on the DRAM and video and such. Before going to that premature optimization, we should see how many times our suspend-on-idle kernel wakes up and then immediately decides to go back to sleep. If it's uncommon, no need to bother. John _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel