https://bugzilla.kernel.org/show_bug.cgi?id=14669
--- Comment #37 from Raffaello D. Di Napoli <fasti...@gmail.com> 2012-01-24
01:44:38 ---
I tried 3.1.6, still the same behavior (no change at all).
Upon suggestion arrived in form of a private e-mail, I tried a change in
drivers/acpi/acpica/nsxfname.c, to skip execution of the _STA method on all
devices:
--- nsxfname.c.orig 2011-10-24 03:10:05.000000000 -0400
+++ nsxfname.c 2012-01-23 00:17:55.953371956 -0500
@@ -376,7 +376,11 @@
/* Execute the Device._STA method */
+#ifdef CONFIG_ACPICA_DEVSTA_OK
+ status = AE_OK;
+#else
status = acpi_ut_execute_STA(node, &info->current_status);
+#endif
if (ACPI_SUCCESS(status)) {
valid |= ACPI_VALID_STA;
}
(I also created a config option to enable/disable it as necessary.)
This effectively removed the 4s delay upon boot. Now, that’s interesting.
So I investigated on this mysterious (to me) _STA method.
I undid the patch above, and instead added a printk BEFORE the execution of
_STA, that also printed the device name (I’ll omit the patch for brevity, it’s
trivial). This revealed a real surprise:
...
[ 0.684241] _STA on P_D0
[ 0.684354] _STA on P_D1
[ 0.884069] _STA on SATA
[ 1.084159] _STA on PRT0
[ 1.084296] _STA on PRT1
[ 1.084408] _STA on PRT2
...
[ 1.093202] _STA on LPCB
[ 1.093286] _STA on PATA
[ 1.093368] _STA on SATA
[ 1.292136] _STA on SBUS
[ 1.292249] _STA on MCHC
[ 1.292335] _STA on PDRC
...
[ 1.293885] _STA on LPCB
[ 1.293969] _STA on PATA
[ 1.294051] _STA on SATA
[ 1.492149] _STA on SBUS
[ 1.492262] _STA on MCHC
[ 1.492347] _STA on PDRC
...
... and so on. See the pattern: every call to _STA on SATA, causes a delay of
approx. 200ms. Does this number sound familiar? :)
So I went further, and decompiled my BIOS’s DSDT. This revealed something I
really did NOT expect:
...
Device (SATA)
{
...
Method (_STA, 0, NotSerialized)
{
Sleep (0xC8)
Return (0x0F)
}
...
Do I need to clarify that 0xc8 is 200? :)
Now, I think my only real option (avoiding the hack above) is to modify and
recompile my DSDT, eliminating the silly Sleep call.
Can anybody come up with a reason why there should be a sleep in _STA?
Synchronization issues?
Just to be safe, I’ll also check Acer’s website to see if they mention ever
adding such thing in the BIOS revision log.
I can attach the whole DSDT if you want, or the dmesg with the revealing printk
if you want. Or just ask me anything, I’ll be glad to experiment more.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
