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

[Alan Jenkins]

On 10/10/09, Luca Niccoli <lultimouomo at gmail.com> wrote:
> 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.

But there is only one init method to run :-/.

-Your patch eliminates the delay from the camera.
- Assuming rfkill-input is removed on schedule, the rfkill delay will
be removed in 2.6.33.  (And if it is delayed, we can do exactly the
same as with the camera).
-> Then there is only the INIT method left - there is nothing else to
run it in parallel with.

>> 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.

It looks to me like the delay on module loading can't be solved in the
kernel.  I think there's a better way to work around it in userspace
though.

Instead of

"blacklist eeepc-laptop"

try

"install eeepc-laptop modprobe --ignore-install eeepc-laptop $CMDLINE_OPTS &"

In the init script, do "modprobe --use-blacklist eeepc-laptop".  If
the background modprobe is still running, that will wait for it to
finish.

That way, we
 - load eeepc-laptop as normal when udev starts, but avoid blocking
the rest of the boot process on it
 - avoid a confusing "blacklist" entry which isn't really a blacklist
 -  allow the user to add "blacklist eeepc-laptop" and have it work as normal

Then we should also change the eeepc-laptop driver to initialise
asynchronously when it is built in to the kernel.  Otherwise building
it into the kernel will slow down the boot process, which is
unpleasantly counter-intuitive.

Does that make sense?  Do you want to work on this yourself, or should
I add it to my TODO list?

Thanks
Alan