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.
>>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.
On Thu, 5 Dec 2002, Michael wrote:
> 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
+++ linux/drivers/block/loop.c Mon Nov 11 15:44:33 2002
@@ -304,21 +304,16 @@
{
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
On Thu, Dec 05, 2002 at 01:36:27PM +0000, Hugh Dickins wrote:
> 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..
On Thu, Dec 05, 2002 at 01:36:27PM +0000, Hugh Dickins wrote:
> 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.