Bug 15528

Created attachment 25487 [details]
acpidump

Created attachment 25488 [details]
lslpci

Created attachment 25489 [details]
/proc/interupts

Created attachment 25490 [details]
xrandr properties

Created attachment 25491 [details]
dsdt

please attach the output of "ls -l /sys/class/backlight/acpi_video0/"

Created attachment 25521 [details]
ls -l /sys/class/backlight/acpi_video0

> lrwxrwxrwx 1 root root    0 Mar 15 09:58 [0m[01;36mdevice[0m -> 
> [01;34m../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/device:06[0m

it seems that this file is corrupted.

please attach the output of "cat //sys/class/backlight/acpi_video0/device/path"

(In reply to comment #8)
> > lrwxrwxrwx 1 root root    0 Mar 15 09:58 [0m[01;36mdevice[0m -> 
> >
> [01;34m../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/device:06[0m
> 
> it seems that this file is corrupted.
> 
> please attach the output of "cat
> //sys/class/backlight/acpi_video0/device/path"

Sorry, it seems that the strange characters are escape characters that are to color the output.  Attached is the output of path:

\_SB_.PCI0.GFX0.DD02

noumena acpi_video0 # ls -l /sys/class/backlight/acpi_video0/
total 0
-r--r--r-- 1 root root 4096 Mar 15 18:12 actual_brightness
-rw-r--r-- 1 root root 4096 Mar 15 18:13 bl_power
-rw-r--r-- 1 root root 4096 Mar 15 18:12 brightness
lrwxrwxrwx 1 root root    0 Mar 15 18:12 device -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:01/device:06
-r--r--r-- 1 root root 4096 Mar 15 18:12 max_brightness
drwxr-xr-x 2 root root    0 Mar 15 18:13 power
lrwxrwxrwx 1 root root    0 Mar 15 18:12 subsystem -> ../../../../class/backlight
-rw-r--r-- 1 root root 4096 Mar 15 18:12 uevent

        Method (_BCM, 1, NotSerialized)
        {
            // calculate the value that should be set to EC
            ...
            If (^^^LPCB.EC0.BNCM)
            {
                If (^^^LPCB.EC0.ACST)
                {
                    Store (Local1, ^^^LPCB.EC0.BNAC)
                }
                Else
                {
                    Store (Local1, ^^^LPCB.EC0.BNDC)
                }
            }
            Else
            {
                Store (Local1, ^^^LPCB.EC0.BNAC)
            }
        }

Now it seems that everything goes well.
1. ACPI video driver invoke the _BCM properly.
2. Linux/ACPI runs the AML code correctly.
but the backlight fails to change.


As the backlight control is done via EC,
Alexey, could this be an EC firmware problem?

*** Bug 15513 has been marked as a duplicate of this bug. ***

(In reply to comment #11)

> Now it seems that everything goes well.
> 1. ACPI video driver invoke the _BCM properly.
> 2. Linux/ACPI runs the AML code correctly.
> but the backlight fails to change.
> 
> 
> As the backlight control is done via EC,
> Alexey, could this be an EC firmware problem?


If this a problem with the BIOS, or the firmware, where should a bug be filed to have the issue resolved?

If this is a firmware bug, the problem also exists in Windows, and this usually means that there will be a BIOS upgrade available later.

But controlling brightness works fine on windows at least on my laptop. Even works up till grub screen

then what if you boot with boot option "acpi_backlight=vendor" and load the acer-wmi driver?

(In reply to comment #16)
> then what if you boot with boot option "acpi_backlight=vendor" and load the
> acer-wmi driver?

option acpi_backlight=vendor does not work. I have following message in the dmesg


So I mailed Carlos Corbacho regarding the acer-wmi and following was his response

> 2) I see the following message in my dmesg at the time of booting
>
> acer-wmi: Acer Laptop ACPI-WMI Extras
> acer-wmi: Unable to detect available WMID devices

This looks like a bug in acer-wmi - AFAICT, it should be able to cope with
your laptop. Something with the supported device auto-detection is failing
(the DSDT looks a bit weird compared to the ones I'm used to, but AFAICT,
everything should be supported).

How recent a kernel are you running - does /sys/class/wmi exist, and what's
the contents of that directory if it does?

re-assign to carlos

Created attachment 25700 [details]
patch: evaluate EC _REG explicitly

could you please try this patch?

(In reply to comment #19)
> Created an attachment (id=25700) [details]
> patch: evaluate EC _REG explicitly
> 
> could you please try this patch?

OK.  Tried the patch.  Doesn't seem to solve the problem.  I have noticed that my use of the function keys for brightness now change the settings in xrandr --prop and xbacklight, but the backlight brightness does not change visibly.

Is there any output that would be useful?  attached is dmesg and /var/log/messages

If anything else is useful, let me know.

Created attachment 25702 [details]
dmesg

Created attachment 25703 [details]
grep -i acpi /var/log/messages

the whole syslog file is too large to attach here.  this is all references to acpi

(In reply to comment #19)
> Created an attachment (id=25700) [details]
> patch: evaluate EC _REG explicitly
> 
> could you please try this patch?

I did a grep of the logfile looking for AAAAA and BBBBB explicitly, because the kernel log output doesn't include ACPI (my mistake for the first log attachment here.)  There is an instance of BBBB, here are the lines that immediately surround it:

  70725 Mar 24 23:41:49 noumena kernel: ACPI: bus type pci registered
  70726 Mar 24 23:41:49 noumena kernel: dca service started, version 1.12.1
  70727 Mar 24 23:41:49 noumena kernel: PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
  70728 Mar 24 23:41:49 noumena kernel: PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in E820
  70729 Mar 24 23:41:49 noumena kernel: PCI: Using configuration type 1 for base access
  70730 Mar 24 23:41:49 noumena kernel: bio: create slab <bio-0> at 0
  70731 Mar 24 23:41:49 noumena kernel: ACPI: EC: Look up EC in DSDT
  70732 Mar 24 23:41:49 noumena kernel: ACPI: BIOS _OSI(Linux) query ignored
  70733 Mar 24 23:41:49 noumena kernel: BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
  70734 Mar 24 23:41:49 noumena kernel: ACPI: Interpreter enabled
  70735 Mar 24 23:41:49 noumena kernel: ACPI: (supports S0 S3 S4 S5)
  70736 Mar 24 23:41:49 noumena kernel: ACPI: Using IOAPIC for interrupt routing
  70737 Mar 24 23:41:49 noumena kernel: ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
  70738 Mar 24 23:41:49 noumena kernel: ACPI: No dock devices found.
  70739 Mar 24 23:41:49 noumena kernel: \_SB_.PCI0:_OSC invalid UUID
  70740 Mar 24 23:41:49 noumena kernel: _OSC request data:1 8 1f 
  70741 Mar 24 23:41:49 noumena kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)


If there is more that I can provide, let me know.

I can confirm the same behaviour as in comment 20

Created attachment 25718 [details]
dmesg after applying patch from comment 19

(In reply to comment #20)
> (In reply to comment #19)
> I have noticed that
> my use of the function keys for brightness now change the settings in xrandr
> --prop and xbacklight, but the backlight brightness does not change visibly.
> 
This also happens in the kernel without the patch, right?

(In reply to comment #26)
> (In reply to comment #20)
> > (In reply to comment #19)
> > I have noticed that
> > my use of the function keys for brightness now change the settings in
> xrandr
> > --prop and xbacklight, but the backlight brightness does not change
> visibly.
> > 
> This also happens in the kernel without the patch, right?

I am sorry for the wrong information in my previous comment 24. I can change the values with function keys with out the patch

(In reply to comment #26)
> (In reply to comment #20)
> > (In reply to comment #19)
> > I have noticed that
> > my use of the function keys for brightness now change the settings in
> xrandr
> > --prop and xbacklight, but the backlight brightness does not change
> visibly.
> > 
> This also happens in the kernel without the patch, right?

That is correct; I didn't mean to create confusion. My apologies.

Assigning this bug back to Zhang Rui - this is an ACPI video bug, not an acer-wmi bug.

The fact that acer-wmi doesn't load on this hardware is a separate bug - even if it did load, it would hand over control of the backlight to the ACPI video driver, so doesn't have any bearing here.

Sachin,
If I'm right, I think you're using a gateway laptop, and have another bug report for the backlight issue on your laptop, right?
So you don't need to comment here because backlight issues are always HARDWARE DEPENDENT. The problem on your laptops is quite different and your comments always make me confused. :p

Kyle,
I run out of my ideas about this.
It seems that Linux/ACPI video driver is working normal. It invokes the firmware code to change the backlight, but unfortunately this fails. It doesn't look like a software problem to me.
Is there a windows partition on this laptop?
If yes, it would be great if you can verify if the problem also exists in windows.

Zhang,

But you have closed other bug(#15528) as duplicate of this bug.

Regards,
Sachin.

(In reply to comment #30)
> Sachin,
> If I'm right, I think you're using a gateway laptop, and have another bug
> report for the backlight issue on your laptop, right?
> So you don't need to comment here because backlight issues are always
> HARDWARE
> DEPENDENT. The problem on your laptops is quite different and your comments
> always make me confused. :p
> 
> Kyle,
> I run out of my ideas about this.
> It seems that Linux/ACPI video driver is working normal. It invokes the
> firmware code to change the backlight, but unfortunately this fails. It
> doesn't
> look like a software problem to me.
> Is there a windows partition on this laptop?
> If yes, it would be great if you can verify if the problem also exists in
> windows.

Unfortunately, there is no windows partition on this machine.  I will not be able to test in Windows.  Perhaps it requires a bios upgrade?  I'm not sure.  If you have any ideas of stuff that I could try, let me know.

(In reply to comment #32)
> (In reply to comment #30)
> > Sachin,
> > If I'm right, I think you're using a gateway laptop, and have another bug
> > report for the backlight issue on your laptop, right?
> > So you don't need to comment here because backlight issues are always
> HARDWARE
> > DEPENDENT. The problem on your laptops is quite different and your comments
> > always make me confused. :p
> > 
> > Kyle,
> > I run out of my ideas about this.
> > It seems that Linux/ACPI video driver is working normal. It invokes the
> > firmware code to change the backlight, but unfortunately this fails. It
> doesn't
> > look like a software problem to me.
> > Is there a windows partition on this laptop?
> > If yes, it would be great if you can verify if the problem also exists in
> > windows.
> 
> Unfortunately, there is no windows partition on this machine.  I will not be
> able to test in Windows.  Perhaps it requires a bios upgrade?  I'm not sure. 
> If you have any ideas of stuff that I could try, let me know.

Is it of use to note that I can change the brightness of the screen when I am on the grub screen and when I am on the BIOS screen?  When the drm loads and it changes the resolution the brightness maxes out and i can no longer change it.

(In reply to comment #31)
> Zhang,
> 
> But you have closed other bug(#15528) as duplicate of this bug.
> 
oops, sorry, I thought the problem on your laptop (bug #15513) is a duplicate of bug #15204.

So you can change the backlight via hotkey but you can not change the backlight via the sysfs I/F, right?
did you load the ACPI wmi driver when poking hotkeys?
If yes, will you please verify if it still works without that driver?

(In reply to comment #33)
> When the drm loads and it
> changes the resolution the brightness maxes out and i can no longer change
> it.

so what if you boot with boot option nomodeset?
can you change the backlight via hotkeys when ACPI wmi driver loaded?

Loaded with "nomodeset" keeps the brightness at the same level as it was at the grub/BIOS screen, cannot change the level.  An interesting find though: use of function keys changes the value of /sys/class/backlight/acpi_video0/actual_brightness as expected, but the value of /proc/acpi/video/GFX0/DD02/brightness does not update until I have read from actual_brightness?  Perhaps nothing too important there, but an interesting find, nonetheless.

On attempted loading of acer-wmi, dmesg reports: 
acer-wmi: Acer Laptop ACPI-WMI Extras
acer-wmi: Unable to detect available WMID devices

no, it's wmi driver, not the acer wmi driver.
try "modprobe wmi"

(In reply to comment #37)
> no, it's wmi driver, not the acer wmi driver.
> try "modprobe wmi"

Sorry for the confusion.  After having loaded the wmi module, the use of the brightness keys shows unhandled ACPI events in my /var/log/messages :

Mar 29 07:44:37 noumena logger: ACPI event unhandled: video DD02 00000087 00000000
Mar 29 07:45:01 noumena logger: ACPI event unhandled: video DD02 00000086 00000000
Mar 29 07:45:02 noumena logger: ACPI event unhandled: video DD02 00000087 00000000

Brightness does not change, stays at whatever setting was selected at the BIOS/GRUB screens.

(In reply to comment #34)
> (In reply to comment #31)
> > Zhang,
> > 
> > But you have closed other bug(#15528) as duplicate of this bug.
> > 
> oops, sorry, I thought the problem on your laptop (bug #15513) is a duplicate
> of bug #15204.
> 
> So you can change the backlight via hotkey but you can not change the
> backlight
> via the sysfs I/F, right?

No I cannot change the brightness by any means in Linux

> did you load the ACPI wmi driver when poking hotkeys?
> If yes, will you please verify if it still works without that driver?

I get following error.

acer-wmi: Acer Laptop ACPI-WMI Extras
acer-wmi: Unable to detect available WMID devices

Some success. When I pass acpi=off noacpi in the command line. I am able to control the back-light through the hot keys

(In reply to comment #40)
> Some success. When I pass acpi=off noacpi in the command line. I am able to
> control the back-light through the hot keys

I can verify that this also works on my laptop.  Unfortunately, you have to give up all other acpi capabilities to enjoy a longer, and unpredictable battery.  haha

Zhang Rui, does this evidence suggest it may yet be an issue with the Linux ACPI?

Sachin, Thanks for the suggestion!!

Best,
Kyle

Zhang,

Is possible to pass the argument in the video module. So that the brightness does not goes to maximum ? It stays what was selected in the bios or windows.


Since the laptop is too bright at maximum it starts hurting the eyes after an hour

Regards,
Sachin.

Acer released a BIOS update for the video cards.  I have applied the update. Still no backlight control here.  I am attaching two things: the new acpidump, and the diff of acpidump.new and acpidump already posted.  Perhaps there is something useful in it.

Any other ideas?

Created attachment 26168 [details]
new acpidump with the bios

Created attachment 26169 [details]
diff acpidump_new acpidump_old

Resolved; needed a grub configuration option of acpi_osi="Linux"

please attach dmidecode, so we could do osi=Linux automatically...

Created attachment 26288 [details]
dmidecode

Attaching dmidecode

Created attachment 26290 [details]
Add Acer Aspire 5740 to osi_linux dmi list

Please check if this patch works.

Created attachment 26291 [details]
dmesg with acpi_osi=Linux

Unfortunately this does not work on my laptop. Still I cannot control brightness. I am attaching the dmesg.

(In reply to comment #49)
> Created an attachment (id=26290) [details]
> Add Acer Aspire 5740 to osi_linux dmi list
> 
> Please check if this patch works.

after doing a make clean and reinstalling the kernel, loading without the additional argument in grub does not give me the ability to control backlight.

Am I missing some other step?

(In reply to comment #50)
> Created an attachment (id=26291) [details]
> dmesg with acpi_osi=Linux

Sachin, you must use quotation marks around the word Linux.

Created attachment 26292 [details]
Add Acer Aspire 5740 to osi_linux dmi list

Please try updated patch

(In reply to comment #53)
> (In reply to comment #50)
> > Created an attachment (id=26291) [details] [details]
> > dmesg with acpi_osi=Linux
> 
> Sachin, you must use quotation marks around the word Linux.

I did use the quotations but it did not help.

(In reply to comment #54)
> Created an attachment (id=26292) [details]
> Add Acer Aspire 5740 to osi_linux dmi list
> 
> Please try updated patch

This one worked.

Thanks!

Great, thanks for testing!

Hi, Kyle,

(In reply to comment #56)
> (In reply to comment #54)
> > Created an attachment (id=26292) [details] [details]
> > Add Acer Aspire 5740 to osi_linux dmi list
> > 
> > Please try updated patch
> 
> This one worked.

can you change the backlight by poking the /sys/class/backlight/acpi_video0/
or can you change the backlight via hotkeys?

Zhang, 

I can change using the brightness keys. Attempting to overwrite the values in /sys/class/backlight/acpi_video0/*brightness results in a bash error: Permission Denied. This happens while logged in as root.

Furthermore, changing the value of brightness in /proc/acpi/video/GFX0/DD02/ changes the value within the file, but does not change the brightness of the screen.

The hotkeys work here though.

Hello,

I have already updated my BIOS ( acer 5740 ) and also applied the patch at drivers/acpi/blacklist.c and after compiling the kernel, I can control the brightness with hot-keys. But no success with xblacklight command. More over "laptop-mode-tools" is also not able to adjust the brightness. Making any change in "/proc/acpi/video/GFX0/DD02/brightness" file has no effect in practical. Any tricks or kernel level configuration to make it working ? Please let me know.

Thanks

The backlight control via ACPI video driver on this laptop is broken, so we need to apply the blacklist patch to enable the backlight control via ACPI wmi.

That's why we can change the backlight via hotkeys but we can not via ACPI video backlight I/F.

Thanks, Any clue when the driver will be fixed ? Actually without a proper driver , laptop-mode-tools can't control the brightness.

Thanks

I'm afraid the answer is no.
By reading the code, I even suspect if win7 follows the ACPI video extension or not. Maybe the ACPI method is broken but BIOS writers are not care of it, because windows just do not use it.
We planned to check how windows control the backlight in the near future, but this may take months.

Very sad to know this. Can we somehow convince the BIOS programmer to add the required code ? It is difficult to ignore the Linux community now-a-days.

Any further progress with the issue ?

thanks

Hello,

any news on this issue ? Can we now control the brightness through ACPI ?

Thanks

with the patch from alexey, the backlight can be changed via hotkey, but does the value of /sys/class/backlight/acpi_video0/actual_brightness also change at the same time?

(In reply to comment #67)
> with the patch from alexey, the backlight can be changed via hotkey, but does
> the value of /sys/class/backlight/acpi_video0/actual_brightness also change
> at
> the same time?

I can verify that the /sys/class/backlight/acpi_video0/actual_brightness value changes with the brightness changes.

Hi everyone,

I guess I have the same problem with my Acer Travel Mate 5740. This bug was originally committed for a Acer Aspire 5740, but I am experiencing the same problem. Do I have to commit a new bug for Acer Travel Mate 5740?

Problem in two words. Out-of-box brightness adjustment doesn't work. Adding acpi_osi=“Linux” to the kernel parameters fixed the brightness control, so I can adjust the brightness via functional keys. BUT after rebooting all setting are gone and the max brightness is applied, so I have to adjust it manually every time, since the the back light is too bright. Is there a way to fix it? A script or something like this?

Can the manufacture (Acer) help to solve this problem? Acer Support?

Thanks

I recently came across a different solution to the LCD brightness issue on the Acer Aspire 5740.  It also applies to other laptops using i915 DRM.

First, compile a kernel (I used 2.6.36-rc8) patched with Matthew Garrett's native backlight control patch:

https://patchwork.kernel.org/patch/163961/ 

Next, add acpi_backlight=vendor to the GRUB kernel line and remove acpi_osi="Linux".

This enables backlight control with more levels of adjustment than the previous method.  It also allows the gnome brightness applet and power manager to control backlight brightness, neither of which worked before.

Kamal Mostafa has additional information here:

https://launchpad.net/~kamalmostafa/+archive/linux-kamal-mjgbacklight

Hello,

I have no problem compiling the kernel, but compilation is not successful with the patched kernel. It failed due to the following 

``````````````````
drivers/gpu/drm/i915/intel_lvds.c: In function âintel_lvds_backlight_setupâ:
drivers/gpu/drm/i915/intel_lvds.c:193: error: âstruct backlight_propertiesâ has no member named âtypeâ
drivers/gpu/drm/i915/intel_lvds.c:193: error: âBACKLIGHT_RAWâ undeclared (first use in this function)
drivers/gpu/drm/i915/intel_lvds.c:193: error: (Each undeclared identifier is reported only once
drivers/gpu/drm/i915/intel_lvds.c:193: error: for each function it appears in.)
make[5]: *** [drivers/gpu/drm/i915/intel_lvds.o] Error 1
make[4]: *** [drivers/gpu/drm/i915] Error 2
make[3]: *** [drivers/gpu/drm] Error 2
make[2]: *** [drivers/gpu] Error 2
make[1]: *** [drivers] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.36-rc8'
make: *** [debian/stamp/build/kernel] Error 2
`````````````````````

What might be the problem ? This is debian squeeze, amd64 arch.

gcc 4:4.4.5-1
make 3.81-8

Thanks

please apply both of these two patches.
https://patchwork.kernel.org/patch/163961/
https://patchwork.kernel.org/patch/163971/

Thanks  Zhang,

Jonathan has already informed me about these 2 patches and I have successfully compiled 2.6.35.7 after patching. Now it is possible to control brightness with

 /sys/class/backlight/intel_backlight/brightness

but the xblacklight as well as the Fn keys are not working. ( tested with acpi_backlight=vendor  too ).  I'll again give a try with the 2.6.36.x series 

- with best regards,
   Joydeep

Hello,

Even with the latest 2.6.36.x series, Fn keys are not working after applying the two patches. But when I apply the one more patch from https://bugzilla.kernel.org/attachment.cgi?id=26292  at drivers/acpi/blacklist.c Fn keys are working and without acpi_backlight=vendor

Additionally the /sys/class/backlight/intel_backlight/brightness has an effect too due to the new patches. Though xblacklight has no effect.

Thanks

Let's not confuse the issue.  https://bugzilla.kernel.org/attachment.cgi?id=26292 is not related to Matthew Garrett's patches and is not required for his patches to work.

Using acpi_osi="Linux" in grub fails for me, however if I use acpi_osi= (with no value) it works great, brightness controls work beautifully. Just want to spread the word because I had some serious issues with this, spent a lot of time finding a workaround.

so can I say that the problem can be workaround by using the i915 brightness control instead of ACPI backlight control?
If yes, I think this is also a duplicate of bug #19342.

Zhang,

The answer to your question is yes.  Using the i915 brightness
control instead of ACPI backlight control is a viable workaround.

Jonathan

As the ACPI backlight control in this bug report is broken, and we can not fix it in Linux/ACPI, the current workaround would be controlling backlight natively.

Bug closed as workaround patch is available.

*** This bug has been marked as a duplicate of bug 19342 ***

for the record Re: acpi_osi=Linux

The acpidump in attachment #1 [details] shows that there is no specific
Linux support in the DSDT.  Rather, the way OSI(Linux) is checked
in the DSDT *disables* Windows support by over-writing
the OSYS variable:

    Scope (_SB.PCI0)
    {
        Method (_INI, 0, NotSerialized)
        {
            Store (0x07D0, OSYS)
            If (CondRefOf (_OSI, Local0))
            {
                If (_OSI ("Windows 2001"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP1"))
                {
                    Store (0x07D1, OSYS)
                }

                If (_OSI ("Windows 2001 SP2"))
                {
                    Store (0x07D2, OSYS)
                }

                If (_OSI ("Windows 2006"))
                {
                    Store (0x07D6, OSYS)
                }

                If (_OSI ("Windows 2009"))
                {
                    Store (0x07D9, OSYS)
                }

                If (_OSI ("Linux"))
                {
                    Store (0x03E8, OSYS)
                }
            }
        }

There are a number of OS-specific hooks in the DSDT
that depend son OSYS, including on that tells the EC
the OS version via OSTP - very nasty.

Thus the patch in comment #54 that sets acpi_osi=Linux automatically
via DMI makes no logical sense, and can not be applied.

Chances are good that the issues appears due to our
claim of Windows 2009 (win7) compatibility, or possibly
that plus Windows 2006 (vista) compatibility.  Disabling
those w/o disabling claim of compatibility with XP may
be more prudent then using acpi_osi=Linux, or disabling
OSI support entirely with acpi_osi=

eg. acpi_osi="!Windows 2009"
to disable claim of compatibility with Win7

or acpi_osi="!Windows 2009" acpi_osi="!Windows 2006"
to disable claim of compatibility with both Win7 and vista.

The acpidump in comment #44 works the same way.

however, the use of acpi_osi here is a workaround only,
not a permanent fix.