Do 8042/kb_ps2 keyboard devices work under wheezy kernels?
Hi all,
I'm currently working on a patchset to fix up the various OpenBIOS
properties to enable detection of the PS/2 keyboard in QEMU. After a
couple of days work I have a prototype patch which fixes us the various
device tree properties to match those close to real hardware - which
works fine on all of my non-Linux images but fails when trying to boot a
Debian wheezy kernel.
Here is the panic I get when I try and boot the kernel:
[ 17.184211] Unable to handle kernel NULL pointer dereference
[ 17.184776] tsk->{mm,active_mm}->context = 0000000000000000
[ 17.185438] tsk->{mm,active_mm}->pgd = fffff800009f6550
[ 17.185964] \|/ ____ \|/
[ 17.185979] "@'/ .. \`@"
[ 17.185990] /_| \__/ |_\
[ 17.186001] \__U_/
[ 17.187411] swapper(1): Oops [#1]
[ 17.188086] TSTATE: 0000004480001605 TPC: 0000000000812788 TNPC:
000000000081278c Y: 00000000 Not tainted
[ 17.189643] TPC: <sparc_i8042_probe+0x34/0x134>
[ 17.190247] g0: 0000000000000000 g1: 00000000009563e8 g2:
0000000000000000 g3: 0000000000992cf8
[ 17.191080] g4: fffff8000703b6e0 g5: 0000000000000000 g6:
fffff80007040000 g7: 0000000000000000
[ 17.191911] o0: 00000000008fd5c0 o1: fffff8000722e800 o2:
ffffffff80000000 o3: 0000000000020000
[ 17.192738] o4: fffff800070436b0 o5: 0000000000000000 sp:
fffff80007042ee1 ret_pc: 0000000000812764
[ 17.193693] RPC: <sparc_i8042_probe+0x10/0x134>
[ 17.194223] l0: 00000000008e8800 l1: 00000000008fd400 l2:
fffff80000000000 l3: 0000000000a83bf0
[ 17.195069] l4: fffff8000726b748 l5: 0000000000000000 l6:
000000000097cfa0 l7: 0000000000000008
[ 17.195889] i0: fffff8000722e800 i1: 00000000008e9000 i2:
00000000008fd400 i3: 00000000008e9000
[ 17.196714] i4: fffff80007296980 i5: 0000000000000000 i6:
fffff80007042f91 i7: 00000000006a3d8c
[ 17.197645] I7: <platform_drv_probe+0xc/0x20>
[ 17.198208] Call Trace:
[ 17.198643] [00000000006a3d8c] platform_drv_probe+0xc/0x20
[ 17.199200] [00000000006a2890] really_probe+0x50/0x180
[ 17.199682] [00000000006a0ff4] bus_for_each_drv+0x54/0xa0
[ 17.200178] [00000000006a2a40] device_attach+0x80/0xc0
[ 17.200654] [00000000006a1f98] bus_probe_device+0x78/0xc0
[ 17.201233] [000000000069fcf8] device_add+0x498/0x600
[ 17.201715] [00000000006a4440] platform_device_add.part.4+0x100/0x240
[ 17.202297] [00000000006a498c] platform_create_bundle+0xcc/0x160
[ 17.202938] [00000000009cd5f4] i8042_init+0x174/0x1d8
[ 17.203420] [0000000000426ba8] do_one_initcall+0xe8/0x160
[ 17.203923] [00000000009b08f0] kernel_init+0xd8/0x168
[ 17.204396] [000000000042b270] kernel_thread+0x30/0x60
[ 17.204965] [0000000000801f20] rest_init+0x10/0x70
[ 17.205590] Disabling lock debugging due to kernel taint
[ 17.206269] Caller[00000000006a3d8c]: platform_drv_probe+0xc/0x20
[ 17.206875] Caller[00000000006a2890]: really_probe+0x50/0x180
[ 17.207394] Caller[00000000006a0ff4]: bus_for_each_drv+0x54/0xa0
[ 17.207929] Caller[00000000006a2a40]: device_attach+0x80/0xc0
[ 17.208443] Caller[00000000006a1f98]: bus_probe_device+0x78/0xc0
[ 17.208977] Caller[000000000069fcf8]: device_add+0x498/0x600
[ 17.209568] Caller[00000000006a4440]:
platform_device_add.part.4+0x100/0x240
[ 17.210185] Caller[00000000006a498c]: platform_create_bundle+0xcc/0x160
[ 17.210763] Caller[00000000009cd5f4]: i8042_init+0x174/0x1d8
[ 17.211270] Caller[0000000000426ba8]: do_one_initcall+0xe8/0x160
[ 17.211804] Caller[00000000009b08f0]: kernel_init+0xd8/0x168
[ 17.212312] Caller[000000000042b270]: kernel_thread+0x30/0x60
[ 17.212826] Caller[0000000000801f20]: rest_init+0x10/0x70
[ 17.213420] Instruction DUMP: 350023f5 901221c0 370023a4 <d45f4000>
9210001d a21461f0 a01420d0 40000467 b2166078
[ 17.215328] Kernel panic - not syncing: Attempted to kill init!
[ 17.215923] Call Trace:
[ 17.216219] [000000000046711c] do_exit+0x79c/0x7c0
[ 17.216675] [0000000000427c3c] die_if_kernel+0x17c/0x300
[ 17.217265] [0000000000818ac8] unhandled_fault+0x84/0x9c
[ 17.217766] [0000000000819290] do_sparc64_fault+0x7b0/0x8e0
[ 17.218273] [0000000000407880] sparc64_realfault_common+0x10/0x20
[ 17.218881] [0000000000812788] sparc_i8042_probe+0x34/0x134
[ 17.219393] [00000000006a3d8c] platform_drv_probe+0xc/0x20
[ 17.219893] [00000000006a2890] really_probe+0x50/0x180
[ 17.220368] [00000000006a0ff4] bus_for_each_drv+0x54/0xa0
[ 17.220856] [00000000006a2a40] device_attach+0x80/0xc0
[ 17.221428] [00000000006a1f98] bus_probe_device+0x78/0xc0
[ 17.221934] [000000000069fcf8] device_add+0x498/0x600
[ 17.222402] [00000000006a4440] platform_device_add.part.4+0x100/0x240
[ 17.222968] [00000000006a498c] platform_create_bundle+0xcc/0x160
[ 17.223539] [00000000009cd5f4] i8042_init+0x174/0x1d8
[ 17.224088] [0000000000426ba8] do_one_initcall+0xe8/0x160
[ 17.225484] Press Stop-A (L1-A) to return to the boot prom
The problem seems to be related to the platform-specific parts of the
8042 keyboard driver which are now invoked with a fixed device tree.
With the aid of some liberally sprinkled printk() statements, what I see
is the following:
- sparc_i8042_probe() is called successfully using a platform_device
passed in from the initial device tree scan
- i8042_init() calls platform_create_bundle() to initialise the
platform-specific parts of the keyboard driver in
drivers/input/serio/i8042-sparcio.h.
- platform_create_bundle() calls platform_device_alloc() to create a new
platform_device object.
- The new platform_device object is passed into sparc_i8042_probe() for
a second time which segfaults when trying to access the
platform_device's OF node property with op->dev.of_node.
AFAICT this shouldn't even work on real hardware since
platform_device_alloc() creates a new platform_device from scratch and
so the reference to the OF device node dev.of_node, which is eventually
passed onto sparc_i8042_probe() when it is called for the second time,
is never populated.
Does anyone have any hardware with a real 8042/kb_ps2 node in its device
tree, and if so can you confirm whether booting a standard wheezy CDROM
correctly detects the PS/2 keyboard device without crashing? If so,
maybe there is something else in the device tree that still allows 8042
detection to succeed but doesn't call sparc_i8042_probe() for a second time?
ATB,
Mark.
Reply to: