Latest working kernel version: none known Earliest failing kernel version: Distribution: Arch Linux Hardware Environment: MSI WIND U100 Software Environment: Problem Description: When I want change brightness using Fn+F4 (down) or Fn+F5 (up) it works crappy. It means that, I must hold this key combination 3-5 seconds to work, or hit it several times. This bug exist in vanilla 2.6.27 and Arch Linux 2.6.27, but in Ubuntu 8.10 kernel it works correctly, as expected. When I use kernel from Ubuntu on Arch Linux it works. I recompiled vanilla kernel with ubuntu config, but it doesn't work. Changing brigtness using "echo xx > /proc/acpi/video/IGD/LCD/brightness" works correctly on all kernels (Vanilla, Arch, Ubuntu, Fedora) Steps to reproduce: - install/run distro: Arch Linux / Fedora 9 - try change brightness using Fn+F4/F5
Will you please attach the output of acpidump, dmidecode? Do you mean that the system can work well if using the proc interface to change the brightness but the system will crash when hotkey is used? Thanks.
hmmm, ACPI backlight I/F works well, that's good news. please run "grep . /sys/firmware/acpi/interrupts/*" both before and after pressing the hotkeys and attach the test result here. Note that you may want to do this test twice, 1. a single shot of the hotkey, which doesn't change the backlight. 2. hold the hotkeys 3-5 seconds which does change the backlight. And please kill acpid before pressing the hotkey and see if the backlight can be changed successfully.:)
Created attachment 18607 [details] acpidump
Created attachment 18608 [details] dmidecode
(In reply to comment #1) > Will you please attach the output of acpidump, dmidecode? > Do you mean that the system can work well if using the proc interface to > change > the brightness but the system will crash when hotkey is used? > No. If I'm using proc all works correct. If I us hotkey, sometimes it works sometimes not. No crash :)
(In reply to comment #2) Changing brightness without acpid running is same.
Created attachment 18609 [details] 1. a single shot of the hotkey, which doesn't change the backlight. - BEFORE
Created attachment 18610 [details] 1. a single shot of the hotkey, which doesn't change the backlight. - AFTER
Created attachment 18611 [details] 2. hold the hotkeys 3-5 seconds which does change the backlight. - BEFORE
Created attachment 18612 [details] 2. hold the hotkeys 3-5 seconds which does change the backlight. - AFTER
weird, no ACPI events even the backlight is changed, which means that hotkey events are not handled by ACPI. could you please re-do the test in comment #2, but run "cat /proc/interrupts" instead. :)
Created attachment 18613 [details] 1. before single shot
Created attachment 18614 [details] 1. after single shot
Created attachment 18615 [details] 3. before brightness change
Created attachment 18616 [details] 4. after brightness change
What I observed: I watched /proc/interrupts using: watch -n0.1 cat /proc/interrupts when hotkey doesnt change brightness, 1: (i8042) doesn't change counter, but when I succesfull change brightness using hotkeys this counter has been changed.
well, I'm not sure, but I don't think this is an ACPI bug. because the hotkey events are not sent to ACPI, but i8042 instead. so the problem is that no i8042 interrupt when pressing the hotkey, right?
On Ubuntu kernel (where all works fine), when I use hotkeys in /proc/interrupts are changed: 1: (i8042) 9: (acpi) So I dont know. Also in /sys/firmware/acpi/interrupts counters are changed when I press hotkeys. Ubuntu or Debian changed something in kernel and it's works (hotkeys).
so ACPI can receive hotkey events in Ubuntu/Debian kernel? that's weird. what's the kernel version of Ubuntu 8.0? It would be great if you can try some earlier vanilla kernel to see if this is a regression
Ok, I will try make a test in earlier kernels. Ubuntu has 2.6.27 kernel (2.6.27-7-generic).
Ok, I tested kernels from 2.6.10 to 2.6.27 and kernel 2.6.27-rc3. 10-17 works. 18-19 doesn't change brightness at all. 20-25 works same as in 10-17. 26 - same as 27 (here is _regression_) BUT this bug is fixed in 2.6.28-rc3 :)))))