[linux-lvm] oops

[linux-lvm] oops

[Jan Niehusmann]

Here is the oops I mentioned on IRC.

# dmsetup table vgraid-kernelsource
0 2097152 linear 254:029 68059136
# dmsetup table vgraid-pvmove0
0 4194304 linear 003:004 64288496

(so vgraid-kernelsource points behind the end of vgraid-pvmove0)

# cat /dev/vgraid/kernelsource (which is a symlink to
				/dev/mapper/vgraid-kernelsource)
Segmentation fault

ksymoops 2.4.8 on i686 2.4.22.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.4.22/ (default)
     -m /boot/System.map-2.4.22 (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.

Aug 28 23:22:07 sirith kernel: Unable to handle kernel paging request at virtual address 0d420295
Aug 28 23:22:07 sirith kernel: e0935bcb
Aug 28 23:22:07 sirith kernel: *pde = 00000000
Aug 28 23:22:07 sirith kernel: Oops: 0000
Aug 28 23:22:07 sirith kernel: CPU:    0
Aug 28 23:22:07 sirith kernel: EIP:    0010:[<e0935bcb>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
Aug 28 23:22:07 sirith kernel: EFLAGS: 00210292
Aug 28 23:22:07 sirith kernel: eax: c2f20770   ebx: d85f3d00   ecx: e081e01c   edx: 0d420285
Aug 28 23:22:07 sirith kernel: esi: 00100000   edi: d587b740   ebp: 00000000   esp: cffd7e40
Aug 28 23:22:07 sirith kernel: ds: 0018   es: 0018   ss: 0018
Aug 28 23:22:07 sirith kernel: Process cat (pid: 7599, stackpage=cffd7000)
Aug 28 23:22:07 sirith kernel: Stack: e081e01c d587b740 00000000 c2f20770 c2f20764 d587b740 00100000 00000008 
Aug 28 23:22:07 sirith kernel:        00000000 c01b9030 c02e5ce8 00000000 d587b740 d587b740 c114531c 00000000 
Aug 28 23:22:07 sirith kernel:        d587b740 00000008 00000000 00001000 c01b90db 00000000 d587b740 00000000 
Aug 28 23:22:07 sirith kernel: Call Trace:    [<c01b9030>] [<c01b90db>] [<c013d584>] [<c0133d9f>] [<c012c77f>]
Aug 28 23:22:07 sirith kernel:   [<c01406a0>] [<c012cc40>] [<c012cd92>] [<c012cc40>] [<c013a853>] [<c010730f>]
Aug 28 23:22:07 sirith kernel: Code: ff 52 10 e9 32 ff ff ff 31 f6 e9 31 ff ff ff 89 d8 ff 00 0f 


>>EIP; e0935bcb <[dm-mod]dm_request+17b/1d0>   <=====

>>eax; c2f20770 <_end+2c318c4/2059f1d4>
>>ebx; d85f3d00 <_end+18304e54/2059f1d4>
>>ecx; e081e01c <_end+2052f170/2059f1d4>
>>edi; d587b740 <_end+1558c894/2059f1d4>
>>esp; cffd7e40 <_end+fce8f94/2059f1d4>

Trace; c01b9030 <generic_make_request+e0/130>
Trace; c01b90db <submit_bh+5b/a0>
Trace; c013d584 <block_read_full_page+134/260>
Trace; c0133d9f <__alloc_pages+3f/170>
Trace; c012c77f <do_generic_file_read+29f/440>
Trace; c01406a0 <blkdev_get_block+0/60>
Trace; c012cc40 <file_read_actor+0/a0>
Trace; c012cd92 <generic_file_read+b2/1b0>
Trace; c012cc40 <file_read_actor+0/a0>
Trace; c013a853 <sys_read+a3/130>
Trace; c010730f <system_call+33/38>

Code;  e0935bcb <[dm-mod]dm_request+17b/1d0>
00000000 <_EIP>:
Code;  e0935bcb <[dm-mod]dm_request+17b/1d0>   <=====
   0:   ff 52 10                  call   *0x10(%edx)   <=====
Code;  e0935bce <[dm-mod]dm_request+17e/1d0>
   3:   e9 32 ff ff ff            jmp    ffffff3a <_EIP+0xffffff3a>
Code;  e0935bd3 <[dm-mod]dm_request+183/1d0>
   8:   31 f6                     xor    %esi,%esi
Code;  e0935bd5 <[dm-mod]dm_request+185/1d0>
   a:   e9 31 ff ff ff            jmp    ffffff40 <_EIP+0xffffff40>
Code;  e0935bda <[dm-mod]dm_request+18a/1d0>
   f:   89 d8                     mov    %ebx,%eax
Code;  e0935bdc <[dm-mod]dm_request+18c/1d0>
  11:   ff 00                     incl   (%eax)
Code;  e0935bde <[dm-mod]dm_request+18e/1d0>
  13:   0f 00 00                  sldtl  (%eax)


1 warning issued.  Results may not be reliable.

[linux-lvm] Oops

[Chris Laycock]

[-- Attachment #1: Type: text/plain, Size: 313 bytes --]

Sorry for the double post. I was having email problems and have 
inadvertently posted the same problem twice.

Sorry,

Chris.

-------------------
Chris Laycock
IT Specialist 
IBM Global Services (IDO)

LITS, Stevenage
Mail point: K3 STEV UK
Email: LaycockC@uk.ibm.com
Tel : (01438) 76-9460  (internal: 44-9460)


[-- Attachment #2: Type: text/html, Size: 462 bytes --]

[linux-lvm] dm chunk size is 512?

[Jason Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I modified lvm2 to display the snapshot chunks used from device-mapper, but 
it's reporting them in 512-byte units (just saw 204800 for a 100mb volume).

My question is, is this supposed to be static (it's from dm proper, not lvm2) 
at that size?  Does lvcreate -s -c <size> change anything?  It would be great 
to force the size for device-mapper snapshot volumes, since dm currently 
thrashes a software raid 5 array during snapshots.

Thanks.

- -- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+UfVQm5qEoSbpT3kRAt1GAKCCIyOHHHhBqzzxRLUG2NYtNFES3wCfSlCI
gXCGSPG6oavRpciyHp7GMAI=
=UOrR
-----END PGP SIGNATURE-----

[linux-lvm] Oops

[Jason Smith]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 18 February 2003 03:56 pm, Jason Smith wrote:
> lvm2) at that size?  Does lvcreate -s -c <size> change anything?  It would

Sent this too early.  I see what it's doing.  Sorry for spamming the list.

- -- 
Jason Smith
Open Enterprise Systems
Bangkok, Thailand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+Ufzfm5qEoSbpT3kRAuloAJwJNo3oT+34ur7+v1/rZl6dZNqCygCeIWVe
3yMs42AB8HHKf387D1JknMI=
=29xW
-----END PGP SIGNATURE-----

[linux-lvm] OOPS

[Ryan Murray]

[-- Attachment #1: Type: text/plain, Size: 4063 bytes --]

Kernel is 2.2.14 with 0.8i LVM patch, and Solar Designer's security
patch.  No module support is in the kernel, so the warnings/errors from
ksymoops can be safely ignored.

When the oops occurs, the machine stays alive, but new processes don't
run.  You can ping it, you can *connect* to a tcp port, but no TCP port
will actually do anything if it tries to fork/exec.

This happened several times in one day with 2.2.13.  Almost every time
it is an rsync of ftp.debian.org that tickles the bug.  I don't have
data from the earlier OOPSes.  This one was copied down from a digital
camera snapshot of the console screen, so if something looks wildly
incorrect, I can double check from the picture.

The system is otherwise a normal Debian GNU/Linux 2.2 (potato) system.

ksymoops 2.3.3 on i686 2.2.14.  Options used
     -V (default)
     -k /proc/ksyms (default)
     -l /proc/modules (default)
     -o /lib/modules/2.2.14/ (default)
     -m /boot/System.map-2.2.14 (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.

Error (regular_file): read_ksyms stat /proc/ksyms failed
No modules in ksyms, skipping objects
No ksyms, skipping lsmod
Unable to handle kernel paging request at virtual address 0fcfb018
current->tss.cr3 = 0258d000, %cr3 = 0258d000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c012f754>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010206
eax: 0fcfb000   ebx: 00000000   ecx: c8030ef0   edx: c5967a78
esi: c8030ee0   edi: c5967a40   ebp: 00000001   esp: c1ab7e80
ds: 0018   es: 0018   ss: 0018
Process rsync (pid: 5745, process nr: 107, stackpage=c1ab7000)
Stack: c5967a40 c012e1fa c8030ee0 c1ab7ec4 c1ab7ebc 00001006 00000246 00001006
       c012f1bc fffffd56 00000d5e c01d95b0 00135927 c01fc370 cfcfb000 c1ab6000
       c01fbb70 c1ab7ec4 c1ab7ec4 c012f224 00001006 c01d95b0 00135927 c01fc370
Call Trace: [<c012e1fa>] [<c012f1bc>] [<c012f224>] [<c012f581>] [<c012f6e0>] [<c0139e30>] [<c012999f>]
       [<c0129b88>] [<c0129c51>] [<c0127b27>] [<c0109018>]
Code: 8b 40 18 85 c0 74 02 89 c3 85 db 74 0d 8b 43 08 85 c0 74 06

>>EIP; c012f754 <iput+18/1f0>   <=====
Trace; c012e1fa <prune_dcache+a2/110>
Trace; c012f1bc <try_to_free_inodes+bc/fc>
Trace; c012f224 <grow_inodes+20/198>
Trace; c012f581 <get_new_inode+b9/11c>
Trace; c012f6e0 <iget+60/6c>
Trace; c0139e30 <ext2_lookup+5c/90>
Trace; c012999f <real_lookup+4f/a4>
Trace; c0129b88 <lookup_dentry+10c/1ac>
Trace; c0129c51 <__namei+29/5c>
Trace; c0127b27 <sys_newlstat+13/64>
Trace; c0109018 <system_call+34/38>
Code;  c012f754 <iput+18/1f0>
00000000 <_EIP>:
Code;  c012f754 <iput+18/1f0>   <=====
   0:   8b 40 18                  mov    0x18(%eax),%eax   <=====
Code;  c012f757 <iput+1b/1f0>
   3:   85 c0                     test   %eax,%eax
Code;  c012f759 <iput+1d/1f0>
   5:   74 02                     je     9 <_EIP+0x9> c012f75d <iput+21/1f0>
Code;  c012f75b <iput+1f/1f0>
   7:   89 c3                     mov    %eax,%ebx
Code;  c012f75d <iput+21/1f0>
   9:   85 db                     test   %ebx,%ebx
Code;  c012f75f <iput+23/1f0>
   b:   74 0d                     je     1a <_EIP+0x1a> c012f76e <iput+32/1f0>
Code;  c012f761 <iput+25/1f0>
   d:   8b 43 08                  mov    0x8(%ebx),%eax
Code;  c012f764 <iput+28/1f0>
  10:   85 c0                     test   %eax,%eax
Code;  c012f766 <iput+2a/1f0>
  12:   74 06                     je     1a <_EIP+0x1a> c012f76e <iput+32/1f0>


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


-- 
Ryan Murray, (rmurray@cyberhqz.com, rmurray@stormix.com)
Programmer, Stormix Technologies Inc.
The opinions expressed here are my own.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]