bug report: multi-byte access in indexfields broken

Hello,

it appears the problems I mailed about earlier are due to a bug in the ACPI code. Reading from multi-byte fields in a ByteAccess-IndexField seems to be broken.

When I replace

IndexField (EIND, EDAT, ByteAcc, NoLock, Preserve)

{
    Offset (0x10), 
    IKFG,   8, 
    FRPN,   16, 
    RAMB,   32,
    AVOL,   8, 

...
}

Method (CRMB, 0, NotSerialized)
{
Return (RAMB)
}

with

IndexField (EIND, EDAT, ByteAcc, NoLock, Preserve)

{
    Offset (0x10), 
    IKFG,   8, 
    FRPN,   16, 
    RAM0,   8,
    RAM1,   8,
    RAM2,   8,
    RAM3,   8,
    AVOL,   8, 

...
}

Method (CRMB, 0, NotSerialized)

{
    Store (RAM3, Local0)
    ShiftLeft (Local0, 0x8, Local0)
    Add (RAM2, Local0, Local0)
    ShiftLeft (Local0, 0x8, Local0)
    Add (RAM1, Local0, Local0)
    ShiftLeft (Local0, 0x8, Local0)
    Add (RAM0, Local0, Local0)
    Return (Local0)
}

the first version of CRMB computes 0x64646464, while the second version computes the correct 0x0F750064. The least byte seems to just be copied to the other positions.

Cheers
Robert

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

That's with Linux 2.4.22 + ACPI 20030916 + DSDT patch.

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

After some testing, I found that this bug happens with word access as well, and only when the field is not aligned with 8 (in case of dword), which do not make sence as a buggy ASL due to the ByteAcc.

I consider that bug being critical. I'm not sure if that happens for other types other than Index one (that piece of code being shared between 4 kind of OR).

Anyway, most of use done by IndexField is to access CMOS data. I prefer not to think what happens if a write is done, and if the write is buggy as well.

Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Here's a patch.

@@ -346,6 +346,7 @@
 {
 	acpi_status                     status;
 	acpi_integer                    local_value;
+	acpi_integer                    index_field_value;
 
 
 	ACPI_FUNCTION_TRACE_U32 ("ex_field_datum_io", field_datum_byte_offset);

@@ -448,18 +449,22 @@
 
 	case ACPI_TYPE_LOCAL_INDEX_FIELD:
 
+		/* Compute index value to access the current datum */
+
+		index_field_value = (acpi_integer) obj_desc->index_field.value
+			+ field_datum_byte_offset;
 
 		/* Ensure that the index_value is not beyond the capacity of the register */
 
 		if (acpi_ex_register_overflow (obj_desc->index_field.index_obj,
-				  (acpi_integer) obj_desc->index_field.value)) {
+					       index_field_value)) {
 			return_ACPI_STATUS (AE_AML_REGISTER_LIMIT);
 		}
 
 		/* Write the index value to the index_register (itself a region_field) */
 
 		status = acpi_ex_insert_into_field (obj_desc->index_field.index_obj,
-				 &obj_desc->index_field.value,
+				 &index_field_value,
 				 sizeof (obj_desc->index_field.value));
 		if (ACPI_FAILURE (status)) {
 			return_ACPI_STATUS (status);

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf