https://bugzilla.novell.com/show_bug.cgi?id=387792
User trenn@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=387792#c6
Thomas Renninger changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |trenn@novell.com, acpi@linux.intel.com
Status|NEW |ASSIGNED
Summary|ACPI exception error - No Asus ATK0110 ACPI |ACPI exception error - No Asus ATK0110 ACPI
|driver implemented yet |driver implemented yet - Double ACPI IO
| |declaration
--- Comment #6 from Thomas Renninger 2008-05-19 07:47:33 MST ---
Wow, I realized that now after a second look, the device at IO address 0x295 is
declared twice!
Oh dear...:
OperationRegion (HWRE, SystemIO, 0x0295, 0x02)
Field (HWRE, ByteAcc, NoLock, Preserve)
{
HIDX, 8,
HDAT, 8
}
OperationRegion (IP, SystemIO, 0x0295, 0x02)
Field (IP, ByteAcc, NoLock, Preserve)
{
INDX, 8,
DAT0, 8
}
This declares 4 variables: HIDX, INDX (pointing to the same address: 0x295)
HDAT, DAT0 (pointing to the same address: 0x296)
The latter I saw quite often, it seems to be a template from a BIOS vendor (or
from wherever it comes from), it is used by these functions:
FOFF - SBYT
SFAN () /
\ FON - SBYT
RTMP () - GBYT
In SBYT and GBYT the actual HW access is done:
Method (SBYT, 2, NotSerialized)
{
Store (Arg0, INDX)
Store (Arg1, DAT0)
}
Method (GBYT, 1, NotSerialized)
{
Store (Arg0, INDX)
Store (DAT0, Local0)
Return (Local0)
}
Syntax for methods in ASL is:
Method (NAME, AMOUNT OF PARAMETERS, [Serialized] | [NotSerialized])
Inside the method ArgX is used to address the paramter X,
LocalX is a placeholder for local method variables (you do not need to
explicitly declare them).
The fan functions from above seem to never be used.
But the default temperature, _TMP function of ThermalZone (THRM) calls RTMP,
RTMP calls GBYT(0x29). Here, 0x29 is written to 0x295 and afterwards 0x296 is
stored and then calculated into (Kelvin*10).
The HIDX and HDAT are abstracted one more time through the Index Field:
IndexField (HIDX, HDAT, ByteAcc, NoLock, Preserve)
{
Offset (0x0B),
FD11, 3,
FD12, 3,
FD13, 1,
Offset (0x0C),
Offset (0x0D),
FAN1, 8,
FAN2, 8,
FAN3, 8,
Offset (0x18),
FEN1, 8,
FEN2, 8,
FEN3, 8,
Offset (0x20),
VCOR, 8,
V33V, 8,
Offset (0x23),
V50V, 8,
V12V, 8,
Offset (0x29),
TSR1, 8,
MBTE, 8
}
Like that, FD11, FD12, ..., MBTE are declared as variables.
If e.g. FAN1 variable is accessed, the parser knows that this is an indexed
addressed hardeware and will write a 0xD (at offset 0x0D) into the index
register at 0x295 and will then store the value of the data register (0x296).
E.g.
Store (GBYT(0x29), Local0)
is the same than
Store (TSR1, Local0)
and reads the temperature as done in RTMP.
If you have the Asus specific ATK0110 ACPI driver and this one tries to read
one of the three fans or other info from the device at 0x295 and the thermal
driver kicks in and wants to read the temperature you have a race condition.
This is a BIOS bug and theoretically can be fixed in through a global mutex.
Why does this happen?
I saw the FON, FOFF, GBYT, SBYT, SFAN construct very often on a 0x295 IO
device.
This seem to be a kind of template (sometimes not used at all) from one of the
manufacturers (probably the guys where ASUS buys the BIOS).
Now ASUS adds their own ACPI device ATK0110 and wants to make use of the
additional HW on their boards, but they did not realize that there already
exist ACPI functions in the BIOS accessing the very same HW.
This is nothing that can be solved in OS, someone must tell ASUS that they are
doing something wrong.
Hmm, but the current implementation in osl.c to find hwmon vs. ACPI HW accesses
can easily be extended to find such double declarations. This also looks like
something for the firmwarekit test or in this case I'd even always throw an
error in dmesg, double IO declarations in ACPI are always a sever BIOS bug.
Ok this is nothing that hits us yet, because there is no ATK0110 driver (yet),
I'll ask whether someone still wants to look at it or can repost...
I keep the bug open until I have a patch to detect the double IO declaration...
Jean, I also wonder how we should collect bugs where our hwmon vs ACPI
detection hits..., having a list of bugs for reference would be great..., maybe
we should use a keyword in the subject or mark them in another way to still be
able to find them, even if the bug is marked as resolved.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.