Strange interpreter behaviour

Hey,
I got an ASUS M6, which contains some strange _CST related ASL code. In the _CST method there is a check, if \_SB.INV7 is set :

                If (\_SB.INV7)
                {
                    Return (NOC3)
                }
This seems to always return true. There is also the method \_GPE:_L17 which just inverts \_SB.INV7 and sends a signal to refetch the CST Object :
          Method (_L17, 0, NotSerialized)
        {
            If (\_SB.INV7)
            {
                Store (0x00, \_SB.INV7)
            }
            Else
            {
                Store (0x01, \_SB.INV7)
            }

            Notify (\_PR.CPU1, 0x81)
        }

Now I called the _L17 method manually :
echo "0:\\_GPE:_L17:\\_GPE:_L17:10001:1" > /proc/acpi/hotkey/poll_config echo "10001:0:1:0" > /proc/acpi/hotkey/action

What I noticed is that every time I call the action, my C-State usage counter gets reset to zero. From that behaviour I would follow, that the L17 method was executed and the CST Object was refetched. So there seems to be an error in setting the \_SB.INV7 bit/register/whatever. (I assume 0 is false an 1 is true in ASL if-clauses ?) Greets
Janosch
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Sound like \_SB.INV7 is a bit into a GPIO.
More, the associated OR is defined like that:

	OperationRegion (GPIO, SystemIO, IO2B, 0x40) 

Note that IO2B is given here:

    OperationRegion (BIOS, SystemMemory, 0x1FF50064, 0xFF)
    Field (BIOS, ByteAcc, NoLock, Preserve)
    {
        SS1,    1,
        SS2,    1,
        SS3,    1,
        SS4,    1,
        Offset (0x01),
        IOST,   16,
        SPIO,   16,
        PMBS,   16,
        PMLN,   8,
        SMBS,   16,
        SMLN,   8,
        IO1B,   16,
        IO1L,   8,
        IO2B,   16,
        IO2L,   8,
        TOPM,   32,
        ROMS,   32,

Therefore one think to check is that IO2B is set correctly to point to the GPIO's, then look if the GPIO is configured as a GPO (not as a GPI).

For checking if IO2B is correct:
sudo dd if=/dev/mem bs=1c skip=536150130 count=2 | hexdump

./acpixtract FACP < acpidump.out | ./acpitbl

where acpidump.txt is the output from ./acpidump. I assume you know what I'm talking about reading the bugzilla report, or else do something like that:

wget ftp://ftp.kernel.org//pub/linux/kernel/people/lenb/acpi/utils/pmtools-20050926.tar.bz2 tar xjvfp pmtools-20050926.tar.bz2
cd pmtools
make
cd acpidump
sudo ./acpidmp > acpidmp.out

I think the value given by the 'sudo dd' above should correspond to the
GPE0_BLK: field from the ./acpitbl above.

For checking if the register where the INV7 is defined is configured as a GPO, well I have to know the ouput from 'lspci -v -xxx -s"the southbridge"'

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Here it get's strange :
scotchmobil scotch # dd if=/dev/mem bs=1c skip=536150130 count=2
dd: reading `/dev/mem': Bad address
0+0 records in
0+0 records out

Uhm as far as I know "the southbridge" is is the Intel 82801. There are more than one 82801 devices, so I just post all except the USB devices, sorry for that :

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=02, sec-latency=64
I/O behind bridge: 00001000-00001fff
Memory behind bridge: ff900000-ff9fffff
Prefetchable memory behind bridge: dea00000-deafffff
00: 86 80 48 24 07 01 80 80 83 00 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 02 02 40 10 10 80 02
20: 90 ff 90 ff a0 de a0 de 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 00
40: 02 28 20 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 02 74 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 10 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 01 00 02 00 00 00 c0 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 2c 48

00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
Flags: bus master, medium devsel, latency 0
00: 86 80 cc 24 0f 01 80 02 03 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 01 05 00 00 10 00 00 00
60: 0b 04 0a 05 90 00 00 00 80 80 80 0a 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 28 03 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 80 02 02 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 02 28 00 00 02 cf 00 00 04 00 00 00 00 00 00 00
e0: 12 00 00 c0 00 00 06 34 33 22 11 00 00 00 67 45
f0: 00 00 01 00 00 00 00 00 60 0f 03 00 00 00 80 02

00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc. Unknown device 1869
Flags: bus master, medium devsel, latency 0, IRQ 10
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at <unassigned>
I/O ports at ffa0 [size=16]
Memory at 30000000 (32-bit, non-prefetchable) [size=1K]
00: 86 80 ca 24 07 00 80 02 03 8a 01 01 00 00 00 00
10: 01 00 00 00 01 00 00 00 01 00 00 00 01 00 00 00
20: a1 ff 00 00 00 00 00 30 00 00 00 00 43 10 69 18
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
40: 07 e3 07 e3 00 00 00 00 05 00 01 02 00 00 00 00
50: 00 00 00 00 31 14 00 00 00 00 00 00 00 00 00 00
60: 08 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 00 00

00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
Subsystem: ASUSTeK Computer Inc. Unknown device 1869
Flags: medium devsel
I/O ports at 0540 [size=32]
00: 86 80 c3 24 01 00 80 02 03 00 05 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 41 05 00 00 00 00 00 00 00 00 00 00 43 10 69 18
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
40: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 60 0f 00 00 00 00 00 00

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

There is physical 512Mo RAM, isn't there? Or the DSDT have been overriden?
How about a 'cat /proc/iomem'?

Bruno Ducrot

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jup, here is 512 MB of RAM, the DSDT hasen't been overidden.

scotch@scotchmobil ~ $ cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000cffff : Video ROM
000f0000-000fffff : System ROM
00100000-1ff3ffff : System RAM
00100000-004853d6 : Kernel code
004853d7-00583193 : Kernel data
1ff40000-1ff4ffff : ACPI Tables
1ff50000-1fffffff : ACPI Non-volatile Storage
30000000-300003ff : 0000:00:1f.1
32000000-33ffffff : PCI CardBus #03
34000000-35ffffff : PCI CardBus #03
36000000-37ffffff : PCI CardBus #07
38000000-39ffffff : PCI CardBus #07
ce900000-de9fffff : PCI Bus #01
d0000000-d7ffffff : 0000:01:00.0

    d0000000-d7ffffff : radeon

dea00000-deafffff : PCI Bus #02
e0000000-efffffff : 0000:00:00.0
ff800000-ff8fffff : PCI Bus #01
ff8c0000-ff8dffff : 0000:01:00.0
ff8f0000-ff8fffff : 0000:01:00.0

    ff8f0000-ff8fffff : radeon
ff900000-ff9fffff : PCI Bus #02
  ff900000-ff900fff : 0000:02:01.0
    ff900000-ff900fff : yenta_socket
  ff901000-ff901fff : 0000:02:01.1
    ff901000-ff901fff : yenta_socket
  ff9ee000-ff9eefff : 0000:02:02.0
  ff9ef800-ff9effff : 0000:02:01.2
    ff9ef800-ff9effff : ohci1394
  ff9f0000-ff9fffff : 0000:02:00.0
    ff9f0000-ff9fffff : tg3

ffaff400-ffaff4ff : 0000:00:1f.5
ffaff400-ffaff4ff : Intel 82801DB-ICH4
ffaff800-ffaff9ff : 0000:00:1f.5
ffaff800-ffaff9ff : Intel 82801DB-ICH4
ffaffc00-ffafffff : 0000:00:1d.7
ffaffc00-ffafffff : ehci_hcd
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Ok. Well maybe that little tool attached could give us the information.

Bruno Ducrot

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

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/stat.h>

int main(void)

{
	int fd;
	off_t c;
	unsigned char t[2];

	fd = open("/dev/mem", O_RDONLY);
	if (fd < 0) {
		perror("open /dev/mem");
		exit(1);
	}

	/*
	 * SS1,    1,	<- 0
	 * SS2,    1,
	 * SS3,    1,
	 * SS4,    1,
	 * Offset (0x01),
	 * IOST,   16,	<-   1, 2
	 * SPIO,   16,	<-   3, 4
	 * PMBS,   16,	<-   5, 6
	 * PMLN,   8,	<-   7
	 * SMBS,   16,	<-   8, 9
	 * SMLN,   8,	<-   A
	 * IO1B,   16,	<-   B, C
	 * IO1L,   8,	<-   D
	 * IO2B,   16,	<-   E, F
	 * IO2L,   8,
	 * TOPM,   32,
	 * ROMS,   32,
	 */

	c = lseek(fd, 0x1FF50064 + 0xE, SEEK_SET);
	if (c != 0x1FF50064 + 0xE) {
		perror("lseek");
		exit(1);
	}

	if (read(fd, t, 2) != 2) {
		perror("read");
		close(fd);
		exit(1);
	}
	close(fd);

	printf("0x%x\n", ((t[0] & 0xff) << 8) | (t[1] & 0xff));

	return 0;
}

Nope, scotchmobil pmtools # ./a.out
read: Bad address

-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Sometimes I'm stupid. Try this version instead.

Bruno Ducrot

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

#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>

int main(void)

{
	int fd;
	off_t c;
	unsigned char *p;

	fd = open("/dev/mem", O_RDONLY);
	if (fd < 0) {
		perror("open /dev/mem");
		exit(1);
	}

	/*
	 * SS1,    1,	<- 0
	 * SS2,    1,
	 * SS3,    1,
	 * SS4,    1,
	 * Offset (0x01),
	 * IOST,   16,	<-   1, 2
	 * SPIO,   16,	<-   3, 4
	 * PMBS,   16,	<-   5, 6
	 * PMLN,   8,	<-   7
	 * SMBS,   16,	<-   8, 9
	 * SMLN,   8,	<-   A
	 * IO1B,   16,	<-   B, C
	 * IO1L,   8,	<-   D
	 * IO2B,   16,	<-   E, F
	 * IO2L,   8,
	 * TOPM,   32,
	 * ROMS,   32,
	 */

	p = mmap(NULL, 1024, PROT_READ, MAP_SHARED, fd, 0x1FF50000);
	if (p == MAP_FAILED) {
		perror("mmap");
		exit(1);
	}
	close(fd);
	printf("0x%x\n", ((p[0x64 + 0xf] & 0xff) << 8) | (p[0x64 + 0xe] & 0xff));
	munmap(p, 1024);

	return 0;
}

Okay, this worked,
the outprut from your little programm was 0x500,
but it should be

GPE0_BLK:         0x00000428
GPE1_BLK:         0x00000000

So is this an error in ACPI-CA or in my DSDT ?

ftp://download.intel.com/design/mobile/datashts/25233701.pdf )
and the lspci -xxx I've requested, we can look that, for the isa bridge, we can see that 0x500 is the base address for the GPIO configuration registers.

The lspci show us:
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
Flags: bus master, medium devsel, latency 0
00: 86 80 cc 24 0f 01 80 02 03 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 01 04 00 00 10 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 01 05 00 00 10 00 00 00
60: 0b 04 0a 05 90 00 00 00 80 80 80 0a 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff fc 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 28 03 00 00 00 00 00 00 0d 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 80 02 02 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 02 28 00 00 02 cf 00 00 04 00 00 00 00 00 00 00
e0: 12 00 00 c0 00 00 06 34 33 22 11 00 00 00 67 45
f0: 00 00 01 00 00 00 00 00 60 0f 03 00 00 00 80 02

The GPIO base address is at 0x58-0x5b (see page 305).

learn that the ACPI node INV7 correspond to the 8th bit of the 'GPIO signal invert (GPI_INV)' register.

Therefore actually INV7 control somehow we'll treat what happens under the GPE0_BLK, but do not modify it. (I must confess I don't see why the ODM designed that stuff like this).

At the description of this register, and for bit 8, we'll see that setting this bit will have no effect if the corresponding GPIO is set as an output. We'll therefore shall check if that is the problem.

Could you please (again, sorry!) run the next tool attached? This would help to progress a little bit further.

NB: please compile it with -O flags at least:

gcc -O -W -Wall scan_gpio_ctl.c -o scan_gpio_ctl sudo ./scan_gpio

Bruno Ducrot

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

#include <stdio.h>
#include <stdlib.h>

#include <sys/io.h>

#define GPIO_BASE 0x0500

int main(void)

{
	int i;
	int gpio_base = GPIO_BASE;

	if (iopl(3)) {
		perror("iopl");
		exit(1);
	}

	printf("     00 01 02 03 04 05 06 07   08 09 0a 0b 0c 0d 0e 0f");
	for (i = 0; i < 64; ++i) {
		switch (i % 16) {
		case 0:
			printf("\n%.4x ", gpio_base + i);
			break;
		case 8:
			printf("  ");
			break;
		default:
			break;
		}
		printf("%.2x ", inb(gpio_base + i));
	}
	printf("\n");

	return 0;
}

Don't be sorry to debug my notebook ;-)
run the next tool attached?

scotchmobil pmtools # ./scan_gpio_ctl

     00 01 02 03 04 05 06 07   08 09 0a 0b 0c 0d 0e 0f
0500 bf 39 00 1a ff ff 00 00   00 00 00 00 00 00 01 08
0510 00 00 00 00 00 00 00 00   00 00 00 02 00 00 00 00
0520 00 00 00 00 00 00 00 00   00 00 00 00 88 39 00 00
0530 ff 0f 00 00 06 04 00 00   8f 04 00 00 00 00 00 00