bug report: multi-byte access in indexfields broken

bug report: multi-byte access in indexfields broken

[Robert Vollmert]

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

Re: bug report: multi-byte access in indexfields broken

[Robert Vollmert]

> 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.

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

Re: bug report: multi-byte access in indexfields broken

[Ducrot Bruno]

On Sun, Sep 21, 2003 at 10:05:25PM +0200, Robert Vollmert wrote:
> 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)
> }
> 

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

Re: bug report: multi-byte access in indexfields broken [patch]

[Robert Vollmert]

Here's a patch.

--- exfldio.c.orig	2003-09-22 18:22:09.000000000 +0200
+++ exfldio.c	2003-09-22 19:16:11.000000000 +0200
@@ -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

RE: bug report: multi-byte access in indexfields broken

[Li, Shaohua]

Hi,
    I opened a track in OSDL 1260. Please add you in the CC list.

Thanks,
Shaohua


-----Original Message-----
From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Ducrot Bruno
Sent: 2003年9月22日 22:03
To: Robert Vollmert
Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Subject: Re: [ACPI] bug report: multi-byte access in indexfields broken

On Sun, Sep 21, 2003 at 10:05:25PM +0200, Robert Vollmert wrote:
> 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)
> }
> 

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
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


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