Bug 13156
| Summary: | keyboard backlight brightness up/down keys doesn't work | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Thomas Meyer (thomas) |
| Component: | x86-64 | Assignee: | platform_x86_64 (platform_x86_64) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | alan, dmitry.torokhov, mingo, rjw |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.30-rc3 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 13070 | ||
| Attachments: | config | ||
|
Description
Thomas Meyer
2009-04-23 20:46:46 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
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>
|