Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157904 - Content of large files change on every read
Summary: Content of large files change on every read
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-16 22:11 UTC by Richard Körber
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-05-17 17:46:51 UTC

Attachments (Terms of Use)

Description Richard Körber 2005-05-16 22:11:41 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de-AT; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

Description of problem:
I am working with rather large files (about 3 GB). If I do a "md5sum -b $largefile", I will always get different sums, but the file itself is unchanged!

The same happens if I copy a large file, and then make a diff. The file should be identical, but diff says it isn't.

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

How reproducible:

Steps to Reproduce:
1. Create a large file (about 3 GB)
2. Repeatedly do a "md5sum -b $largefile" on that file

Actual Results:  Most often, different md5 sums are returned even though the file is unchanged.

Expected Results:  Always getting the same md5 sum because the file did not change.

Additional info:

My hardware: AMD Athlon64 3000+, Asus K8V SE Deluxe mainboard, 1x PATA hard disk, 2x SATA hard disks (Software RAID-0). Latest Asus BIOS is installed. The system is not overclocked. The RAM has been successfully tested using memtest86 for more than 10 hours. The partitions are EXT3 formatted.

First I suspected the on-board VIA SATA RAID controller, so I connected the hard disks to the on-board Promise SATA RAID controller. The issue remained reproducable though.

I copied the large file to a PATA hard disk. Even there, md5sum always gave different sums.

I went back to the original FC3 kernel (2.6.9-1.667) but it didn't help either. The bug was also reproducable in an "init 1" environment, though then I got a few consecutively correct md5sums.

When booting from the FC3 rescue CD, everything seems to be fine.

Comment 1 Richard Körber 2005-05-17 17:46:51 UTC
Actually, it turned out to be a mainboard issue!

If there is double sided RAM in slot 0 and 1, and Cool&Quiet is enabled, the
data read from IDE or SATA will be corrupted.

I have moved the second RAM bar from slot 1 to slot 2, and now everything is
working fine again.

Resolved to WorksForMe, since this is not a Linux issue. I'm sorry!

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