kernel BUG at drivers/block/loop.c:621

kernel BUG at drivers/block/loop.c:621

[Rob Landley]

I can reproduce the following in 2.6.16-rc5, User Mode Linux:

kernel BUG at drivers/block/loop.c:621!
Kernel panic - not syncing: BUG!

EIP: 0073:[<ffffe410>] CPU: 0 Not tainted ESP: 007b:b7de1f9c EFLAGS: 00200246
    Not tainted
EAX: 00000000 EBX: 000018be ECX: 00000013 EDX: 000018be
ESI: 000018bb EDI: 00000011 EBP: b7de1fb8 DS: 007b ES: 007b
09b87bb4:  [<0806c762>] show_regs+0x102/0x110
09b87bd0:  [<0805b6fc>] panic_exit+0x2c/0x50
09b87be0:  [<0807ff7d>] notifier_call_chain+0x2d/0x50
09b87c00:  [<08071095>] panic+0x75/0x120
09b87c20:  [<0812e181>] loop_thread+0x151/0x160
09b87c4c:  [<08065297>] run_kernel_thread+0x37/0x60
09b87cfc:  [<0805bbd1>] new_thread_handler+0x91/0xc0
09b87d20:  [<ffffe420>] disks+0xf7e7ec84/0x4

The reproduction sequence is a bit involved (my mount regression test and the 
current svn snapshot of busybox are involved), and running the following 
sequence of commands:

mount; mount -a; mount; mount /dev/loop1 /images/vfat.dir ; 
losetup /dev/loop1; ls; vi /etc/fstab; cat /etc/fstab; losetup /dev/loop0; 
mount /images/vfat.img /images/vfat.dir -o ro

The current busybox mount is still broken in a couple of known places (hence 
the testing; I'm fixing it).  But it probably shouldn't panic the kernel...

Rob
-- 
Never bet against the cheap plastic solution.

Re: [uml-devel] kernel BUG at drivers/block/loop.c:621

[Blaisorblade]

On Saturday 18 March 2006 01:12, Rob Landley wrote:
> I can reproduce the following in 2.6.16-rc5, User Mode Linux:
>
> kernel BUG at drivers/block/loop.c:621!
> Kernel panic - not syncing: BUG!
>
> EIP: 0073:[<ffffe410>] CPU: 0 Not tainted ESP: 007b:b7de1f9c EFLAGS:
> 00200246 Not tainted
> EAX: 00000000 EBX: 000018be ECX: 00000013 EDX: 000018be
> ESI: 000018bb EDI: 00000011 EBP: b7de1fb8 DS: 007b ES: 007b
> 09b87bb4:  [<0806c762>] show_regs+0x102/0x110
> 09b87bd0:  [<0805b6fc>] panic_exit+0x2c/0x50
> 09b87be0:  [<0807ff7d>] notifier_call_chain+0x2d/0x50
> 09b87c00:  [<08071095>] panic+0x75/0x120
> 09b87c20:  [<0812e181>] loop_thread+0x151/0x160
> 09b87c4c:  [<08065297>] run_kernel_thread+0x37/0x60
> 09b87cfc:  [<0805bbd1>] new_thread_handler+0x91/0xc0

The below is strange - GCC is putting disks in the .text section or kallsyms 
has some bug.

> 09b87d20:  [<ffffe420>] disks+0xf7e7ec84/0x4

> The reproduction sequence is a bit involved (my mount regression test and
> the current svn snapshot of busybox are involved), and running the
> following sequence of commands:
>
> mount; mount -a; mount; mount /dev/loop1 /images/vfat.dir ;
> losetup /dev/loop1; ls; vi /etc/fstab; cat /etc/fstab; losetup /dev/loop0;
> mount /images/vfat.img /images/vfat.dir -o ro
>
> The current busybox mount is still broken in a couple of known places
> (hence the testing; I'm fixing it).  But it probably shouldn't panic the
> kernel...

*) Is this reproducible on host?

*) I don't understand yet what UML may be doing wrong.
*) look at: that spin_lock (SMP kernel? SPINLOCK_DEBUG? Try enabling the 
latter and see what happens).

(a bio is a block I/O request)
*) given what the code says, on that line bio is NULL, i.e. loop_get_bio 
returned NULL, i.e. (I guess) wait_for_completion_interruptible returned, 
because someone else (loop_make_request) did "complete" on its param, but 
incorrectly as the "someone else" hadn't filled the lo->lo_bio.

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com

Re: [uml-devel] kernel BUG at drivers/block/loop.c:621

[Rob Landley]

On Friday 17 March 2006 7:24 pm, Blaisorblade wrote:
> On Saturday 18 March 2006 01:12, Rob Landley wrote:
> > I can reproduce the following in 2.6.16-rc5, User Mode Linux:
> >
> > kernel BUG at drivers/block/loop.c:621!
> > Kernel panic - not syncing: BUG!
> >
> > EIP: 0073:[<ffffe410>] CPU: 0 Not tainted ESP: 007b:b7de1f9c EFLAGS:
> > 00200246 Not tainted
> > EAX: 00000000 EBX: 000018be ECX: 00000013 EDX: 000018be
> > ESI: 000018bb EDI: 00000011 EBP: b7de1fb8 DS: 007b ES: 007b
> > 09b87bb4:  [<0806c762>] show_regs+0x102/0x110
> > 09b87bd0:  [<0805b6fc>] panic_exit+0x2c/0x50
> > 09b87be0:  [<0807ff7d>] notifier_call_chain+0x2d/0x50
> > 09b87c00:  [<08071095>] panic+0x75/0x120
> > 09b87c20:  [<0812e181>] loop_thread+0x151/0x160
> > 09b87c4c:  [<08065297>] run_kernel_thread+0x37/0x60
> > 09b87cfc:  [<0805bbd1>] new_thread_handler+0x91/0xc0
>
> The below is strange - GCC is putting disks in the .text section or
> kallsyms has some bug.
>
> > 09b87d20:  [<ffffe420>] disks+0xf7e7ec84/0x4

Isn't ffffe??? the FASTCALL page?

> > The reproduction sequence is a bit involved (my mount regression test and
> > the current svn snapshot of busybox are involved), and running the
> > following sequence of commands:
> >
> > mount; mount -a; mount; mount /dev/loop1 /images/vfat.dir ;
> > losetup /dev/loop1; ls; vi /etc/fstab; cat /etc/fstab; losetup
> > /dev/loop0; mount /images/vfat.img /images/vfat.dir -o ro
> >
> > The current busybox mount is still broken in a couple of known places
> > (hence the testing; I'm fixing it).  But it probably shouldn't panic the
> > kernel...
>
> *) Is this reproducible on host?

Haven't tried.  I value my laptop. :)

My host is running unbuntu 2.6.12, and my mount test requires a clean 
environment with nothing else mounted when it first runs.  (It basically 
needs to run as PID 1.  Among other things, it synthesizes variants of its 
own fstab...)

I don't think it's a uml bug, but I cc'd the UML list because that's where I 
can easily reproduce it.

Rob
-- 
Never bet against the cheap plastic solution.

Re: [uml-devel] kernel BUG at drivers/block/loop.c:621

[Blaisorblade]

On Saturday 18 March 2006 01:55, Rob Landley wrote:
> On Friday 17 March 2006 7:24 pm, Blaisorblade wrote:
> > On Saturday 18 March 2006 01:12, Rob Landley wrote:
> > > I can reproduce the following in 2.6.16-rc5, User Mode Linux:
> > >
> > > kernel BUG at drivers/block/loop.c:621!
> > > Kernel panic - not syncing: BUG!
> > >
> > > EIP: 0073:[<ffffe410>] CPU: 0 Not tainted ESP: 007b:b7de1f9c EFLAGS:
> > > 00200246 Not tainted
> > > EAX: 00000000 EBX: 000018be ECX: 00000013 EDX: 000018be
> > > ESI: 000018bb EDI: 00000011 EBP: b7de1fb8 DS: 007b ES: 007b
> > > 09b87bb4:  [<0806c762>] show_regs+0x102/0x110
> > > 09b87bd0:  [<0805b6fc>] panic_exit+0x2c/0x50
> > > 09b87be0:  [<0807ff7d>] notifier_call_chain+0x2d/0x50
> > > 09b87c00:  [<08071095>] panic+0x75/0x120
> > > 09b87c20:  [<0812e181>] loop_thread+0x151/0x160
> > > 09b87c4c:  [<08065297>] run_kernel_thread+0x37/0x60
> > > 09b87cfc:  [<0805bbd1>] new_thread_handler+0x9 1/0xc0
> >
> > The below is strange - GCC is putting disks in the .text section or
> > kallsyms has some bug.
> >
> > > 09b87d20:  [<ffffe420>] disks+0xf7e7ec84/0x4
>
> Isn't ffffe??? the FASTCALL page?

Sorry, didn't mention that according to ctags, disks is defined only as a 
struct member or as a static variable... clearly neither is valid on a call 
stack.

The call trace decoder filters out hex values outside _stext - _etext, but 
maybe it also considers valid the FASTCALL page... leading to this 
interesting bogus output :-)

> Haven't tried.  I value my laptop. :)

> My host is running unbuntu 2.6.12, and my mount test requires a clean
> environment with nothing else mounted when it first runs.  (It basically
> needs to run as PID 1.  Among other things, it synthesizes variants of its
> own fstab...)

> I don't think it's a uml bug, but I cc'd the UML list because that's where
> I can easily reproduce it.

Ok - didn't notice the LKML cc, sorry (it's really late).

> Rob

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

		
___________________________________ 
Yahoo! Messenger with Voice: chiama da PC a telefono a tariffe esclusive 
http://it.messenger.yahoo.com