Skip to contentSkip to conversation

2.5.67-mm2

DISCUSSION Alistair Strachan 4 participants 8 messages Apr 13, 2003 – Apr 14, 2003

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

Joshua Kwan wrote:

[snip]

Quoted 27 lines
Unable to handle kernel NULL pointer dereference at virtual address

00000040
printing eip:
c0223cf4
*pde = 00000000

Oops: 0002 [#1]
CPU:    0
EIP:    0060:[<c0223cf4>]    Not tainted VLI
EFLAGS: 00010282

EIP is at devclass_add_driver+0x34/0x8a
eax: 00000040 ebx: fffffff8 ecx: fffffff0 edx: ffff0001
esi: 00000040 edi: 00000000 ebp: c03af298 esp: 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.

#1 lore raw
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_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.

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
diff -puN drivers/base/class.c~a drivers/base/class.c
@@ -105,7 +105,7 @@ int devclass_add_driver(struct device_dr
 	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);

_

#2 lore raw
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
diff -urN linux-2.5.67/drivers/base/class.c linux/drivers/base/class.c
@@ -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);
#7 lore raw
In reply to Andrew Morton
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~a drivers/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_dr
 	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);

Ah yes. Works fine, thanks.

Cheers,
Alistair.

#3 lore raw
In reply to Robert Love
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

#4 lore raw
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
diff -Nru a/drivers/input/input.c b/drivers/input/input.c
@@ -717,5 +717,5 @@
 	devclass_unregister(&input_devclass);
 }
 
-module_init(input_init);
+subsys_initcall(input_init);
 module_exit(input_exit);
#5 lore raw
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.

#6 lore raw
In reply to Greg KH
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