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): 2.6.11-1.14_FC3 How reproducible: Always 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.
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!