On 10/10/09, Luca Niccoli <[email protected]> wrote: > 2009/10/10 Alan Jenkins <[email protected]>: > >> 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 _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
