[Debian-eeepc-devel] Some experiences with kernel 2.6.31

[Alan Jenkins]

On 10/10/09, Darren Salt <linux at youmustbejoking.demon.co.uk> wrote:
> [snip; slow loading of eeepc_laptop]
>>> There is one known cause of this: i2c_i801. That module is blacklisted
>>> (if you have eeepc-acpi-scripts 1.1.2 or a git snapshot); if it's present
>>> in your kernel, REMOVE IT and the delay will go away.
>
>> It wasn't present, I looked better and found that is probably a BIOS
>> bug for the 901, loading the module takes ~3s...
>
> That's quick compared to what it would take were i2c_i801 being loaded and
> claiming resources...
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=12243
>> I updated to the latest BIOS but it isn't fixed.
>
> 2103? That's what I have, and I see that module initialisation taking a few
> seconds here too.

It takes something like 1.5 seconds on my machine.  1 second for the
wireless toggle (rfkill) and half a second for the camera.

The rfkill initialisation is actually redundant.  It will go away when
the "rfkill input handler" is removed, which is scheduled for 2.6.33.
If you like, you can preview the removal by building a kernel with
CONFIG_EMBEDDED=y and CONFIG_RFKILL_INPUT=n.

I guess we should also optimize the camera delay for 2.6.33 (normally
it will be enabled already so we don't need to suffer the delay).

I can reproduce both my delays at run-time, e.g. (as root)

cd /sys/devices/platform/eeepc/
echo 0 > camera
time echo 1 > camera

and

for d in /sys/devices/platform/eeepc/rfkill/rfkill*; do
  cd $d
  echo Time to enable `cat type`:
  echo 0 > state
  time echo 1 > state
  echo
done

- so you could use this to see whether your delays are purely from
these known causes, or if there is something else going on.  I would
be interested to hear any results.

Thanks
Alan