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.