Hi;
Thanks in advance if anyone can shed any light on this.
versions:
XFS kernel 2.4.0 tree (last night)
LVM-0.9 w/ software RAID patches
util-linux-2.10r
I updated my XFS tree to last nights version on kernel
2.4.0 and updated to all the most recent LVM kernel
and user space tools for 0.9. When doing a mount,
the resync daemon stops and will not continue until
reboot, but the kernel does not oops anymore. More
importantly (I think), during a umount, the following
oops occurs (attached is the ksymoops output at the
bottom of the oops). Prior to this point (test13-pre3
XFS tree), I would see a kernel oops when the raid5
resync daemon would stop as well. I am not seeing
that with the current system.
Interestingly, the lvcreate of my current system also
causes the resync daemon to hang when issuing the
lvcreate. I have passed this information on to Neil
Brown and will do so to the LVM list. However, I was
wondering about the the kernel oops from the umount:
-----------oops and ksymoops run----------------------------------
Unable to handle kernel NULL pointer dereference at virtual address 00000020
Jan 12 14:18:13 linuxdev kernel: c01318b3
Jan 12 14:18:13 linuxdev kernel: *pde = 00000000
Jan 12 14:18:13 linuxdev kernel: Oops: 0000
Jan 12 14:18:13 linuxdev kernel: CPU: 0
Jan 12 14:18:13 linuxdev kernel: EIP: 0010:[<c01318b3>]
Using defaults from ksymoops -t elf32-i386 -a i386
Jan 12 14:18:13 linuxdev kernel: EFLAGS: 00010102
Jan 12 14:18:13 linuxdev kernel: eax: 00000000 ebx: 00000000 ecx:
0000030f edx: c7e020c0
Jan 12 14:18:13 linuxdev kernel: esi: 00003a00 edi: 00000000 ebp:
c1989f40 esp: c1989f20
Jan 12 14:18:13 linuxdev kernel: ds: 0018 es: 0018 ss: 0018
Jan 12 14:18:13 linuxdev kernel: Process umount (pid: 929,
stackpage=c1989000)
Jan 12 14:18:13 linuxdev kernel: Stack: 00003a00 c456ae00 00000000 c7e020c0
00000000 00000000 3a000000 00000000
Jan 12 14:18:14 linuxdev kernel: c1989f54 c0131a8c 00003a00 00000000
c2676dc0 c1989f70 c0136363 00003a00
Jan 12 14:18:14 linuxdev kernel: c456ae00 ffffffff c19ab2e0 c1989f90
c1989fac c01364cb c2676dc0 00000000
Jan 12 14:18:15 linuxdev kernel: Call Trace: [<c0131a8c>] [<c0136363>]
[<c01364cb>] [<c0136502>] [<c0108f63>]
Jan 12 14:18:16 linuxdev kernel: Code: 8b 58 20 83 3d d0 87 34 c0 00 74 63
66 83 7d fa 00 74 0a 0f
>>EIP; c01318b3 <sync_buffers+33/1d0> <=====
Trace; c0131a8c <fsync_dev+10/3c>
Trace; c0136363 <do_umount+117/1c0>
Trace; c01364cb <sys_umount+bf/e8>
Trace; c0136502 <sys_oldumount+e/14>
Trace; c0108f63 <system_call+33/38>
Code; c01318b3 <sync_buffers+33/1d0>
00000000 <_EIP>:
Code; c01318b3 <sync_buffers+33/1d0> <=====
0: 8b 58 20 mov 0x20(%eax),%ebx <=====
Code; c01318b6 <sync_buffers+36/1d0>
3: 83 3d d0 87 34 c0 00 cmpl $0x0,0xc03487d0
Code; c01318bd <sync_buffers+3d/1d0>
a: 74 63 je 6f <_EIP+0x6f> c0131922
<sync_buffers+a2/1d0>
Code; c01318bf <sync_buffers+3f/1d0>
c: 66 83 7d fa 00 cmpw $0x0,0xfffffffa(%ebp)
Code; c01318c4 <sync_buffers+44/1d0>
11: 74 0a je 1d <_EIP+0x1d> c01318d0
<sync_buffers+50/1d0>
Code; c01318c6 <sync_buffers+46/1d0>
13: 0f 00 00 sldt (%eax)
|