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

[Luca Niccoli]

2009/10/10 Alan Jenkins <sourcejedi.lkml at googlemail.com>:

> I think we can avoid the *known* delays altogether.  We should only
> need to suffer the camera delay if it was disabled in the BIOS and we
> have to enable it - but that should be a one-off, because the BIOS
> remembers the setting for us.

Right, the (obvious) patch attached trims half a second if the camera
is already enabled.

> Cool.  So that leave 2900 - 0500 = ~2400ms of unknown delays.

Mmm, right now the load time grown by 1200ms (under every kernel and
in every condition), I don't know why...
Anyway, not compiling rfkill-input trims another second on the load
time with wifi and bt off, and it doesn't take longer if they're on.
So I'm down to 3100ms in every condition. Still slow, but an
improvement nonetheless.

> The easy option is to force the entire driver to load asynchronously
> (i.e. in the background), like the acpi battery driver.

By making asynchronous calls we could shorten the load time even in
the module case, no?
It would still take the time it takes for the slowest init to return,
but better than nothing.

> The hard way is to work out why Asus have added these delays and what
> they do about them on the pre-installed OS's.  The obvious place to
> look would be the acpi INIT method.  I am curious as to what your
> "acpidump" output looks like.  But to be honest, I doubt it's worth
> the effort.  Especially if the answer is that they don't install Linux
> anymore and the Windows driver is loaded as a background process :-).

http://bugzilla.kernel.org/show_bug.cgi?id=12243
The problem seems well known, and stalled.

Cheers,

Luca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eeepc.patch
Type: text/x-diff
Size: 439 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/debian-eeepc-devel/attachments/20091010/29f7c63b/attachment.patch>