This is a windows compatibility issue more than it is an issue with Linux/ACPI not implementing the ACPI specification, but so be it. Some vendors (Fujitsu) are shipping machines that have an enormous Sleep() in the EC _REG method. The one in this bug report has one for 10 seconds, plus another for 8 seconds: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/100110 This sleep delays Linux boot. Curiously, Windows, and reportedly a 2.6.16 version of Linux do not experience a boot delay due to to this. Perhaps they are not actually implementing the requested delay, or perhaps the EC's _REG method is executed in parallel and the reset of boot completes, with the EC _REG completing 18 seconds later... The current proposal in the bug report above is to DMI the failing systems, and cut their long Sleep()s down to shorter ones. That is problematic, of course, for maintaining DMI is never-ending, and we can never be sure that it is correct to shorten the Sleep(). So I think we should look into why EC _REG is serialized, and see if we can un-serialize it.
(In reply to comment #0) > So I think we should look into why EC _REG is serialized, > and see if we can un-serialize it. I don't think we can execute _REG in parallel. Because we can not access EC address space before _REG being finished, i.e. a lot of ACPI stuff may depend on this. IMO, we should root cause why the problem doesn't exist in windows first. Ming, can you please verify how windows handles "Sleep(0x2710)"?
Ming, what's the status of this problem? I think we have root caused/fixed the problem already, right?
We have below patch since v2.6.35-rc4 commit 9cbfa18e8a7b34a32eddbd914a07f085962f50a8 Author: Bob Moore <robert.moore@intel.com> Date: Wed May 26 11:22:41 2010 +0800 ACPICA: Limit maximum time for Sleep() operator To prevent accidental deep sleeps, limit the maximum time that Sleep() will sleep. Configurable, default maximum is two seconds. ACPICA bugzilla 854. http://www.acpica.org/bugzilla/show_bug.cgi?id=854 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>