[Top] [All Lists]

RE: oops umounting full LVM snapshots

To: "'Keith Owens'" <kaos@xxxxxxx>, "'linux-xfs@xxxxxxxxxxx'" <linux-xfs@xxxxxxxxxxx>
Subject: RE: oops umounting full LVM snapshots
From: "Stephenson, Dale" <dstephenson@xxxxxxxxxxxxxx>
Date: Mon, 25 Feb 2002 08:44:52 -0800
Sender: owner-linux-xfs@xxxxxxxxxxx
At Keith Owens' suggestion, I've rerun the oops output using the System Map
and a more recent ksymoops.
This oops was generated by filling two mounted LVM snapshots of an XFS
filesystem, and then umounting them both.  Both umounts resulted in I/O
errors and xfs_force_shutdown calls, and the second umount oopsed.  The
snapshots are a read only device, and they were mounted

---oops start---
ksymoops 2.4.3 on i686 2.4.17-1snap.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.17-1snap/ (default)
     -m /boot/System.map-2.4.17-1snap (default)

Warning: You did not tell me where to find symbol information.  I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc.  ksymoops -h explains the options.

Warning (compare_maps): mismatch on symbol partition_name  , ksyms_base says
c024ed90, System.map says c014bde0.  Ignoring ksyms_base entry
Unable to handle kernel NULL pointer dereference at virtual address 00000020

*pde = 00000000 
Oops: 0000 
CPU:    0 
EIP:    0010:[<c012ea13>]    Not tainted 
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206 
eax: 00000000   ebx: 00000000   ecx: 00003a02   edx: 00003a02 
esi: 00000006   edi: 00000000   ebp: 00000000   esp: c1615e8c 
ds: 0018   es: 0018   ss: 0018 
Process umount (pid: 1118, stackpage=c1615000) 
Stack: c3e3e460 c3c99800 c3b8b360 00000000 3a020168 00000000 c012eaf8
       00000001 c3756220 c01d2270 00003a02 00000001 c3c99800 c01bc7d7
       00000000 c3c99800 c01c3e61 c3c99800 00000001 c03485c0 00000000
Call Trace: [<c012eaf8>] [<c01d2270>] [<c01bc7d7>] [<c01c3e61>] [<c01d2c9a>]

   [<c01da79c>] [<c0131eb8>] [<c014090e>] [<c013579f>] [<c0140f61>]
   [<c0140f7c>] [<c0106d7b>]  
Code: 8b 53 20 89 54 24 14 0f b7 54 24 12 66 39 53 0c 75 7b 83 7b  

>>EIP; c012ea12 <invalidate_bdev+3e/104>   <=====
Trace; c012eaf8 <__invalidate_buffers+20/2c>
Trace; c01d2270 <pagebuf_target_clear+10/2c>
Trace; c01bc7d6 <xfs_unmountfs+c2/fc>
Trace; c01c3e60 <xfs_unmount+170/180>
Trace; c01d2c9a <fs_dounmount+5a/74>
Trace; c01da79c <linvfs_put_super+30/a0>
Trace; c0131eb8 <kill_super+bc/16c>
Trace; c014090e <__mntput+1e/24>
Trace; c013579e <path_release+26/2c>
Trace; c0140f60 <sys_umount+a8/b8>
Trace; c01204f4 <sys_munmap+34/54>
Trace; c0140f7c <sys_oldumount+c/10>
Trace; c0106d7a <system_call+32/38>
Code;  c012ea12 <invalidate_bdev+3e/104>
00000000 <_EIP>:
Code;  c012ea12 <invalidate_bdev+3e/104>   <=====
   0:   8b 53 20                  mov    0x20(%ebx),%edx   <=====
Code;  c012ea14 <invalidate_bdev+40/104>
   3:   89 54 24 14               mov    %edx,0x14(%esp,1)
Code;  c012ea18 <invalidate_bdev+44/104>
   7:   0f b7 54 24 12            movzwl 0x12(%esp,1),%edx
Code;  c012ea1e <invalidate_bdev+4a/104>
   c:   66 39 53 0c               cmp    %dx,0xc(%ebx)
Code;  c012ea22 <invalidate_bdev+4e/104>
  10:   75 7b                     jne    8d <_EIP+0x8d> c012ea9e
Code;  c012ea24 <invalidate_bdev+50/104>
  12:   83 7b 00 00               cmpl   $0x0,0x0(%ebx)

2 warnings issued.  Results may not be reliable.

---oops end---

Dale Stephenson

<Prev in Thread] Current Thread [Next in Thread>