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.
(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
Please reassign to "Drivers/Input". I'm not allowed to do this.
Why is it kernel bugzilla at all?
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?
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?
Created attachment 21162 [details] config
Notify-Also : Dmitry Torokhov <dmitry.torokhov@gmail.com> Notify-Also : Ingo Molnar <mingo@elte.hu>
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>