Bits from the Debian Eee PC team

[Posted October 13, 2008 by jake]

From:		Ben Armstrong <synrg-AT-sanctuary.nslug.ns.ca>
To:		debian-devel-announce-AT-lists.debian.org
Subject:		Bits from the Debian Eee PC team, autumn 2008
Date:		Mon, 13 Oct 2008 14:35:16 -0300
Message-ID:		<20081013143516.1d258756@sanctuary.edennet>

Also posted as http://syn.theti.ca/2008/10/13/

   Some brief highlights of the last three months of Debian Eee PC
   development.

Thermal and ACPI breakage resolved in 2.6.26-7

   We're pleased to see that in the upload to Sid of
   linux-image-2.6.26-1-686 version 2.6.26-7, the pair of [1]2.6.26 bugs
   we've been tracking that have made it difficult for Eee users to
   upgrade their systems have been resolved. Since then 2.6.26-8 has
   been uploaded and is expected to enter Lenny this week due to a
   freeze exception. Once the new kernel has migrated we will move
   quickly to build and release a new installer that includes it.

Ath5k wifi works on Eee PC in Linux 2.6.27

   Jean-Christophe reports that [2]ath5k works in Linux 2.6.27 on
   the Eee PC 701, and just needs a [3]small patch to work with our
   eeepc-acpi-scripts package. This is good news for those of us with
   models 701, 900, 900A and 1000HD who have been wanting to get off of
   the non-free Madwifi drivers and onto DFSG free drivers.

New Eee PC model 701SD wifi support in the works

   Users of the new Eee PC Model [4]701SD have just started showing up
   looking for support in mainstream Linux distros. Martin Filtenborg
   confirmed using our [5]Eee PC Live image with the GPL'd rtl8187se
   driver from Realtek to demonstrate that we can at least use it to
   connect to an unencrypted AP, get an IP address and ping other hosts.

   Of course, it is one thing to have a working vendor-supplied driver
   and quite another to have mainstream support. We'll make do with what
   we have now, but will be seeking a mainstream solution as soon as
   possible.

   We're seeking more testers and developers to work on this. To date,
   an ITP has not been filed, as it is not yet clear who is going to
   carry this work forward.

Chasing the 5 second boot

   An interesting discussion on [6]Arjan van de Ven and Auke Kok's work
   to get an Eee 901 to boot in 5 seconds took place this month. While
   the Debian Eee PC team is not making work on this a priority, we'll
   keep an eye on it to see if Debian can incorporate some or all of the
   techniques they used so that our users can benefit without making
   radical changes to their systems.

Working towards mainstream support for rt2860

   Our filing of an [7]ITP for rt2860 (the wifi driver for models 901,
   1000 and 1000H) was followed by discussion about how to separate out
   the GPL'd driver from the embedded non-free firmware so that it can
   at least go into contrib. Glenn Saberton has been working on
   rewriting the build system around kbuild and separating out the
   firmware.

Numerous improvements to ACPI scripts

   Since my last progress report, there have been numerous improvements
   to the eeepc-acpi-scripts package to deal with all of the various
   [8]models we now support and make the scripts more robust and
   flexible. Check out the [9]changelog for details.

References

   1. http://wiki.debian.org/DebianEeePC/Bugs/2.6.26
   2. http://lists.alioth.debian.org/pipermail/debian-eeepc-dev...
   3. http://lists.alioth.debian.org/pipermail/debian-eeepc-dev...
   4. http://wiki.debian.org/DebianEeePC/Model/701SD
   5. http://wiki.debian.org/DebianEeePC/Live
   6. http://lists.alioth.debian.org/pipermail/debian-eeepc-dev...
   7. http://bugs.debian.org/497200
   8. http://wiki.debian.org/DebianEeePC/Models
   9.
http://git.debian.org/?p=debian-eeepc/eeepc-acpi-scripts.git;...

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   synrg@sanctuary.nslug.ns.ca
 \`'  Debian   http://www.debian.org    synrg@debian.org
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]

Bits from the Debian Eee PC team

Posted Oct 14, 2008 10:42 UTC (Tue) by xav (guest, #18536) [Link] (7 responses)

I have some doubts about the 5s boot - as far as I can see, Arjan told that you had to start from scratch to reach that goal, not just add a tweak here and there.

Bits from the Debian Eee PC team

Posted Oct 14, 2008 13:00 UTC (Tue) by endecotp (guest, #36428) [Link] (6 responses)

Hi Xav,

I'm the one doing the "5 second boot" experiments referred to in the message. So far, I have reduced by boot time (from end of Grub to xdm login screen visible) from 33 seconds to 19 seconds. Unlike Arjan and Auke's system, mine starts wireless networking, NFS and CUPS, but there are also some things that they have that I'm not running. I think I can probably get it down to 10-12 seconds without too much more work.

It's not clear that much of this could ever make it in to mainstream Debian; the fundamental issue is custom versus general-purpose (modular) kernels. I'm not a Debian developer; I'm just a Debian user sharing the results of my experiments with the Debian list because they seem prepared to listen politely....

As you say, reaching 5 seconds probably involves more fundamental surgery and to be honest I'm not too bothered about that: we're now at the point where the BIOS start time (from pressing the power button to GRUB) is dominant at around 9 seconds. If anyone thinks they can improve on that, with BIOS tweaks or CoreBoot, do let me know. Maybe Arjan is secretly working on this too.

You can read the thread at http://thread.gmane.org/gmane.linux.debian.devel.eeepc/1015

Cheers, Phil.

Bits from the Debian Eee PC team

Posted Oct 14, 2008 23:28 UTC (Tue) by cleary (guest, #41669) [Link] (5 responses)

Hi Phil,
Does your testing currently include a dependency based boot system?

If not, can I recommend you look at insserv, which has seen some strong development in debian lately.

Bits from the Debian Eee PC team

Posted Oct 15, 2008 13:25 UTC (Wed) by endecotp (guest, #36428) [Link] (4 responses)

Hi cleary,

No I'm not using a dependency-based init. My approach so far has been to find the slow bits and remove the bug that makes it slow: sequential is fine as long as the individual steps are fast. Also, since X takes several seconds just probing the hardware, and I'm not (yet) changing that, many of the delays are hidden just by starting X earlier; I'm unsure why Debian starts xdm at S99. The "sore thumbs" are currently setting the clock, which Debian does twice and each time waits until the second ticks over, and the udev coldplugging. Arjan has sidestepped udev with a pre-populated /dev but I'm considering something a bit less extreme or a bit more automated - or simply working out why udev takes so long just to call mknod a few times.

Phil.

Bits from the Debian Eee PC team

Posted Oct 15, 2008 20:30 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

If you're using the default rules, it's probably calling modprobe a bunch
of times for modules you don't have.

Bits from the Debian Eee PC team

Posted Oct 15, 2008 21:32 UTC (Wed) by endecotp (guest, #36428) [Link] (1 responses)

Everything that it needs is built in to the kernel. I have the impression that during coldplug it still calls modprobe, but that that's a no-op as no module is loaded. I'm not sure how much time is spent doing that and whether it's worth trying to fix it; it's clearly spending more time bringing up the network, which could be postponed until later in the boot and run asynchronously.

If anyone's curious, I have put bootgraph/chart here which you can compare with Arjan's from his LPC presentation:

http://chezphil.org/tmp/bootgraph1.svg
http://chezphil.org/tmp/bootchart1.svgz (hmm, maybe the wrong MIME type, sorry)

Bits from the Debian Eee PC team

Posted Oct 15, 2008 22:02 UTC (Wed) by nix (subscriber, #2304) [Link]

It eliminates dozens of forks, at least, and if you know you have no
modules that's all wasted time. (It takes nearly a second to do those
modprobes on my 1.2GHz Athlon IV.)

Bits from the Debian Eee PC team

Posted Oct 20, 2008 5:47 UTC (Mon) by branden (guest, #7029) [Link]

Phil,

xdm starts at S99 for purely historical reasons. It was that way when I took over the X packages from Mark Eichin in 1998 and the closest thing to an articulated reason I ever came up with, or heard anyone else offer, for leaving it there was the usual exceptionalism having to do with X. The default configuration is to run a local X server, of course, and that will go poke the hardware rather hard (which most daemons don't do).

I think in the years since someone has filed a bug requesting that xdm (and the other *dms) be kicked down to S90 or so. Certainly once mode-setting gets into the kernel, I think any remaining reasons for leaving xdm at the tail end of the init sequence will have been vitiated.

You should certainly raise this issue with the current X Strike Force when you feel the time is ripe. xdm is where it is almost entirely due to inertia.

I find the EEE 1000 model very tempting, so I am watching your work with great interest and appreciation. Thank you for your efforts!

14-second boot

Posted Nov 11, 2008 9:45 UTC (Tue) by endecotp (guest, #36428) [Link]

There's now an article summarising this work at

http://www.debian-administration.org/articles/620