loop problems continue in 2.4.3

loop problems continue in 2.4.3

[Ian Eure]

i'm still having loopback problems with linux 2.4.3, even though they
were supposed to be fixed. it doesn't deadlock my maching right away
anymore, but instead causes a kernel panic after 4-6 uses of the loop
device.

the message i get is: "Kernel panic: Invalid blocksize passed to
set_blocksize"

100% reproducable. has anyone else seen this?

i did compile with gcc 2.92.3, and i have hedrick's ide patches
applied.

anyone else see this?

p.s. please cc: me in any replies, i'm not on the list.

-- 
 ___________________________________
| Ian Eure - <ieure@insynq.com>     | "You're living in a facist world...
|         -  Developer -            | Freedom is a luxury." -Front Line
|        -  InsynQ, Inc. -          | Assembly, "Digital Tension Dementia"
| Your Internet Utility Company.tm  |________________________________________

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Sat, Apr 07 2001, Ian Eure wrote:
> i'm still having loopback problems with linux 2.4.3, even though they
> were supposed to be fixed. it doesn't deadlock my maching right away
> anymore, but instead causes a kernel panic after 4-6 uses of the loop
> device.
> 
> the message i get is: "Kernel panic: Invalid blocksize passed to
> set_blocksize"
> 
> 100% reproducable. has anyone else seen this?
> 
> i did compile with gcc 2.92.3, and i have hedrick's ide patches
> applied.
> 
> anyone else see this?

Nope, please add a printk like before set_blocksize in
drivers/block/loop.c and print the bs info, like so

        printk("loop: setting %d bs for %s\n", bs, kdevname(inode->i_rdev));
        set_blocksize(dev, bs);

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[Ian Eure]

i get this message when it panics:

-- snip --
loop: setting 534781920 bs for 07:86
Kernel panic: Invalid blocksize passed to set_blocksize
-- snip --

Jens Axboe writes:
 > On Sat, Apr 07 2001, Ian Eure wrote:
 > > i'm still having loopback problems with linux 2.4.3, even though they
 > > were supposed to be fixed. it doesn't deadlock my maching right away
 > > anymore, but instead causes a kernel panic after 4-6 uses of the loop
 > > device.
 > > 
 > > the message i get is: "Kernel panic: Invalid blocksize passed to
 > > set_blocksize"
 > > 
 > > 100% reproducable. has anyone else seen this?
 > > 
 > > i did compile with gcc 2.92.3, and i have hedrick's ide patches
 > > applied.
 > > 
 > > anyone else see this?
 > 
 > Nope, please add a printk like before set_blocksize in
 > drivers/block/loop.c and print the bs info, like so
 > 
 >         printk("loop: setting %d bs for %s\n", bs, kdevname(inode->i_rdev));
 >         set_blocksize(dev, bs);
 > 
 > -- 
 > Jens Axboe

-- 
 ___________________________________
| Ian Eure - <ieure@insynq.com>     | "You're living in a facist world...
|         -  Developer -            | Freedom is a luxury." -Front Line
|        -  InsynQ, Inc. -          | Assembly, "Digital Tension Dementia"
| Your Internet Utility Company.tm  |________________________________________

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Wed, Apr 11 2001, Ian Eure wrote:
> i get this message when it panics:
> 
> -- snip --
> loop: setting 534781920 bs for 07:86
> Kernel panic: Invalid blocksize passed to set_blocksize
> -- snip --

Ahm, how are you setting your loop device up? The above is completely
bogus.

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[Ian Eure]

Jens Axboe writes:
 > On Wed, Apr 11 2001, Ian Eure wrote:
 > > i get this message when it panics:
 > > 
 > > -- snip --
 > > loop: setting 534781920 bs for 07:86
 > > Kernel panic: Invalid blocksize passed to set_blocksize
 > > -- snip --
 > 
 > Ahm, how are you setting your loop device up? The above is completely
 > bogus.
 > 
`mount foo /mnt2 -oloop,dev'

-- 
 ___________________________________
| Ian Eure - <ieure@insynq.com>     | "You're living in a facist world...
|         -  Developer -            | Freedom is a luxury." -Front Line
|        -  InsynQ, Inc. -          | Assembly, "Digital Tension Dementia"
| Your Internet Utility Company.tm  |________________________________________

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Mon, Apr 16 2001, Ian Eure wrote:
> Jens Axboe writes:
>  > On Wed, Apr 11 2001, Ian Eure wrote:
>  > > i get this message when it panics:
>  > > 
>  > > -- snip --
>  > > loop: setting 534781920 bs for 07:86
>  > > Kernel panic: Invalid blocksize passed to set_blocksize
>  > > -- snip --
>  > 
>  > Ahm, how are you setting your loop device up? The above is completely
>  > bogus.
>  > 
> `mount foo /mnt2 -oloop,dev'

Majorly strange, will take a look.

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[David Woodhouse]

arthur-p@home.com said:
>  Well, I wrote the script. It has been running for 10 minutes now
> mounting and unmounting an iso image. Nothing happens. I guess I
> should be happy. Still don't undertand where the original Oops came
> from 


It's a great shame that your distribution vendor shipped klogd configured 
to destroy information. Please make sure you've reported this bug to them.

--
dwmw2

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Mon, Apr 16 2001, Mircea Damian wrote:
> But the guy said:
> "
> > disappers from cat /proc/mounts output, but the module 'loop' shows as
> > busy and cannot be removed even though there are no more loop mounts.
> "
> 
> So he has no loop mounts and he can not remove the module. This is a bug!

Ah indeed, I'll take a look.

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Mon, Apr 16 2001, Alexander Viro wrote:
> 
> 
> On Mon, 16 Apr 2001, Jens Axboe wrote:
> 
> > > I can mount the same file on the same mountpoint more than once. If I
> > > mount a file twice (same file on the same mount point)
> > 
> > This is a 2.4 feature
> 
> Ability to losetup different loop devices to the same underlying
> file is a bug, though. Not that it was new, though...

It's also so close to 'doctor it hurts' that I don't think that's a big
deal. Besides, if we later on want to have size limitited loop on files
(some have already expressed wishes in this direction), we'll do this
anyway.

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[Mircea Damian]

On Mon, Apr 16, 2001 at 05:30:45AM -0400, Alexander Viro wrote:
> 
> 
> On Mon, 16 Apr 2001, Jens Axboe wrote:
> 
> > > I can mount the same file on the same mountpoint more than once. If I
> > > mount a file twice (same file on the same mount point)
> > 
> > This is a 2.4 feature
> 
> Ability to losetup different loop devices to the same underlying
> file is a bug, though. Not that it was new, though...

But the guy said:
"
> disappers from cat /proc/mounts output, but the module 'loop' shows as
> busy and cannot be removed even though there are no more loop mounts.
"

So he has no loop mounts and he can not remove the module. This is a bug!


-- 
Mircea Damian
E-mails: dmircea@kappa.ro, dmircea@roedu.net
WebPage: http://taz.mania.k.ro/~dmircea/

Re: loop problems continue in 2.4.3

[Alexander Viro]

On Mon, 16 Apr 2001, Jens Axboe wrote:

> > I can mount the same file on the same mountpoint more than once. If I
> > mount a file twice (same file on the same mount point)
> 
> This is a 2.4 feature

Ability to losetup different loop devices to the same underlying
file is a bug, though. Not that it was new, though...

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Sun, Apr 15 2001, Arthur Pedyczak wrote:
> On Sat, 14 Apr 2001, Jeff Garzik wrote:
> 
> > Can you try 2.4.4-pre3?
> > ftp://ftp.us.kernel.org/pub/linux/kernel/testing/
> >
> I am testing loop behaviour in 2.4.3 and 3.4.4p3. I have noticed something
> disturbing:
> 
> I can mount the same file on the same mountpoint more than once. If I
> mount a file twice (same file on the same mount point)

This is a 2.4 feature

-- 
Jens Axboe

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sun, 15 Apr 2001, Arthur Pedyczak wrote:

> On Sat, 14 Apr 2001, Jeff Garzik wrote:
>
> > Can you try 2.4.4-pre3?
> > ftp://ftp.us.kernel.org/pub/linux/kernel/testing/
> >


...the same thing happens in 2.4.3...



> I am testing loop behaviour in 2.4.3 and 3.4.4p3. I have noticed something
> disturbing:
>
> I can mount the same file on the same mountpoint more than once. If I
> mount a file twice (same file on the same mount point)
> both mounts (identical) show when I do df or cat /proc/mounts. If I issue
> unmount (once), both mounts disappear from df output, but one of them
> remains in /proc/mounts. If I issue umount again, the second mount
> disappers from cat /proc/mounts output, but the module 'loop' shows as
> busy and cannot be removed even though there are no more loop mounts.
> lsmod shows loop being used by 1 process.
> If I repeat this whole procedure again, loop will be used by 2 processess
> in the end. I guess something is wrong here.
> This experiment has been done under 2.4.4pre3. I will try the same under
> 2.4.3.
>
> cheers,
> Arthur
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sat, 14 Apr 2001, Jeff Garzik wrote:

> Can you try 2.4.4-pre3?
> ftp://ftp.us.kernel.org/pub/linux/kernel/testing/
>
I am testing loop behaviour in 2.4.3 and 3.4.4p3. I have noticed something
disturbing:

I can mount the same file on the same mountpoint more than once. If I
mount a file twice (same file on the same mount point)
both mounts (identical) show when I do df or cat /proc/mounts. If I issue
unmount (once), both mounts disappear from df output, but one of them
remains in /proc/mounts. If I issue umount again, the second mount
disappers from cat /proc/mounts output, but the module 'loop' shows as
busy and cannot be removed even though there are no more loop mounts.
lsmod shows loop being used by 1 process.
If I repeat this whole procedure again, loop will be used by 2 processess
in the end. I guess something is wrong here.
This experiment has been done under 2.4.4pre3. I will try the same under
2.4.3.

cheers,
Arthur

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sat, 14 Apr 2001, Aaron Lunansky wrote:
Why not indeed? - should have thought about it myself

Well, I wrote the script. It has been running for 10 minutes now mounting
and unmounting an iso image. Nothing happens.
I guess I should be happy.
Still don't undertand where the original Oops
came
from

> If you're intent on making it oops why not write a script to
mount/unmount
> it repeatedly?
>
>
> Regards,
> Aaron
>
>
> -----Original Message-----
> From: Arthur Pedyczak <arthur-p@home.com>
> To: Jens Axboe <axboe@suse.de>
> CC: Linux kernel list <linux-kernel@vger.kernel.org>; Jeff Garzik
> <jgarzik@mandrakesoft.com>
> Sent: Sat Apr 14 08:46:49 2001
> Subject: Re: loop problems continue in 2.4.3
>
> On Sat, 14 Apr 2001, Jens Axboe wrote:
>
> [ SNIP..................]
> > > =====================
> > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging
> request at virtual address 7e92bfd7
> >
> > Please disable syslog decoding (it sucks) and feed it through ksymoops
> > instead.
> >
> > In other words, reproduce and dmesg | ksymoops instead.
> >
> >
> I tried to reproduce the error this morning and couldn't. Same kernel
> (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no
> problem. DOn't know what to think.
>
> Arthur
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: loop problems continue in 2.4.3

[Aaron Lunansky]

If you're intent on making it oops why not write a script to mount/unmount
it repeatedly?


Regards,
Aaron


-----Original Message-----
From: Arthur Pedyczak <arthur-p@home.com>
To: Jens Axboe <axboe@suse.de>
CC: Linux kernel list <linux-kernel@vger.kernel.org>; Jeff Garzik
<jgarzik@mandrakesoft.com>
Sent: Sat Apr 14 08:46:49 2001
Subject: Re: loop problems continue in 2.4.3

On Sat, 14 Apr 2001, Jens Axboe wrote:

[ SNIP..................]
> > =====================
> > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging
request at virtual address 7e92bfd7
>
> Please disable syslog decoding (it sucks) and feed it through ksymoops
> instead.
>
> In other words, reproduce and dmesg | ksymoops instead.
>
>
I tried to reproduce the error this morning and couldn't. Same kernel
(2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no
problem. DOn't know what to think.

Arthur

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: loop problems continue in 2.4.3

[Ola Garstad]

Just a tip:

I had the same problems when I started to use 2.4.x kernels. It was the compiler that caused the problem. 
I switch to using kgcc (comes with RH 7.0) and all the problems when away. :-)

----- Original Message ----- 
From: "Arthur Pedyczak" <arthur-p@home.com>
To: "Jens Axboe" <axboe@suse.de>
Cc: "Linux kernel list" <linux-kernel@vger.kernel.org>; "Jeff Garzik" <jgarzik@mandrakesoft.com>
Sent: Saturday, April 14, 2001 2:46 PM
Subject: Re: loop problems continue in 2.4.3


> On Sat, 14 Apr 2001, Jens Axboe wrote:
> 
> [ SNIP..................]
> > > =====================
> > > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7
> >
> > Please disable syslog decoding (it sucks) and feed it through ksymoops
> > instead.
> >
> > In other words, reproduce and dmesg | ksymoops instead.
> >
> >
> I tried to reproduce the error this morning and couldn't. Same kernel
> (2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no
> problem. DOn't know what to think.
> 
> Arthur
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
> 

Re: loop problems continue in 2.4.3

[Arthur Pedyczak]

On Sat, 14 Apr 2001, Jens Axboe wrote:

[ SNIP..................]
> > =====================
> > Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7
>
> Please disable syslog decoding (it sucks) and feed it through ksymoops
> instead.
>
> In other words, reproduce and dmesg | ksymoops instead.
>
>
I tried to reproduce the error this morning and couldn't. Same kernel
(2.4.3), same setup, same iso file. It mounted/unmounted 10 times with no
problem. DOn't know what to think.

Arthur

Re: loop problems continue in 2.4.3

[Jens Axboe]

On Fri, Apr 13 2001, Arthur Pedyczak wrote:
> Hi all,
> here are my $0.02 regarding loop in 2.4.3.
> 
> 1. mounted file
> mount -t iso9660 -o loop file.img /mnt/cdrom
>     worked o.k.
> 2. unmounted
> umount /mnt/cdrom
>     worked o.k.
> 3. mounted file
> mount -t iso9660 -o loop file.img /mnt/cdrom
>     worked o.k.
> 4. tried to unmount
> umount /mnt/cdrom
>    got oops:
> 
> =====================
> Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7

Please disable syslog decoding (it sucks) and feed it through ksymoops
instead.

In other words, reproduce and dmesg | ksymoops instead.

-- 
Jens Axboe

loop problems continue in 2.4.3

[Arthur Pedyczak]

Hi all,
here are my $0.02 regarding loop in 2.4.3.

1. mounted file
mount -t iso9660 -o loop file.img /mnt/cdrom
    worked o.k.
2. unmounted
umount /mnt/cdrom
    worked o.k.
3. mounted file
mount -t iso9660 -o loop file.img /mnt/cdrom
    worked o.k.
4. tried to unmount
umount /mnt/cdrom
   got oops:

=====================
Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7
Apr 13 20:50:03 cs865114-a kernel:  printing eip:
Apr 13 20:50:03 cs865114-a kernel: c0142cde
Apr 13 20:50:03 cs865114-a kernel: *pde = 00000000
Apr 13 20:50:03 cs865114-a kernel: Oops: 0000
Apr 13 20:50:03 cs865114-a kernel: CPU:    0
Apr 13 20:50:03 cs865114-a kernel: EIP:    0010:[invalidate_list+142/176]
Apr 13 20:50:03 cs865114-a kernel: EFLAGS: 00210203
Apr 13 20:50:03 cs865114-a kernel: eax: d26cc400   ebx: 7e92bfd7   ecx: d26cc400   edx: 00000000
Apr 13 20:50:03 cs865114-a kernel: esi: d3ab4220   edi: 7e92bfd7   ebp: c2433f14   esp: c2433eecApr 13 20:50:03 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Apr 13 20:50:03 cs865114-a kernel: Process umount (pid: 30929, stackpage=c2433000)Apr 13 20:50:03 cs865114-a kernel: Stack: 00000000 00000000 c2433f14 c2433f14 d26cc400 df9bf650 c0142d22 c0220e68Apr 13 20:50:03 cs865114-a kernel:        d26cc400 c2433f14 c2433f14 c2433f14 d26cc400 cb165220 df9bf5a0 df9bf650Apr 13 20:50:03 cs865114-a kernel:        c0135219 d26cc400 c013a662 d6636640 00000700 00200282 00000000 d141c4c0Apr 13 20:50:03 cs865114-a kernel: Call Trace: [<df9bf650>] [invalidate_inodes+34/96] [<df9bf5a0>] [<df9bf650>] [kill_super+121/288] [path_walk+1922/2160] [do_umount+449/464]
Apr 13 20:50:03 cs865114-a kernel:        [sys_umount+218/272] [filp_close+83/96] [sys_oldumount+12/16] [system_call+51/56]
Apr 13 20:50:03 cs865114-a kernel:
Apr 13 20:50:03 cs865114-a kernel: Code: 8b 3b 3b 5c 24 1c 75 9a 8b 04 24 29 05 a4 d7 27 c0 8b 44 24

===========================================

ksymoops:
===========================================
ksymoops 2.3.4 on i686 2.4.3.  Options used
     -v /usr/src/linux/vmlinux (specified)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.3/ (default)
     -m /usr/src/linux/System.map (specified)

Apr 13 20:50:03 cs865114-a kernel: Unable to handle kernel paging request at virtual address 7e92bfd7
Apr 13 20:50:03 cs865114-a kernel: c0142cde
Apr 13 20:50:03 cs865114-a kernel: *pde = 00000000
Apr 13 20:50:03 cs865114-a kernel: Oops: 0000
Apr 13 20:50:03 cs865114-a kernel: CPU:    0
Apr 13 20:50:03 cs865114-a kernel: EIP:    0010:[invalidate_list+142/176]
Apr 13 20:50:03 cs865114-a kernel: EFLAGS: 00210203
Apr 13 20:50:03 cs865114-a kernel: eax: d26cc400   ebx: 7e92bfd7   ecx: d26cc400   edx: 00000000
Apr 13 20:50:03 cs865114-a kernel: esi: d3ab4220   edi: 7e92bfd7   ebp: c2433f14   esp: c2433eecApr 13 20:50:03 cs865114-a kernel: ds: 0018   es: 0018   ss: 0018
Apr 13 20:50:03 cs865114-a kernel: Process umount (pid: 30929, stackpage=c2433000)Apr 13 20:50:03 cs865114-a kernel: Stack: 00000000 00000000 c2433f14 c2433f14 d26cc400 df9bf650 c0142d22 c0220e68Apr 13 20:50:03 cs865114-a kernel:        d26cc400 c2433f14 c2433f14 c2433f14 d26cc400 cb165220 df9bf5a0 df9bf650Apr 13 20:50:03 cs865114-a kernel:        c0135219 d26cc400 c013a662 d6636640 00000700 00200282 00000000 d141c4c0Apr 13 20:50:03 cs865114-a kernel: Call Trace: [<df9bf650>] [invalidate_inodes+34/96] [<df9bf5a0>] [<df9bf650>] [kill_super+121/288] [path_walk+1922/2160] [do_umount+449/464]
Apr 13 20:50:03 cs865114-a kernel: Code: 8b 3b 3b 5c 24 1c 75 9a 8b 04 24 29 05 a4 d7 27 c0 8b 44 24
Using defaults from ksymoops -t elf32-i386 -a i386

Code;  00000000 Before first symbol
00000000 <_EIP>:
Code;  00000000 Before first symbol
   0:   8b 3b                     mov    (%ebx),%edi
Code;  00000002 Before first symbol
   2:   3b 5c 24 1c               cmp    0x1c(%esp,1),%ebx
Code;  00000006 Before first symbol
   6:   75 9a                     jne    ffffffa2 <_EIP+0xffffffa2> ffffffa2 <END_OF_CODE+276b3b43/????>
Code;  00000008 Before first symbol
   8:   8b 04 24                  mov    (%esp,1),%eax
Code;  0000000b Before first symbol
   b:   29 05 a4 d7 27 c0         sub    %eax,0xc027d7a4
Code;  00000011 Before first symbol
  11:   8b 44 24 00               mov    0x0(%esp,1),%eax