Bug 51731

Created attachment 89291 [details]
lspci -vxxx:

does acpi_backlight=vendor help?

I have added acpi_backlight=vendor and acpi_osi=Linux but it still doesn't work.

please do the following test in a working kernel.
"grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the hotkey.

And please verify if changing the value in /sys/class/backlight/acpi_video0/ manually can actually change the backlight, in both working and failing kernels.

acpi_osi=""

should work for your laptop.

Hi i-tek@web.de,

Any update on this? Did you try Rui and Nikolay's suggestion?
Thanks.

Hi,

sorry I was a bit busy recently.
I tried to change the backlight by using "echo 1 >
/sys/class/backlight/acpi_video0/brightness" and it worked in all tested
kernels.

The appended files concern the requested output of "grep .
/sys/firmware/acpi/interrupts/*"; if it matters: there were 3 not
related keystrokes between the hotkey's usage and the postkey.txt file
output.

At last:
Setting "acpi_osi=" in grub's kernel boot arguments did the trick.

However, how should a normal enduser figure this out? Is this a grub,
kernel or distribution related problem?

Thank You Sirs

Created attachment 95181 [details]
Before pressing the key

Created attachment 95191 [details]
After pressing the key

Looks like an EC problem to me, Rui, what do you think?

The _BQC and _BCM is straightforward, they just return/store a value in EC space, and this works well according to i-tek. The broken part is the notification, which is related to EC. I've no idea what happened here.

Setting acpi_osi= here means to set OS version to windows 2000 in this table I think, and it would affect XSEC, which is a variable defined in EC space. Bud I don't know how it is related.

Hi Nikolay,
May I know how did you get the conclusion setting acpi_osi= would work? Thanks.

(In reply to comment #7)
> Hi,
> 
> At last:
> Setting "acpi_osi=" in grub's kernel boot arguments did the trick.
> 
> However, how should a normal enduser figure this out? Is this a grub,
> kernel or distribution related problem?

Perhaps a kernel problem.

Can you please verify the following two commits?
5c7dd710f691d1b44c39e32d2f05b4286ff51f99 (should be bad)
9061e0e16700ef228837e96987ff51794c956197 (should be good)

And do a git bisect to find the offending commit? Thanks.

A quick guide on git bisect:
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search

(In reply to comment #10)

Please, pay attention to the old bug:
https://bugzilla.kernel.org/show_bug.cgi?id=9902

Amilo Pi 2515 is a similar notebook. BTW, users of Pi 2515 report that
brightness keys work fine on Opensuse 11.3 and Fedora 13 ("acpi_osi" not needed).

(In reply to comment #7)
> Hi,
> 
> sorry I was a bit busy recently.
> I tried to change the backlight by using "echo 1 >
> /sys/class/backlight/acpi_video0/brightness" and it worked in all tested
> kernels.

When you test this, do you have acpi_osi= kernel command line param?

> 
> The appended files concern the requested output of "grep .
> /sys/firmware/acpi/interrupts/*"; if it matters: there were 3 not
> related keystrokes between the hotkey's usage and the postkey.txt file
> output.

Same here, do you use acpi_osi= kernel command line param when doing these tests?

> 
> At last:
> Setting "acpi_osi=" in grub's kernel boot arguments did the trick.
> 
> However, how should a normal enduser figure this out? Is this a grub,
> kernel or distribution related problem?
> 
> Thank You Sirs

(In reply to comment #12)
> (In reply to comment #10)
> 
> Please, pay attention to the old bug:
> https://bugzilla.kernel.org/show_bug.cgi?id=9902

This looks different: in bug 9902, the asl code will do some test before sending out notification, and the test may fail. But here, the asl code does nothing, it simply send the notification:

                    Method (_Q11, 0, NotSerialized)
                    {
                        Notify (^^^PEGP.VGA.LCD, 0x87)
                    }

                    Method (_Q12, 0, NotSerialized)
                    {
                        Notify (^^^PEGP.VGA.LCD, 0x86)
                    }

> 
> Amilo Pi 2515 is a similar notebook. BTW, users of Pi 2515 report that
> brightness keys work fine on Opensuse 11.3 and Fedora 13 ("acpi_osi" not
> needed).

Where can I find information about this? Thanks.

(In reply to comment #14)
> > Amilo Pi 2515 is a similar notebook. BTW, users of Pi 2515 report that
> > brightness keys work fine on Opensuse 11.3 and Fedora 13 ("acpi_osi" not
> > needed).
> 
> Where can I find information about this? Thanks.

For example, in the German forum: 
http://www.amilo-forum.de/topic,23195,-AMILO-Pi-2515-Linux.html

Maybe acpi_osi="!Windows 2006" works for Amilo Pi 2550 too.

(In reply to comment #11)
> Can you please verify the following two commits?
> 5c7dd710f691d1b44c39e32d2f05b4286ff51f99 (should be bad)
> 9061e0e16700ef228837e96987ff51794c956197 (should be good)
> And do a git bisect to find the offending commit? Thanks.

I have built 5c7dd710f691d1b44c39e32d2f05b4286ff51f99 which was bad
indeed but I ran into problems trying to compile
9061e0e16700ef228837e96987ff51794c956197 which look this way:
  CC [M]  drivers/net/wireless/mac80211_hwsim.o
  LD      drivers/net/wireless/built-in.o
  LD      drivers/net/built-in.o
make[2]: *** [drivers] Error 2
make[1]: *** [deb-pkg] Error 2
make: *** [deb-pkg] Error 2


(In reply to comment #13)
> When you test this, do you have acpi_osi= kernel command line param?

I am pretty sure I hadn't set the acpi_osi= param when I tested those
things.

(In reply to comment #15)
> For example, in the German forum:
> http://www.amilo-forum.de/topic,23195,-AMILO-Pi-2515-Linux.html
> Maybe acpi_osi="!Windows 2006" works for Amilo Pi 2550 too.

Yes, it does work like "acpi_osi="

(In reply to comment #16)
> I have built 5c7dd710f691d1b44c39e32d2f05b4286ff51f99 which was bad
> indeed but I ran into problems trying to compile
> 9061e0e16700ef228837e96987ff51794c956197 which look this way:
>   CC [M]  drivers/net/wireless/mac80211_hwsim.o
>   LD      drivers/net/wireless/built-in.o
>   LD      drivers/net/built-in.o
> make[2]: *** [drivers] Error 2
> make[1]: *** [deb-pkg] Error 2
> make: *** [deb-pkg] Error 2

Please try this one instead: ed283e9f0a2cc0541870828c76c6c6997c51a318, see if it is good, thanks.

I still had problems with compiling but after struggling with different
configs I finally got the Revision.

git bisect: [ea9f8856bd6d4ed45885b06a338f7362cd6c60e5] ACPI video:
Harden video bus adding.

And indeed the compromising code provided changes in the Backlight handling.
While the newer kernel releases were able to show a kernel panic screen
the elder ones resulted in a frozen screen.
I'll attach the bisect log as well...

I hope that spending my whole night was worth it :)

Created attachment 96661 [details]
Logfile of git bisect

Created attachment 96671 [details]
Kernel 3.8.2 - Part of the visible call trace on kernel panic

(In reply to comment #19)
> I still had problems with compiling but after struggling with different
> configs I finally got the Revision.
> 
> git bisect: [ea9f8856bd6d4ed45885b06a338f7362cd6c60e5] ACPI video:
> Harden video bus adding.
> 
> And indeed the compromising code provided changes in the Backlight handling.
> While the newer kernel releases were able to show a kernel panic screen
> the elder ones resulted in a frozen screen.
> I'll attach the bisect log as well...
> 
> I hope that spending my whole night was worth it :)

Yes, I'm sure it's worth it :-)
Thanks for your test.

Created attachment 96891 [details]
Debug statement for acpi_video_bus_add

Hi i-tek,

Please apply this debug patch on top of Linus' git tree(v3.9-rc5 as of today), and then attach the full dmesg here, thanks.

In your DSDT table, there is a device under the vga controller that doesn't provide _ADR:

Device (AMW0)

And it would make acpi_video_bus_get_devices fail, but the problem is, when it failed, it didn't handle correctly: the notification handler is added, but the input device is not set yet. So each time a notification comes, the handler will try to send out the event through the input device, it will panic.

Created attachment 96901 [details]
Deal with failure cases when acpi_video_bus_get_devices failed

Please test this patch, apply directly on top of v3.9-rc5. I think it can fix your problem, thanks.

(In reply to comment #25)
> Please test this patch, apply directly on top of v3.9-rc5. I think it
can fix your problem, thanks.

The patch works very well on the bleeding edge kernel. No more panics
for me!

Thank you very much
(Is further testing etc. required?)

(In reply to comment #26)
> (In reply to comment #25)
> > Please test this patch, apply directly on top of v3.9-rc5. I think it
> can fix your problem, thanks.
> 
> The patch works very well on the bleeding edge kernel. No more panics
> for me!
> 
> Thank you very much
> (Is further testing etc. required?)

No more, thanks a lot for the test.

I'll propose this patch to upstream, and with your Reported-bisected-and-tested-by tag if you don't object. BTW, what's your real name? I need to put it like this:

Reported-bisected-and-tested-by: Your Real Name <i-tek@web.de>

Thanks.

commit 91e13aa37023437c260c85a3f17308052bbfbfa2
Author: Aaron Lu <aaron.lu@intel.com>
Date:   Thu Apr 25 02:47:49 2013 +0000

    ACPI: video: correct acpi_video_bus_add error processing