Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Post by Michae » Fri, 06 Dec 2002 14:30:21


Firstly, this is truly a terrific kernel(for me), fixed alot of stability issues I had.
Have to wonder why keyboard/mouse support is so well "hidden" though =)
Anyway, my issue is a 'oops' whenever I mount a ISO image file.
(I have compiled the loop device as a module)

example :
spam michael # mount -o loop stuff/linux-cd/knoppix/orig/KNOPPIX_V3.1-08-11-2002-EN.iso /mnt/iso
Then It becomes a zombie.

ksymoops 2.4.8 on i586 2.5.47-xfs.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.5.47-xfs/ (default)
     -m /usr/src/linux/System.map (default)

Error (regular_file): read_system_map stat /usr/src/linux/System.map failed
Unable to handle kernel NULL pointer dereference at virtual address 00000000
00000000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0060:[<00000000>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210282
eax: c02b95c0   ebx: e4a4ec20   ecx: e4a4ec20   edx: cc192480
esi: e7faedc0   edi: e7faedc0   ebp: 00000000   esp: e073df24
ds: 0068   es: 0068   ss: 0068
Stack: c01cea8c cbf21348 e4a4ec20 e073df5c 00001000 ec9d4540 e073df64 00000000
       ec9d46d2 e4a4ec20 e073df5c 00001000 ec9d4540 e073df64 00000000 00000000
       cc226000 dfcb1000 00001000 c0116d8e 00000000 00000000 ec9d4722 cc226000
Call Trace: [<c01cea8c>]  [<ec9d4540>]  [<ec9d46d2>]  [<ec9d4540>]  [<c0116d8e>]
  [<ec9d4722>]  [<ec9d479e>]  [<ec9d4d85>]  [<ec9d4ca0>]  [<c01070c1>]
Code:  Bad EIP value.

Quote:>>EIP; 00000000 Before first symbol
>>eax; c02b95c0 <proc_root+23e0/2e80>
>>ebx; e4a4ec20 <xfrm_policy_list+2472ffbc/2858f3fc>
>>ecx; e4a4ec20 <xfrm_policy_list+2472ffbc/2858f3fc>
>>edx; cc192480 <xfrm_policy_list+be7381c/2858f3fc>
>>esi; e7faedc0 <xfrm_policy_list+27c9015c/2858f3fc>
>>edi; e7faedc0 <xfrm_policy_list+27c9015c/2858f3fc>
>>esp; e073df24 <xfrm_policy_list+2041f2c0/2858f3fc>

Trace; c01cea8c <pagebuf_offset+1f8c/eb00>
Trace; ec9d4540 <[loop]lo_read_actor+0/100>
Trace; ec9d46d2 <[loop]do_lo_receive+92/a0>
Trace; ec9d4540 <[loop]lo_read_actor+0/100>
Trace; c0116d8e <__wake_up+6e/80>
Trace; ec9d4722 <[loop]lo_receive+42/80>
Trace; ec9d479e <[loop]do_bio_filebacked+3e/80>
Trace; ec9d4d85 <[loop]loop_thread+e5/160>
Trace; ec9d4ca0 <[loop]loop_thread+0/160>
Trace; c01070c1 <enable_hlt+1e1/200>

1 warning and 1 error issued.  Results may not be reliable.

Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Post by Hugh Dickin » Fri, 06 Dec 2002 15:40:09



> Firstly, this is truly a terrific kernel(for me), fixed alot of stability issues I had.
> Have to wonder why keyboard/mouse support is so well "hidden" though =)
> Anyway, my issue is a 'oops' whenever I mount a ISO image file.
> (I have compiled the loop device as a module)

> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> Code:  Bad EIP value.

> Trace; c01cea8c <pagebuf_offset+1f8c/eb00>
> Trace; ec9d4540 <[loop]lo_read_actor+0/100>
> Trace; ec9d46d2 <[loop]do_lo_receive+92/a0>
> Trace; ec9d4540 <[loop]lo_read_actor+0/100>

If your xfs[cvs] resembles the xfs source in 2.5.50-mm1, then it looks
to me like fs/xfs/linux has a .sendfile = linvfs_sendfile in xfs_file.c
(which assures the loop driver it can loop this file for reading), but
lacks a .vop_ioctl = xfs_sendfile (and its extern) in xfs_vnodeops.c.

But I've not delved into XFS, for all I know that code may not be ready
to use yet: Christoph can say.  And to get further with the 2.5.47 loop,
you'll also need this patch (in 2.5.48):

--- 2.5.47/drivers/block/loop.c Mon Nov 11 12:34:14 2002

 {
        struct lo_read_data cookie;
        struct file *file;
-       int error;
+       int retval;

        cookie.lo = lo;
        cookie.data = kmap(bvec->bv_page) + bvec->bv_offset;
        cookie.bsize = bsize;
-
-       /* umm, what does this lock actually try to protect? */
-       spin_lock_irq(&lo->lo_lock);
        file = lo->lo_backing_file;
-       spin_unlock_irq(&lo->lo_lock);
-
-       error = file->f_op->sendfile(file, &pos, bvec->bv_len,
+       retval = file->f_op->sendfile(file, &pos, bvec->bv_len,
                        lo_read_actor, &cookie);
        kunmap(bvec->bv_page);
-       return error;
+       return (retval < 0)? retval: 0;
 }

 static int

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Post by Christoph Hellwi » Fri, 06 Dec 2002 16:10:10



> If your xfs[cvs] resembles the xfs source in 2.5.50-mm1, then it looks
> to me like fs/xfs/linux has a .sendfile = linvfs_sendfile in xfs_file.c
> (which assures the loop driver it can loop this file for reading), but
> lacks a .vop_ioctl = xfs_sendfile (and its extern) in xfs_vnodeops.c.

> But I've not delved into XFS, for all I know that code may not be ready
> to use yet: Christoph can say.

I've still had a few issues with the sendfile code.  I hope I can get
it working very soon.  One of the problems is that the xfss tree is
still at 2.5.47 and needs the below fix.  If only the module mess in
mainline could get sorted out a bit more..

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

Kernel 2.5.47-xfs[cvs] Oops when mounting ISO image.

Post by Christoph Hellwi » Fri, 06 Dec 2002 22:00:14



> If your xfs[cvs] resembles the xfs source in 2.5.50-mm1, then it looks
> to me like fs/xfs/linux has a .sendfile = linvfs_sendfile in xfs_file.c
> (which assures the loop driver it can loop this file for reading), but
> lacks a .vop_ioctl = xfs_sendfile (and its extern) in xfs_vnodeops.c.

> But I've not delved into XFS, for all I know that code may not be ready
> to use yet: Christoph can say.  And to get further with the 2.5.47 loop,
> you'll also need this patch (in 2.5.48):

It's fixed now.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/