Skip to contentSkip to conversation

ACPI device for ASUS EEEPC 1101HA not added

DISCUSSION Daniel Mack 6 participants 12 messages Feb 1, 2010 – Mar 1, 2010 ACPI

lore
Share & tools
lore

Daniel Mack

author
#0 lore raw

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

Thanks,
Daniel

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*/
DefinitionBlock ("out/DSDT-0x3f660430-0.aml", "DSDT", 2, "A1359", "A1359000", 0x00000000) {

    [...]

    Scope (_SB)
    {

        [...]

        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A08"))
            Name (_ADR, Zero)

            [...]

            Device (SBRG)
            {

                [...]

                Scope (\_SB)
                {
                    Name (ATKP, Zero)
                    Device (ATKD)
                    {
                        Name (_HID, "ASUS010")
                        Name (_UID, 0x01010100)

                        [...]

The full version of the dump is here:

http://caiaq.de/download/tmp/DSDT-0x3f660430-0.dsl

#1 lore raw

Hi,

you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c like this:

+        /*
+        * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)
+        * is disabled without _OSI(Linux)
+        */
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Asus Eeepc-1101HA",
+       .matches = {

+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
+ },
+ },

Regards,
Andrej

Quoted 55 lines · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

Thanks,
Daniel

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*/
DefinitionBlock ("out/DSDT-0x3f660430-0.aml", "DSDT", 2, "A1359", "A1359000", 0x00000000) {

    [...]

    Scope (_SB)
    {

        [...]

        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A08"))
            Name (_ADR, Zero)

            [...]

            Device (SBRG)
            {

                [...]

                Scope (\_SB)
                {
                    Name (ATKP, Zero)
                    Device (ATKD)
                    {
                        Name (_HID, "ASUS010")
                        Name (_UID, 0x01010100)

                        [...]

The full version of the dump is here:

http://caiaq.de/download/tmp/DSDT-0x3f660430-0.dsl

Quoted 10 lines

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Acpi4asus-user mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/acpi4asus-user

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

author
#2 lore raw
Quoted 5 lines · On Mon, Feb 01, 2010 at 12:06:40PM +0100, [email protected] wrote:

you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c like this:

(quoted diff) +2 -0
+        /*
+        * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)

Review

Quoted 10 lines
(quoted diff) +10 -0
+        * is disabled without _OSI(Linux)
+        */
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Asus Eeepc-1101HA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
+               },
+       },

Great, thanks. That worked. Is that already queued anywhere or do you want me to send a proper patch?

Daniel

Quoted 14 lines
Quoted 12 lines · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

Thanks,
Daniel

#3 lore raw

Hi,

there was a patch for 1005ha and 1000h (or so), but i can't find it in the repository anymore. I miss it in 2.6.33-rc* too.

acpi/blacklist: enable OSI(Linux) on newer eeepc
patch from git://git.iksaif.net/acpi4asus.git.

Regards,
Andrej

Quoted 17 lines · Daniel Mack
Quoted 5 lines · On Mon, Feb 01, 2010 at 12:06:40PM +0100…

you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c like this:

(quoted diff) +2 -0
+        /*
+        * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)

Review

Quoted 10 lines
(quoted diff) +10 -0
+        * is disabled without _OSI(Linux)
+        */
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Asus Eeepc-1101HA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
+               },
+       },
Quoted 20 lines

Great, thanks. That worked. Is that already queued anywhere or do you want me to send a proper patch?

Daniel

Quoted 14 lines
Quoted 12 lines · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

Thanks,
Daniel

------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com

reviewer
#4 lore raw
In reply to [email protected]
Quoted 7 lines · On Mon, 1 Feb 2010, [email protected] wrote:

Hi,

you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c like this:

(quoted diff) +2 -0
+        /*
+        * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)

Review

Quoted 10 lines
(quoted diff) +10 -0
+        * is disabled without _OSI(Linux)
+        */
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Asus Eeepc-1101HA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
+               },
+       },

Not necessarily the right fix. We have gone to a lot of trouble to discourage BIOS vendors from depending on the ill-defined OSI(Linux), so I hesitate to invoke it -- even for a workaround.

The problem at hand is that ASUS010 is not enabled for an OS that claims compatibility with Win7 (MSOS() == MSW7) below.

                Scope (\_SB)
                {
                    Name (ATKP, Zero)
                    Device (ATKD)
                    {
                        Name (_HID, "ASUS010")
                        Name (_UID, 0x01010100)
                        Method (_STA, 0, NotSerialized)
                        {
                            If (LEqual (MSOS (), MSW7))
                            {
                                Return (Zero)
                            }
                            Else
                            {
                                Return (0x0F)
                            }

                            Return (Zero)
                            Return (0x0F)
                        }

(heh, see any indication of lack of quality in this code?:-)

MSOS() does this:

                    Scope (\)
                    {
                        Name (OSLX, 0x10)
                        Name (OSMS, 0x20)
                        Name (MS98, 0x21)
                        Name (MSME, 0x22)
                        Name (MS2K, 0x23)
                        Name (MSXP, 0x24)
                        Name (MSVT, 0x25)
                        Name (MSW7, 0x26)
                        Name (OSFG, Ones)
                        Method (MSOS, 0, NotSerialized)
                        {
                            If (LNotEqual (OSFG, Ones))
                            {
                                Return (OSFG)
                            }

                            Store (Zero, OSFG)
                            If (CondRefOf (_OSI, Local0))
                            {
                                If (_OSI ("Windows 2001"))
                                {
                                    Store (MSXP, OSFG)
                                }

                                If (_OSI ("Windows 2001 SP1"))
                                {
                                    Store (MSXP, OSFG)
                                }

                                If (_OSI ("Windows 2001 SP2"))
                                {
                                    Store (MSXP, OSFG)
                                }

                                If (_OSI ("Windows 2006"))
                                {
                                    Store (MSVT, OSFG)
                                }

                                If (_OSI ("Windows 2009"))
                                {
                                    Store (MSW7, OSFG)
                                }

                                If (_OSI ("Linux"))
                                {
                                    Store (OSLX, OSFG)
                                }

                                Return (OSFG)
                            }
                            Else

So I expect if you apply no patch, but boot with 'acpi_osi="!Windows 2009"' then that would also work properly, as OSFG above will be set to "MSVT" instead of "OSLX".

Looking through the DSDT, there are no references to OSLX or MSVT, or MSXP, for that matter. However, there is an additional reference to MSV7 in the temperature reading part of thermal zone TZ00, that looks like some sort of OS-specific initialization, perhaps a workaround. So also check that /proc/acpi/thermal_zone/*/temperature still work before and after.

thanks,
-Len Brown, Intel Open Source Technology Center

#5 lore raw
Quoted 120 lines · Len Brown
Quoted 5 lines · On Mon, 1 Feb 2010, [email protected] wrote:

Hi,

you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c like this:

Quoted 12 lines

+        /*
+        * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)
+        * is disabled without _OSI(Linux)
+        */
+       {
+       .callback = dmi_enable_osi_linux,
+       .ident = "Asus Eeepc-1101HA",
+       .matches = {
+                    DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
+                    DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
+               },
+       },

Not necessarily the right fix.  We have gone to a lot of trouble to discourage BIOS vendors from depending on the ill-defined OSI(Linux), so I hesitate to invoke it -- even for a workaround.

The problem at hand is that ASUS010 is not enabled for an OS that claims compatibility with Win7 (MSOS() == MSW7) below.

               Scope (\_SB)
               {
                   Name (ATKP, Zero)
                   Device (ATKD)
                   {
                       Name (_HID, "ASUS010") Name (_UID, 0x01010100) Method (_STA, 0, NotSerialized) {
                           If (LEqual (MSOS (), MSW7)) {
                               Return (Zero) }
                           Else
                           {
                               Return (0x0F) }

                           Return (Zero)
                           Return (0x0F)
                       }

(heh, see any indication of lack of quality in this code?:-)

MSOS() does this:

                   Scope (\)
                   {
                       Name (OSLX, 0x10)
                       Name (OSMS, 0x20)
                       Name (MS98, 0x21)
                       Name (MSME, 0x22)
                       Name (MS2K, 0x23)
                       Name (MSXP, 0x24)
                       Name (MSVT, 0x25)
                       Name (MSW7, 0x26)
                       Name (OSFG, Ones) Method (MSOS, 0, NotSerialized) {
                           If (LNotEqual (OSFG, Ones)) {
                               Return (OSFG) }

                           Store (Zero, OSFG)
                           If (CondRefOf (_OSI, Local0)) {
                               If (_OSI ("Windows 2001")) {
                                   Store (MSXP, OSFG) }

                               If (_OSI ("Windows 2001 SP1")) {
                                   Store (MSXP, OSFG) }

                               If (_OSI ("Windows 2001 SP2")) {
                                   Store (MSXP, OSFG) }

                               If (_OSI ("Windows 2006")) {
                                   Store (MSVT, OSFG) }

                               If (_OSI ("Windows 2009")) {
                                   Store (MSW7, OSFG) }

                               If (_OSI ("Linux")) {
                                   Store (OSLX, OSFG) }

                               Return (OSFG)
                           }
                           Else

So I expect if you apply no patch, but boot with 'acpi_osi="!Windows 2009"' then that would also work properly, as OSFG above will be set to "MSVT" instead of "OSLX".

Looking through the DSDT, there are no references to OSLX or MSVT, or MSXP, for that matter.  However, there is an additional reference to MSV7 in the temperature reading part of thermal zone TZ00, that looks like some sort of OS-specific initialization, perhaps a workaround.  So also check that /proc/acpi/thermal_zone/*/temperature still work before and after.

Quoted 3 lines

thanks,
-Len Brown, Intel Open Source Technology Center

This kind of things is present on all newer eeepc.
I tried to contact asus about that, without real success and it is likely that the xandros distribribution
shipped with some eeepc include an acpi blacklisiting patch.

The thing is that on win7 ASUS010 is disabled, but an equivalent wmi interface is enable, and it could
be possible to write a driver for it. Now, someone need to write it, or send me a free 1005HA so I can do it :).

If nothing is done for 2.6.34, we may need to envisage some blacklisting :/. Thanks

Signature · 2 lines
Corentin Chary
http://xf.iksaif.net
#7 lore raw
In reply to Daniel Mack
Quoted 8 lines · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

eeepc is handled in eeepci-laptop driver.

~/src/linux-2.6$ grep ASUS010 drivers/platform/*/*
drivers/platform/x86/eeepc-laptop.c:#define EEEPC_ACPI_HID "ASUS010"

thanks,
rui

Quoted 50 lines

Thanks,
Daniel

/*
* Intel ACPI Component Architecture
* AML Disassembler version 20090521
*/
DefinitionBlock ("out/DSDT-0x3f660430-0.aml", "DSDT", 2, "A1359", "A1359000", 0x00000000) {

    [...]

    Scope (_SB)
    {

        [...]

        Device (PCI0)
        {
            Name (_HID, EisaId ("PNP0A08"))
            Name (_ADR, Zero)

            [...]

            Device (SBRG)
            {

                [...]

                Scope (\_SB)
                {
                    Name (ATKP, Zero)
                    Device (ATKD)
                    {
                        Name (_HID, "ASUS010")
                        Name (_UID, 0x01010100)

                        [...]

The full version of the dump is here:

http://caiaq.de/download/tmp/DSDT-0x3f660430-0.dsl

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

author
#8 lore raw
Quoted 6 lines · Zhang Rui
Quoted 5 lines · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This is because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

Quoted 7 lines
Quoted 3 lines

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

eeepc is handled in eeepci-laptop driver.

~/src/linux-2.6$ grep ASUS010 drivers/platform/*/*
drivers/platform/x86/eeepc-laptop.c:#define EEEPC_ACPI_HID "ASUS010"

Yes, that I know. The driver was just unable to match the device because it was not detected by the ACPI core. Works now with the patch Andrej sent. I would still like to make sure it's getting merged mainline sooner or later.

Thanks,
Daniel

#9 lore raw
Quoted 25 lines

-----Original Message-----
From: Daniel Mack [mailto:[email protected]]
Sent: Tuesday, February 02, 2010 10:10 AM
To: Zhang, Rui
Cc: [email protected]; [email protected]; [email protected]
Subject: Re: ACPI device for ASUS EEEPC 1101HA not added

Quoted 2 lines · Zhang Rui
Quoted 1 line · Daniel Mack

On my new 1101HA Eeepc, the special function keys do not work. This

is

Quoted 11 lines
Quoted 7 lines

because the asus-laptop driver fails to match the ACPI device named "ASUS010". However, acpidump tells me a device with that name does actually exist - the (simplified) disassembly of the DSDT is below.

It looks like the gigantic parser state machine fails to add that device for whatever reason. Any ideas how to fix that?

eeepc is handled in eeepci-laptop driver.

~/src/linux-2.6$ grep ASUS010 drivers/platform/*/* drivers/platform/x86/eeepc-laptop.c:#define EEEPC_ACPI_HID

Quoted 8 lines
	"ASUS010"

Yes, that I know. The driver was just unable to match the device because
it was not detected by the ACPI core. Works now with the patch Andrej sent. I would still like to make sure it's getting merged mainline sooner or later.

Oh, can you give a link to this patch please?

Thanks,
rui

Quoted 2 lines

Thanks,
Daniel

author
#10 lore raw
Quoted 7 lines · Rui
Quoted 7 lines · Zhang Rui
Quoted 4 lines

eeepc is handled in eeepci-laptop driver.

~/src/linux-2.6$ grep ASUS010 drivers/platform/*/* drivers/platform/x86/eeepc-laptop.c:#define EEEPC_ACPI_HID

	"ASUS010"
Quoted 7 lines
Quoted 6 lines

Yes, that I know. The driver was just unable to match the device because
it was not detected by the ACPI core. Works now with the patch Andrej sent. I would still like to make sure it's getting merged mainline sooner or later.

Oh, can you give a link to this patch please?

http://permalink.gmane.org/gmane.linux.acpi.acpi4asus.user/3781

reviewer
#11 lore raw
Quoted 14 lines · Daniel Mack
Quoted 13 lines · Rui
Quoted 13 lines · Zhang Rui
Quoted 4 lines

eeepc is handled in eeepci-laptop driver.

~/src/linux-2.6$ grep ASUS010 drivers/platform/*/* drivers/platform/x86/eeepc-laptop.c:#define EEEPC_ACPI_HID

	"ASUS010"

Yes, that I know. The driver was just unable to match the device because
it was not detected by the ACPI core. Works now with the patch Andrej sent. I would still like to make sure it's getting merged mainline sooner or later.

Quoted 3 lines
Quoted 1 line

Oh, can you give a link to this patch please?

http://permalink.gmane.org/gmane.linux.acpi.acpi4asus.user/3781

boot the eeepc with acpi_osi="!Windows 2009"
until a WMI driver is written to handle this windows-specific BIOS.

thanks,
Len Brown, Intel Open Source Technology Center