Bug 59970 - copy large file from e3 to e2 under kernel 2.4.9-21 causes kernel panic
Summary: copy large file from e3 to e2 under kernel 2.4.9-21 causes kernel panic
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Stephen Tweedie
QA Contact: Brian Brock
: 59971 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-16 23:35 UTC by Bishop Clark
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-19 21:06:30 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bishop Clark 2002-02-16 23:35:43 UTC
Description of Problem:
while copying large (avi) files from one mounted filesystem to another, the
kernel panics.  The offending comand is:

       cp /tmp/tv-200202101700-59m-CH46.avi /home/bishop/vcr-out

s/cp/mv/ for the same result (since mv over mounted FSes is really cp&&rm).

The FS is not full:

Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda1              9273984   2693332   6109548  31% /
/dev/hdb1             20161172  17430536   1706496  92% /home

[root@ducky root]# cat /etc/mtab | grep relevant-bits
/dev/hda1 / ext3 rw 0 0
/dev/hdb1 /home ext2 rw 0 0

Version-Release number of selected component (if applicable):

How Reproducible:

Twice today, but only with the large file.  a 200Mb avi was successfully copied.

Steps to Reproduce:
1. take one updated RH72 system
2. mount one FS e2, one e3.
3. cp larger file from e3 to e2 fs.

Actual Results:
Kernel Panic.

Expected Results:
cp succeeds.

Additional Information:

System is an athlon 900Mhz on an ASUS a7v133 mobo, with 512M RAM and 256M swap.
 it's got a 10G ide drive hooked to its 33Mbit IDE, and a 60G UDMA100 drive
hooked to its 100Mbit iface.

This system is 3012 miles away from me, and is a logistical nightmare so I can't
reboot it often (requires a call-out).

The tech called out this morning has taken some rough screen shots (literally,
because she had her new cam in the car).  I'll attach them.

Comment 1 Bill Nottingham 2002-02-19 04:37:36 UTC
*** Bug 59971 has been marked as a duplicate of this bug. ***

Comment 2 Bishop Clark 2002-02-19 10:19:50 UTC
Sorry for the Double-Submit, guys, and please hold off on researching this for
the moment.  My onsite guy reminded me that he's just upgraded the RAM in the
box, and one of the sticks may turn out to be bogus.  

I'll have a re-test within 24 hours or so.

Comment 3 Bishop Clark 2002-02-19 21:06:26 UTC
I have confirmed:  The problem with the 3 -> e2 was coincidental with a HW
upgrade, and the HW introduced appears to have caused the problem.  An identical
test (same file, same operation, maybe different load and time-of-day) was
successful.  I'll replace the bad RAM, get some new RAM in there, and, if I can
reproduce with definitely known-good RAM, I'll reopen.

Sorry to bother you, and I'm glad it was a false alarm.

Comment 4 Stephen Tweedie 2002-02-19 21:29:25 UTC
Thanks for the update.

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