Current bitkeeper tree seems to have problems with NBD.
As soon as I modprobe nbd (or boot with it compiled in)
I get this..
nbd: registered device at major 43
Unable to handle kernel paging request at virtual address 5a5a5a7e
printing eip:
c027864b
*pde = 00000000
Oops: 0000 [#1]
CPU: 0
EIP: 0060:[<c027864b>] Not tainted
EFLAGS: 00010206
EIP is at kobject_get+0xb/0x50
eax: 5a5a5a6a ebx: 5a5a5a6a ecx: c0492e7f edx: 00000000
esi: ffffffea edi: c60b91a0 ebp: c4f01f14 esp: c4f01f10
ds: 007b es: 007b ss: 0068
Process modprobe (pid: 1141, threadinfo=c4f00000 task=c6524000)
Stack: c60b91a0 c4f01f24 c0278319 5a5a5a6a c60b91a0 c4f01f38 c0278537 c60b91a0
c77f8004 c60b9004 c4f01f60 c03063e6 c60b91a0 c60b91a0 00000014 c0492e7d
c046f3c6 c77f8004 d087bf60 00000001 c4f01fa8 d08151d9 c77f8004 d087bf40
Call Trace:
[<c0278319>] kobject_init+0x29/0x50
[<c0278537>] kobject_register+0x17/0x50
[<c03063e6>] blk_register_queue+0x56/0x90
[<d08151d9>] nbd_init+0x1d9/0x250 [nbd]
[<c0144f5c>] sys_init_module+0x1cc/0x370
[<c010a027>] syscall_call+0x7/0xb
Code: 8b 43 14 85 c0 74 0c ff 43 14 89 d8 8b 5d fc 89 ec 5d c3 68
--
Dave Jones http://www.codemonkey.org.uk
On Thu, 10 Jul 2003, Dave Jones wrote:
> Current bitkeeper tree seems to have problems with NBD.
> As soon as I modprobe nbd (or boot with it compiled in)
> I get this..
>
> nbd: registered device at major 43
> Unable to handle kernel paging request at virtual address 5a5a5a7e
> printing eip:
> c027864b
> *pde = 00000000
> Oops: 0000 [#1]
> CPU: 0
> EIP: 0060:[<c027864b>] Not tainted
> EFLAGS: 00010206
> EIP is at kobject_get+0xb/0x50
> eax: 5a5a5a6a ebx: 5a5a5a6a ecx: c0492e7f edx: 00000000
> esi: ffffffea edi: c60b91a0 ebp: c4f01f14 esp: c4f01f10
> ds: 007b es: 007b ss: 0068
> Process modprobe (pid: 1141, threadinfo=c4f00000 task=c6524000)
> Stack: c60b91a0 c4f01f24 c0278319 5a5a5a6a c60b91a0 c4f01f38 c0278537 c60b91a0
> c77f8004 c60b9004 c4f01f60 c03063e6 c60b91a0 c60b91a0 00000014 c0492e7d
> c046f3c6 c77f8004 d087bf60 00000001 c4f01fa8 d08151d9 c77f8004 d087bf40
> Call Trace:
> [<c0278319>] kobject_init+0x29/0x50
> [<c0278537>] kobject_register+0x17/0x50
> [<c03063e6>] blk_register_queue+0x56/0x90
> [<d08151d9>] nbd_init+0x1d9/0x250 [nbd]
> [<c0144f5c>] sys_init_module+0x1cc/0x370
> [<c010a027>] syscall_call+0x7/0xb
>
> Code: 8b 43 14 85 c0 74 0c ff 43 14 89 d8 8b 5d fc 89 ec 5d c3 68
2.5.74-mm does not have this problem, could you try the following patch from Andrew's tree?
nbd-kobject-oops-fix.patch
That should fix the problem. I guess we need to push to Linus?
--
Paul
Rather than pushing the memset zero hack to NBD to work around this
problem, how about we fix this problem where it should be fixed - from
within the blk_init_queue() function. I'm sorry I'm not offerring a real
patch right here myself for this but I'd rather defer that to the blk_*
API experts. The basics of such a patch though would be to simply add
memset(&q->kobj, 0, sizeof(struct kobject)) to the top of the
blk_init_queue() function. Andrew's been super involved and has done
wonderful things with the block layer so I really want him to think
about where and how to best to initialize the new kobj field of
request_queue or to say why he (or someone else as qualified) believes
it should be the driver's responsibility to init this field (instead of
the blk_init_queue function init'ing it). Thanks!