Bug 13156 - keyboard backlight brightness up/down keys doesn't work
keyboard backlight brightness up/down keys doesn't work
Status: CLOSED CODE_FIX
Product: Platform Specific/Hardware
Classification: Unclassified
Component: x86-64
All Linux
: P1 normal
Assigned To: platform_x86_64@kernel-bugs.osdl.org
:
Depends on:
Blocks: 13070
  Show dependency treegraph
 
Reported: 2009-04-23 20:46 UTC by Thomas Meyer
Modified: 2009-05-24 10:55 UTC (History)
4 users (show)

See Also:
Kernel Version: 2.6.30-rc3
Tree: Mainline
Regression: Yes


Attachments
config (66.63 KB, text/plain)
2009-04-28 19:58 UTC, Thomas Meyer
Details

Description Thomas Meyer 2009-04-23 20:46:46 UTC
hald-addon-macbookpro-backlight abnormally ends after pressing keyboard backlight brightness up/down keys.

1. Start hald:
$ ps -A f

 4094 ?        Ss     0:00 hald
 4095 ?        S      0:00  \_ hald-runner
 4190 ?        S      0:00      \_ /usr/libexec/hald-addon-macbookpro-backlight
 4203 ?        S      0:00      \_ hald-addon-input: Listening on /dev/input/event11 /dev/input/event9 /dev/input/event8 /dev/input/event3 /dev/input/event1
 4216 ?        S      0:00      \_ /usr/libexec/hald-addon-cpufreq
 4217 ?        S      0:00      \_ hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
 4221 ?        S      0:00      \_ hald-addon-storage: polling /dev/sr0 (every 2 sec)

2. Press keyboard backlight up or down key:
[ 3006.019628] hald-addon-macb[4190] general protection ip:804962b sp:bffe0fa0 error:0 in hald-addon-macbookpro-backlight[8048000+3000]

2.6.29.1 works ok with applesmc driver.
Comment 1 Thomas Meyer 2009-04-25 13:32:19 UTC
(gdb) cont
Continuing.

Program received signal SIGSEGV, Segmentation fault.
readkey (key=0x804a400 "ALV1", len=6 '\006', buffer=0xbfd50d72 "")
    at addon-macbookpro-backlight.c:166
166		outb(0x10, 0x304);

(gdb) bt 
#0  0x0804962b in readkey (key=0x804a400 "ALV1", len=6 '\006', 
    buffer=0xbfd50d72 "")
#1  0x080499ad in read_light_sensor () at addon-macbookpro-backlight.c:193
#2  filter_function (connection=0x90077f8, message=0x9007b18, userdata=0x0)
    at addon-macbookpro-backlight.c:319
#3  0x00b53175 in dbus_connection_dispatch (connection=0x90077f8)
    at dbus-connection.c:4406
#4  0x497dc08d in message_queue_dispatch (source=0x9007260, callback=0, 
    user_data=0x0) at dbus-gmain.c:101
#5  0x48f52258 in g_main_dispatch () at gmain.c:2144
#6  IA__g_main_context_dispatch (context=0x90090b0) at gmain.c:2697
#7  0x48f55903 in g_main_context_iterate (context=0x90090b0, block=1, 
    dispatch=1, self=0x9007350) at gmain.c:2778
#8  0x48f55e22 in IA__g_main_loop_run (loop=0x9007d60) at gmain.c:2986
#9  0x080492a7 in main () at addon-macbookpro-backlight.c:550
Comment 2 Thomas Meyer 2009-04-25 14:18:19 UTC
Please reassign to "Drivers/Input". I'm not allowed to do this.
Comment 3 Dmitry Torokhov 2009-04-27 21:35:00 UTC
Why is it kernel bugzilla at all?
Comment 4 Thomas Meyer 2009-04-27 23:03:08 UTC
Hi Dmitry,

a) 2.6.29.1   + Fedora 10 user land =     working brightness control
b) 2.6.30-rc3 + Fedora 10 user land = non-working brightness control

Shouldn't the kernel change be transparent to user space applications?

Am I overseeing something? Did some sysfs conventions change? Why does the application get the above SIGSEGV at all in the new kernel?

Could you please have a look at this?
Comment 5 Dmitry Torokhov 2009-04-28 16:03:17 UTC
hald-addon-macbookpro-backlight does not use input layer at all nor does it use sysfs, instead it does direct port IO in attempt to control backlight.

The following in HAL code is not correct:

        if (ioperm (0x300, 0x304, 1) < 0) {
                HAL_ERROR (("ioperm failed (you should be root)."));
                exit(1);
        }

- the 2nd argument to ioperm is number of ports to allow access to, not the upper bound. PLease file a bug against HAL.

Ingo, it may be that ioperm code was changed and now exposes the issue, any ideas?
Comment 6 Thomas Meyer 2009-04-28 19:58:25 UTC
Created attachment 21162 [details]
config
Comment 7 Rafael J. Wysocki 2009-05-13 10:49:58 UTC
Notify-Also : Dmitry Torokhov <dmitry.torokhov@gmail.com>
Notify-Also : Ingo Molnar <mingo@elte.hu>
Comment 8 Thomas Meyer 2009-05-24 08:10:06 UTC
Strange! The hald addon started to work again (with 2.6.30-rc5(?) and later). I'm confused now. Did something change in the ioperm syscall?

Ah!

I searched the git log. This is very likley fixed by f9a196b8dceba3c1e5fe885b81e45043ad7c60fc

    x86: initialize io_bitmap_base on 32bit
    
    commit db949bba3c7cf2e664ac12e237c6d4c914f0c69d (x86-32: use non-lazy
    io bitmap context switching) broke ioperm for 32bit because it removed
    the lazy initialization of io_bitmap_base and did not set it to the
    real bitmap offset.
    
    [ Impact: fix non-working sys_ioperm() on 32-bit kernels ]
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Note You need to log in before you can comment on or make changes to this bug.