Bug 114279 - reiserfs oops 74min into copying 50G
Summary: reiserfs oops 74min into copying 50G
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2004-01-26 09:52 UTC by Need Real Name
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-19 15:32:45 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 Need Real Name 2004-01-26 09:52:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040120

Description of problem:
I was copying a tree from a reiserfs volume on a GDTH hardware RAID0
set to a software RAID0 ATA pair.


kernel BUG at buffer.c:604!
invalid operand: 0000
ide-cd cdrom via82cxxx_audio ac97_codec uart401 sound soundcore nfs
lockd sunrpc parport_pc lp parport autofs e100 floppy sg raid0 keybdev
mousedev hid input
CPU:    0
EIP:    0060:[<c014529e>]    Not tainted
EFLAGS: 00010286
EIP is at __insert_into_lru_list [kernel] 0x1e (2.4.22-1.2149.nptl)
eax: 8bbe968e   ebx: 00000002   ecx: f0220080   edx: c03d604c
esi: f0220080   edi: f0220080   ebp: 00001000   esp: e6edbe64
ds: 0068   es: 0068   ss: 0068
Process cp (pid: 16878, stackpage=e6edb000)
Stack: 00000002 c0145c8b f0220080 00000002 f0220080 00001000 c0146882
       00000000 00014000 00000000 c1f22e20 efd51980 c014707f efd51980
       00000000 00001000 e6edbee8 00014000 00000000 efd51980 f886538d
Call Trace:   [<c0145c8b>] __refile_buffer [kernel] 0x5b (0xe6edbe68)
[<c0146882>] __block_commit_write [kernel] 0xb2 (0xe6edbe7c)
[<c014707f>] generic_commit_write [kernel] 0x3f (0xe6edbe98)
[<f886538d>] reiserfs_commit_write [reiserfs] 0x13d (0xe6edbebc)
[<f8887090>] .LC30 [reiserfs] 0x2c (0xe6edbee8)
[<c01366f3>] do_generic_file_write [kernel] 0x283 (0xe6edbf18)
[<c0136c86>] generic_file_write [kernel] 0x136 (0xe6edbf68)
[<c0143a13>] sys_write [kernel] 0xa3 (0xe6edbf94)
[<c014b9a9>] sys_fstat64 [kernel] 0x49 (0xe6edbfa8)
[<c0109747>] system_call [kernel] 0x33 (0xe6edbfc0)
Code: 0f 0b 5c 02 17 0a 28 c0 8b 02 85 c0 75 07 89 0a 89 49 24 8b

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

How reproducible:
Didn't try

Steps to Reproduce:
1. cp -a /vol1/* /vol2/


Actual Results:  34G copied

Expected Results:  50G copied

Additional info:

This machine was a dual PIII till it caught fire. We replaced mobo,
RAM, CPU (to an Athlon but I wasn't allowed to install the Athlon
kernel..), video card, RAID card, PSU and one hard drive (which is
where the fire was)..

I believe the RAM is OK (we regularly run memtest86) but will find
time to run it again..

Comment 1 Need Real Name 2004-01-28 00:05:07 UTC
Preliminary memtest (default tests) ran fine for 2 passes;
tried the cp again and it worked fine;
now running memtest (all tests..)--will follow up if it fails!

Should we put this down to gamma rays/the dodgy music coming out of
the machine next door?

Comment 2 Need Real Name 2004-01-29 14:20:19 UTC
memtest (all tests) was fine (for one pass).

It's now been running 2.6.1-1.57 happily for 24h.

Comment 3 Dave Jones 2004-06-19 15:32:45 UTC
the vm updates circa 2163 should have also fixed this.

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