snaps from dmidecode: BIOS Information Vendor: American Megatrends Inc. Version: 1301 Release Date: 08/05/2008 System Information Manufacturer: ASUSTeK Computer INC. Product Name: 901 Version: x.x Serial Number: EeePC-1234567890 UUID: 00B6CA08-553D-DD81-2747-00221519B97E Wake-up Type: Power Switch SKU Number: 90OAM0BB73111131U201Q Family: To Be Filled By O.E.M. dmesg consistently confirms slow boot times: [ 0.275412] eeepc: Eee PC Hotkey Driver [ 1.311214] eeepc: Hotkey init flags 0x41 [ 1.314479] eeepc: Get control methods supported: 0x101713 debugging the code of the driver, the code basically halts at eeepc_hotkey_check(): if (write_acpi_int(ehotk->handle, "INIT", ehotk->init_flag, &buffer)) { which is a wrapper to: 215 static int write_acpi_int(acpi_handle handle, const char *method, int val, 216 » » » struct acpi_buffer *output) 217 { 218 » struct acpi_object_list params; 219 » union acpi_object in_obj; 220 » acpi_status status; 221 222 » params.count = 1; 223 » params.pointer = &in_obj; 224 » in_obj.type = ACPI_TYPE_INTEGER; 225 » in_obj.integer.value = val; 226 227 » status = acpi_evaluate_object(handle, (char *)method, ¶ms, output); 228 » return (status == AE_OK ? 0 : -1); 229 }
Created attachment 19349 [details] acpidump output
Hi, Auke By the way, why do you care that it will take more than 1s to initialize the hotkey driver on the eee-pc 901? From the acpidump it seems that the functio of sleep is called several times and the SMbus controller will be accessed in the INIT object. INIT -> CFVS -> SFBA and the SMbus controller is accessed in the SFBA object. In such case the issue is related with BIOS. It had better be fixed by BIOS upgrading. Thanks.
CC :corentincj@iksaif.net
(In reply to comment #2) > Hi, Auke > By the way, why do you care that it will take more than 1s to initialize > the hotkey driver on the eee-pc 901? it blocks the entire boot process of the kernel, making the kernel boot instead of 0.8 seconds, boot in 1.8 seconds, an increase in boot time of > 220% !!!
Asside from Asus providing a BIOS update that works better... The next step would be to do enable CONFIG_ACPI_DEBUG along with printk time and trace the actual path taken through the AML with timestamps. This might be done most easily by overriding the DSDT with moves to the Debug object that can be timestamped. For it is possible that Linux is not provoking the most optimal path through the BIOS... Hopefully Corentin has access this hardware and can take this next step.
Unfortunately I only have an eeepc 701. I will try to reproduce that on my eeepc, but if it's only affecting eeepc 901 it will be hard for me to debug. Anyway I won't be able to test that before next week. If anobody with an eeepc could see if his hardware is affected (eeepc 701/901, bios version).
Eeepc 701 is not affected. Lastest BIOS for Eeepc 901 is 1703. Auke Kok could you try to update your bios ? If you can't, I'll try to find someone with a 901 ...
yes, Yakui and I have reproduced the problem. most of the time are costed by the AML code. the SMbus controller is accessed very frequently in the INIT object, which always invokes some sleep. (10ms each time). This is similar to another problem I found. Evaluating _WAK method takes > 1sec during resume, while the total kernel resume time is 2sec. Anyway, we'll try to upgrade the BIOS and see if there are any improvements.
Hi, Corentin We have an EEEPC 901 in hand and the bios version is also 1301. But now we need do some tests on it . Very sorry that now we can't upgrade BIOS to 1703. Thanks.
My reading of the new code in INIT is: 1) If waking from S4 or S5, set the FSB to the value in NVRAM 2) Otherwise, set the FSB to the value in FS70 (a value in RAM) we then pass to CFVS. This does the following: 1) If waking from S3, S4 or S5, always perform the FSB change 2) Otherwise, only perform the FSB change if it would change the value. This is done by comparing ARG0 to FS70. So, we must be following path 1. My /guess/ is that WAKT is set to 0x5 on boot. This seems like unnecessary paranoia on Asus's part, but it looks like there's no trivial way for us to avoid FSBA being called. I'll look into whether there's any way to make it faster...
I sent an email to Chih-Wei Huang from Asus and he forwarded it to the Eeepc team. He said that he didn't think it was a known issue, so it may not be fixed in newer bios.
eeepc_laptop seems to take about 1.85 seconds to initialize on an eee 1000, bios version 0803 (latest), running linux 2.6.28 boot tracer output: [...] [ 0.741634] initcall i915_init+0x0/0x14 returned 0 after 452 usecs [ 0.741723] calling topology_sysfs_init+0x0/0x3f @ 1 [ 0.741827] initcall topology_sysfs_init+0x0/0x3f returned 0 after 22 usecs [ 0.741915] calling eeepc_laptop_init+0x0/0x1ad @ 1 [ 0.742026] eeepc: Eee PC Hotkey Driver [ 2.500010] Clocksource tsc unstable (delta = -89950091 ns) [ 2.601993] eeepc: Hotkey init flags 0x41 [ 2.606304] eeepc: Get control methods supported: 0x101713 [ 2.606943] input: Asus EeePC extra buttons as /class/input/input5 [ 2.619232] initcall eeepc_laptop_init+0x0/0x1ad returned 0 after 1833240 usecs [ 2.619338] calling atl1e_init_module+0x0/0x11 @ 1 [...] This is out of a kernel boot time of about 3.3 seconds in my configuration.
ASUS needs to fix their BIOS, this doesn't appear to be a Linux bug. Closing as DOCUMENTED -- but if there is news from Asus, or any other bright ideaas, we'll post it here.