LVM Oops

LVM Oops

[Yaroslav Klyukin]

Hello!

Oops happened after several days of normal operation diring snapshot.


Linux backup-db2 2.4.27 #1 SMP Fri Oct 22 05:22:55 EST 2004 i686 unknown 
unknown GNU/Linux

Filesystem - reiserfs.

Logical Volume Manager 1.0.8
Heinz Mauelshagen, Sistina Software  17/11/2003 (IOP 10)


Unable to handle kernel NULL pointer dereference at virtual address 00000004
c02adbea
*pde = 126d9001
Oops: 0002
CPU:    0
EIP:    0010:[<c02adbea>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: f8c3b4b0   ebx: fb20bde8   ecx: f89edc38   edx: 00000000
esi: 33dbdf00   edi: 00000001   ebp: 00000803   esp: c5bc3dac
ds: 0018   es: 0018   ss: 0018
Process kupdated (pid: 9, stackpage=c5bc3000)
Stack: 00000038 00000803 00000000 eae59400 f4ff7800 f4ff7970 00002000 
c02aa5fa
        c5bc3e00 c5bc3df8 33dbc580 f4ff7800 f73a9000 00000400 f77db240 
eae59570
        f73a9000 33dbc580 0002cdd0 33dbdf38 33dbdf38 08030803 00003a06 
f2046d00
Call Trace:    [<c02aa5fa>] [<c02aa727>] [<c022a4be>] [<c022a59e>] 
[<c02b8d08>]
   [<c013ebdc>] [<c013ece5>] [<c0142b48>] [<c0142e41>] [<c01072b6>] 
[<c0142d50>]
   [<c0105000>] [<c01057ae>] [<c0142d50>]
Code: 89 42 04 8b 03 89 48 04 89 01 89 59 04 89 0b 89 ca 90 8d 74


 >>EIP; c02adbea <lvm_snapshot_remap_block+aa/100>   <=====

Trace; c02aa5fa <lvm_map+36a/480>
Trace; c02aa727 <lvm_make_request_fn+17/30>
Trace; c022a4be <generic_make_request+be/140>
Trace; c022a59e <submit_bh+5e/130>
Trace; c02b8d08 <netif_receive_skb+188/1c0>
Trace; c013ebdc <write_locked_buffers+2c/40>
Trace; c013ece5 <write_some_buffers+f5/140>
Trace; c0142b48 <sync_old_buffers+78/b0>
Trace; c0142e41 <kupdate+f1/1c0>
Trace; c01072b6 <ret_from_fork+6/20>
Trace; c0142d50 <kupdate+0/1c0>
Trace; c0105000 <_stext+0/0>
Trace; c01057ae <arch_kernel_thread+2e/40>
Trace; c0142d50 <kupdate+0/1c0>

Code;  c02adbea <lvm_snapshot_remap_block+aa/100>
00000000 <_EIP>:
Code;  c02adbea <lvm_snapshot_remap_block+aa/100>   <=====
    0:   89 42 04                  mov    %eax,0x4(%edx)   <=====
Code;  c02adbed <lvm_snapshot_remap_block+ad/100>
    3:   8b 03                     mov    (%ebx),%eax
Code;  c02adbef <lvm_snapshot_remap_block+af/100>
    5:   89 48 04                  mov    %ecx,0x4(%eax)
Code;  c02adbf2 <lvm_snapshot_remap_block+b2/100>
    8:   89 01                     mov    %eax,(%ecx)
Code;  c02adbf4 <lvm_snapshot_remap_block+b4/100>
    a:   89 59 04                  mov    %ebx,0x4(%ecx)
Code;  c02adbf7 <lvm_snapshot_remap_block+b7/100>
    d:   89 0b                     mov    %ecx,(%ebx)
Code;  c02adbf9 <lvm_snapshot_remap_block+b9/100>
    f:   89 ca                     mov    %ecx,%edx
Code;  c02adbfb <lvm_snapshot_remap_block+bb/100>
   11:   90                        nop
Code;  c02adbfc <lvm_snapshot_remap_block+bc/100>
   12:   8d 74 00 00               lea    0x0(%eax,%eax,1),%esi


1 error issued.  Results may not be reliable.

-- 
Senior Systems Administrator, NiuTech LLC.
AIM: infiniteparticle
Cellular: (561) 843-1552

Re: LVM Oops

[Bernd Eckenfels]

In article <418428C6.7070707@staff.theuseful.com> you wrote:
> Oops happened after several days of normal operation diring snapshot.

Was the snapshot volumne full? I once had oopses in that situation (with XFS).

Greetings
Bernd

Re: LVM Oops

[Chris Wedgwood]

On Sun, Oct 31, 2004 at 02:35:57AM +0100, Bernd Eckenfels wrote:

> Was the snapshot volumne full? I once had oopses in that situation
> (with XFS).

Which version of XFS and when?  The XFS block allocator uses more
stack in low-memory conditions and would over-flow 4K stacks
previously but Nathan made some changes which should make it better.


  --cw

Re: LVM Oops

[Bernd Eckenfels]

On Sat, Oct 30, 2004 at 07:21:33PM -0700, Chris Wedgwood wrote:
> Which version of XFS and when?  The XFS block allocator uses more
> stack in low-memory conditions and would over-flow 4K stacks
> previously but Nathan made some changes which should make it better.

It was some 2.4 version, but the stacktrace was not related to XFS I think.
It was just that reproducible one got panic or oops (not sure) if the
snapshot volumne was full. Hevent tried that with 2.6 yet, will do.

Greetings
Bernd
-- 
  (OO)      -- Bernd_Eckenfels@Mörscher_Strasse_8.76185Karlsruhe.de --
 ( .. )      ecki@{inka.de,linux.de,debian.org}  http://www.eckes.org/
  o--o     1024D/E383CD7E  eckes@IRCNet  v:+497211603874  f:+497211606754
(O____O)  When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!

Re: LVM Oops

[Bernd Eckenfels]

In article <20041031091355.GA27407@lina.inka.de> you wrote:
> It was some 2.4 version, but the stacktrace was not related to XFS I think.
> It was just that reproducible one got panic or oops (not sure) if the
> snapshot volumne was full. Hevent tried that with 2.6 yet, will do.

Ok, I just retested with 2.6.8.1 and lvm2 on 2 sd disks, I no longer get oops  when
the snapshot fills up. (However I cant control a policy what should happen
on snapshot fillup. Currently it looks like dm-snap is always invalidating
the snapshot LV. Other option would be to block IO (on the original drive)
or return ENOSPC. I can think of situations where this is desired.

My inital problems howwever have been with lvm1 meta data volumnes and 2.4,
cant test those anymore.

Greetings
Bernd