Bug 152959 - Repeated Kernel Panics while using LVM Snapshot
Repeated Kernel Panics while using LVM Snapshot
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Heinz Mauelshagen
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2005-03-31 08:26 EST by Juergen Maniera
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-04 06:56:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
screenshot (509.14 KB, image/jpeg)
2005-03-31 08:42 EST, Juergen Maniera
no flags Details
lvdisplay of active snapshots (see next comment) (1.63 KB, text/plain)
2005-04-01 07:29 EST, Juergen Maniera
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:294 normal SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 5 2005-05-18 00:00:00 EDT

  None (edit)
Description Juergen Maniera 2005-03-31 08:26:37 EST
Description of problem:
Repeated Kernel Panics while using LVM Snapshot

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux AS release 3 (Taroon Update 4)
2.4.21-15.0.4.ELsmp #1 SMP Sat Jul 31 01:25:25 EDT 2004 i686 i686 i386 GNU/Linux

How reproducible:

The Kernel Panic happens while trying to make a backup of the follwing device:
/dev/vg_1/lv_imap2 ext3   268352200 126207656 128513056  50% /var/spool/imap2

The Backup of a similar devices on the same machine and the same HD worked well:
/dev/vg_1/lv_imap1 ext3   268352200  69058348 185662364  28% /var/spool/imap1

Steps to Reproduce:
1. lvcreate -L31G -s -n lv_snapshot_imap2 /dev/vg_1/lv_imap2

2. mount /dev/vg_1/lv_snapshot_imap2 /mnt/snapshot_imap2

3. dump -u0 -f imap2.dump /dev/vg_1/lv_snapshot_imap2

We tried three times and the crash happened after different amounts of data
being dumped:
7.7G    050328-1721/imap2.dump
83G     050329-0940/imap2.dump
29G     050329-0940/imap2_neu.dump

We did not make any more tests because it is our imap-server in production :-(
The problem is severe because we are without a reliable update of the user

Additional info:
The dump of the source-device (not the snapshot) works without kernel panics.
Additionaly we tried the scenario on a test machine first: we got one kernel
panic on the first day but after that we had an uptime of 62 days.
Comment 1 Juergen Maniera 2005-03-31 08:42:05 EST
Created attachment 112510 [details]
Comment 2 Ernie Petrides 2005-03-31 23:26:53 EST
Switching component to "kernel".
Comment 3 Juergen Maniera 2005-04-01 07:29:40 EST
Created attachment 112579 [details]
lvdisplay of active snapshots (see next comment)
Comment 4 Juergen Maniera 2005-04-01 07:31:47 EST

one more experience - I switched to an elder kernel we user first on our

2.4.21-15.0.4.ELsmp and with lvm-1.0.8-9

and the first backup of the critical partition succeeded. But after making
backups of the rest of the partitions an additional dump of the first partition
caused the "well known" kernel panic again :-(
I will attach the state of the snapshots after reboot of the machine - maybe it
is some help.
Comment 5 Heinz Mauelshagen 2005-04-04 06:56:46 EDT
Looks like another instance of BZ #135266.
Fix is scheduled for U5.
Comment 6 Heinz Mauelshagen 2005-04-04 08:53:32 EDT

*** This bug has been marked as a duplicate of 135266 ***
Comment 7 Ernie Petrides 2005-04-04 16:31:42 EDT
A fix for this problem was committed to the RHEL3 U5 patch pool
on 25-Jan-2005 (in kernel version 2.4.21-27.9.EL).
Comment 8 Tim Powers 2005-05-18 09:29:24 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.