2.5.67-mm2
Subsystems (2)
Joshua Kwan wrote:
[snip]
Quoted 27 lines
Unable to handle kernel NULL pointer dereference at virtual address00000040
printing eip:c0223cf4
*pde = 00000000Oops: 0002 [#1] CPU: 0 EIP: 0060:[<c0223cf4>] Not tainted VLI EFLAGS: 00010282EIP is at
devclass_add_driver+0x34/0x8a
eax: 00000040 ebx:fffffff8ecx:fffffff0edx:ffff0001
esi: 00000040 edi: 00000000 ebp:c03af298esp:c1297f50
ds: 0007b es: 007b ss: 0068
Process swapper: (pid: 1, threadinfo=c1296000 task=c1294080)Stack: c03af500 c03af2b4 c03ae7c4 00000000 c03ae780 c0223620 c03af298 c03af280 00000001 00000000 00000000 c0223a72 c03af298 c0223a72 c03af048 fffffffc 00000034 c026d15d c03af298 c01afc02 c03af048 c0402ebe c03af020 0000003c Call Trace: [<c0223620>] bus_add_driver+0x82/0xd2 [<c0223a72>] driver_register+0x38/0x3c [<c0223a72>] driver_register+0x38/0x3c [<c026d15d>] usb_register+0x73/0xae [<c01afc02>] pci_register_driver+0x47/0x57 [<c0402ebe>] uhci_hcd_init+0xd9/0x137
Quoted 8 lines
[<c0402f2b>] hid_init+0xf/0x21 [<c03ec6e0>] do_initcalls+0x28/0x94 [<c0129ce8>] init_workqueues+0xf/0x27 [<c0105099>] init+0x36/0x195 [<c0105063>] init+0x0/0x195 [<c0106ffd>] kernel_thread_helper+0x5/0xb Code: 24 0c 89 6c 24 10 89 74 24 08 8b 6c 24 18 31 ff 8b 45 08 89 04
24 e8
Quoted 1 line
f7 02 00 00 85 c0 89 c3 74 4a 8d 70 48 ba 01 00 ff ff 98 f0 <0f> c1 10
85
Quoted 6 lines
d2 0f 85 f 03 00 00 89 2c 24 e8 c0 fe ff ff 85 c0
<0>Kernel panic: Attempted to kill init!This doesn't happen with 2.5.67{-bk4}. I looked at the USB changes for 2.5.67-mm2 and they are just about the same as in -bk4. I didn't look at every line, though.
I get the same thing on an mm2 boot. Are you certain it isn't a -bk4 bug? kobject, bus_add_driver and friends have all been touched by greg in bk, and I can't see anything immediately obvious in the new -mm patches (-mm1 works fine).
I'll try with just the linus drop now.
Cheers,
Alistair.
Quoted 10 lines · Alistair Strachan
Quoted 2 lines
EIP is at
devclass_add_driver+0x34/0x8a...
I get the same thing on an mm2 boot. Are you certain it isn't a -bk4 bug? kobject,
bus_add_driverand friends have all been touched by greg in bk, and I can't see anything immediately obvious in the new -mm patches (-mm1 works fine).I'll try with just the linus drop now.
It's a bk bug. This might make it boot:
drivers/base/class.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-)
drivers/base/class.c renamed from drivers/base/class.c~a +1 -1
@@ -105,7 +105,7 @@ int devclass_add_driver(struct device_drstruct device_class * cls =get_devclass (drv->devclass);int error =0 ; -if (cls) { +if (cls && cls->subsys) {down_write (&cls->subsys.rwsem);pr_debug ("device class %s: adding driver %s:%s\n" , cls->name,drv->bus->name,drv->name);
_
Quoted 1 line · Andrew Morton
It's a bk bug. This might make it boot:
Yah, I needed a similar patch to make 2.5.67-mm2 boot. Not sure if its hiding the real problem or not, but it works.
Note the difference between mine and your's, though. I think you need it.
Robert Love
drivers/base/class.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
drivers/base/class.c +2 -2
@@ -103,12 +105,12 @@struct device_class * cls =get_devclass (drv->devclass);int error =0 ; -if (cls) { +if (cls && &cls->subsys) {down_write (&cls->subsys.rwsem);pr_debug ("device class %s: adding driver %s:%s\n" , cls->name,drv->bus->name,drv->name); error =devclass_drv_link (drv); - +if (!error)list_add_tail (&drv->class_list,&cls->drivers.list);up_write (&cls->subsys.rwsem);
Quoted 6 lines · Robert Love
Quoted 1 line · Andrew Morton
It's a bk bug. This might make it boot:
Yah, I needed a similar patch to make 2.5.67-mm2 boot. Not sure if its hiding the real problem or not, but it works.
This patch is just hiding the real problem. The real problem is in the input class patch that I sent to Linus. Either the input core needs to be marked as a subsys_init(), or that patch needs to be reverted.
I'll work on fixing this up on Monday...
greg k-h
Quoted 2 lines · Greg KH
I'll work on fixing this up on Monday...
David Miller pointed out the proper fix, and here it is. Let me know if this works for everyone or not.
thanks,
greg k-h
# Input: change input_init() to be a subsys initcall
#
# This fixes oopses when it and the hid core are compiled into the kernel.
drivers/input/input.c +1 -1
@@ -717,5 +717,5 @@devclass_unregister (&input_devclass); } -module_init (input_init); +subsys_initcall (input_init);module_exit (input_exit);
Quoted 5 lines · Greg KH
Quoted 1 line · Greg KH
I'll work on fixing this up on Monday...
David Miller pointed out the proper fix, and here it is. Let me know if this works for everyone or not.
Patching 2.5.67 to -mm3, then reverting Andrew's workaround and applying your fix still allows me to boot. Therefore it is fixed, here.
Cheers,
Alistair.
Quoted 2 lines · Greg KH
David Miller pointed out the proper fix, and here it is. Let me know if this works for everyone or not.
Ja, bestatigt.
Danke,
Robert Love
Quoted 11 lines · Andrew Morton
It's a bk bug. This might make it boot:
drivers/base/class.c | 2 +- 1 files changed, 1 insertion(+), 1 deletion(-)diff -puN
drivers/base/class.c~adrivers/base/class.c
drivers/base/class.c int devclass_add_driver(struct device_dr · line 111
Quoted 8 lines
drivers/base/class.c renamed from drivers/base/class.c~a +1
-1@@ -105,7 +105,7 @@ int devclass_add_driver(struct device_drstruct device_class * cls =get_devclass (drv->devclass);int error =0 ; -if (cls) { +if (cls && cls->subsys) {down_write (&cls->subsys.rwsem);pr_debug ("device class %s: adding driver %s:%s\n" , cls->name,drv->bus->name,drv->name);
Ah yes. Works fine, thanks.
Cheers,
Alistair.