Kernel Panic in 2.5.73-mm1 OOps part.

DISCUSSION jds 3 participants 7 messages Jun 24, 2003 Block layer

lore

Share & tools

lore

Andrew Morton

2003-06-24 19:54 UTC #1 lore raw

Quoted 9 lines · jds

Hi Andrew:
I have kernel panic when boot with kernel 2.5.73-mm1, in kernel 2.5.73
working good.

Please disable CONFIG_BLK_DEV_NBD. We're working on it.

I think this is my fault. I introduced a patch to nbd that apparantly doesn't use the block layer quite the way the block layer developers expect. As you found, it works on 2.5.73 but not in 2.5.73-mm1. I'm looking into why exactly this is so I can get a fix ASAP. In the meantime, if you take out the network block driver you shouldn't get this oops anymore.

jds

author

2003-06-24 21:38 UTC #3 lore raw

Hi Andrew, lou:

Diseable the # CONFIG_BLK_DEV_NBD is not set, in .config, compile again
kernel and working good.

Thanks .... :)

Iam testings my new kernel mm1

Regards.

---------- Original Message -----------
From: Lou Langholtz <[email protected]>
To: jds <[email protected]>
Sent: Tue, 24 Jun 2003 14:15:24 -0600
Subject: Re: Kernel Panic in 2.5.73-mm1 OOps part.

Quoted 20 lines

Quoted 16 lines · jds

Hi Andrew:

I have kernel panic when boot with kernel 2.5.73-mm1, in kernel 2.5.73
working good.

   Anex part the OOps: . . .

   [< c020f503>]  kobject_register+0x23/0x60
   [<             blk_register_queue+0x80/0xb0
                  nbd_init+0x1df/0x220
                  do_initcalls+0x2b/0xa0
                  init_workqueues+0x12/0x30
                  init+0x28/0x150
                  init+0x0/0x150
                  kernel_thread_helper+0x50/0xc

Quoted 2 lines

. . .

Quoted 6 lines

I think this is my fault. I introduced a patch to nbd that apparantly doesn't use the block layer quite the way the block layer developers expect. As you found, it works on 2.5.73 but not in 2.5.73-mm1. I'm looking into why exactly this is so I can get a fix ASAP. In the meantime, if you take out the network block driver you shouldn't get this oops anymore.

------- End of Original Message -------

Lou Langholtz

2003-06-24 21:44 UTC #4 lore raw

In reply to jds

Quoted 34 lines · jds

Hi Andrew:

I have kernel panic when boot with kernel 2.5.73-mm1, in kernel 2.5.73
working good.

   Anex part the OOps:


   EPI: 0060:[<c20f480>]   not tainted VLI
   EFLAHS: 0010246
   EIP:   is at kobject_add+0xd0/0130
   eax: 736f70a3 ebx:736f705f  ecx:00000000   edx:ffff0001
   esi: 736f70a3 edi:dfd6653x  ebp:c157df40   esp:c157df24
   ds:  007b  es: 007b  ss:  0068

   Process:   swapper( pid:1, theaddinfo= c157c000 task = c157f880)
   
   Stack:

   c03ed505  00000059  dfd6653c  dfd80860  dfd66400 dfd653c  c157f75c
    
 
   Call Trace:

   [< c020f503>]  kobject_register+0x23/0x60
   [<             blk_register_queue+0x80/0xb0
                  nbd_init+0x1df/0x220
                  do_initcalls+0x2b/0xa0
                  init_workqueues+0x12/0x30
                  init+0x28/0x150
                  init+0x0/0x150
                  kernel_thread_helper+0x50/0xc

Quoted 4 lines

  Code: feff
  <0>Kernel Panic:  Attempted to kill init!

. . .

I'm *guestimating* that the following patch will fix this problem. Let me know if you use it wether it makes this problem go away or not. Note that to me at least, blk_init_queue() should be responsible for initializing this memory not the driver. Either way, something has to initialize request_queue.kobj.kset otherwise I think this is the result when the kset field can be any value.

Lou Langholtz

2003-06-24 21:46 UTC #5 lore raw

Quoted 6 lines

Quoted 3 lines
.. . .
I'm *guestimating* that the following patch will fix this problem. Let me know if you use it wether it makes this problem go away or not. Note that to me at least, blk_init_queue() should be responsible for initializing this memory not the driver. Either way, something has to initialize request_queue.kobj.kset otherwise I think this is the result when the kset field can be any value.

Woops... pressed send before doing the attachment...

block/nbd-new.c renamed from block/nbd.c +1 -0

@@ -695,6 +695,7 @@
 			put_disk(disk);
 			goto out;
 		}
+		memset(disk->queue, 0, sizeof(struct request_queue));
 		blk_init_queue(disk->queue, do_nbd_request, &nbd_lock);
 	}

jds

author

2003-06-24 23:33 UTC #6 lore raw

Hi Lou, Andrew:

Ok applied the patch Lou in kernel 2.5.73-mm1, change the .config CONFIG_BLK_DEV_NBD=y, compile again and kernel working good not more Oops.

In this moment testing kernel.

Thanks again ..... :)

Regards.

---------- Original Message -----------
From: Lou Langholtz <[email protected]>
To: jds <[email protected]>
Sent: Tue, 24 Jun 2003 16:00:48 -0600
Subject: Re: Kernel Panic in 2.5.73-mm1 OOps part.

Quoted 4 lines

Quoted 4 lines
Quoted 3 lines
.. . .

Quoted 8 lines

Quoted 7 lines
I'm *guestimating* that the following patch will fix this problem. Let me know if you use it wether it makes this problem go away or not. Note that to me at least, blk_init_queue() should be responsible for initializing this memory not the driver. Either way, something has to initialize request_queue.kobj.kset otherwise I think this is the result when the kset field can be any value.
Woops... pressed send before doing the attachment...

------- End of Original Message -------