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):
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.
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.
*** Bug 59971 has been marked as a duplicate of this bug. ***
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.
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.
Thanks for the update.