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

[Alan Jenkins]

On 10/10/09, Alan Jenkins <sourcejedi.lkml at googlemail.com> wrote:
> On 10/10/09, Luca Niccoli <lultimouomo at gmail.com> wrote:
>> For the wlan (rt2860, plus eeepl_laptop patch from darren):
>> 1200ms for switching it on, 300ms to switch it off
>> For the bluetooth:
>> 1100ms on, 200ms off
>>
>>
>>> - 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.
>>
>>
>> I tried booting with:
>> bluetooth and wifi off (the camera is always switched on at boot time
>> in 2.6.31), eeepc_laptos initcall returns after 2900ms,
>> bluetooth and wifi on: 4670ms
>> only wifi on: 3830ms
>> only bluetooth on: 3810ms
>>
>> Cheers,
>>
>> Luca
>
> Cool.  So that leave 2900 - 0500 = ~2400ms of unknown delays.

wups, more like 1900ms after excluding the time to disable the
bluetooth and wifi.

> The easy option is to force the entire driver to load asynchronously
> (i.e. in the background), like the acpi battery driver.
>
> 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 :-).

Oops, I'm afraid the easy way doesn't work for modules.  We can do
async work in a module, but it won't load in the background.  It only
helps if you build it into the kernel.

So for debian (as a general purpose distribution), it will only help
if we can fix it the hard way.

"async: Fix module loading async-work regression

    Several drivers use asynchronous work to do device discovery, and we
    synchronize with them in the compiled-in case before we actually try to
    mount root filesystems etc.

    However, when compiled as modules, that synchronization is missing - the
    module loading completes, but the driver hasn't actually finished
    probing for devices, and that means that any user mode that expects to
    use the devices after the 'insmod' is now potentially broken.
...
    It will slow down module loading, but since common devices should be
    built in anyway, and since the bug is really annoying and hard to handle
    from user space (and caused several S3 resume regressions), the simple
    fix to wait is the right one."

Regards
Alan