Silent data corruption with kernel 3.4 and FireWire disks

About a week ago I noticed silent data corruptions of files on FireWire
disks: Mount disk, read lots of data and e.g. compute their md5sum, unmount disk, mount disk again, read and md5sum the same files again -> MD5s may differ.

Defects in files that were written in May hint that not only reading from but also writing to FireWire disks resulted in corrupt data. This was silent corruption without any error messages from the PCI, firewire, SCSI, block, or filesystem subsystems.

Affected:
- kernel 3.4
- kernel 3.4-rc5
Not affected:
- kernel 3.3.1 (which I have been running now for the last 6 days)

I used these three kernels with the same patchlevel of FireWire drivers, namely circa those which are about to be released in 3.5-rc1. FireWire disks with different 1394-to-SATA or -IDE bridge chips are affected. I noticed the problem at first on an Agere FW643e PCIe 1394 controller which sits behind a PLX PEX 8505 PCIe switch.

MPEG2TS video reception through the same 1394 controller and PCIe switch did never show a noticable sign of corruption.

I did not have time yet to systematically test
- whether all of my FireWire controllers are affected,
- whether SATA or USB disks are affected (SATA probably not, USB not used yet),
- whether my secondary Linux PC is affected.

Kernel 3.4 and 3.4-rc5 exhibited another (seemingly harmless but suspicious) issue on my primary PC: frequent transmit queue time-outs of an RTL8111/8168B Ethernet interface,
http://www.spinics.net/lists/netdev/msg197032.html

Being busy at work lately and not having Linux available at work, I will be slow to look further into it. With enough spare time, it should be possible to identify the regression by bisection between kernel 3.3 and 3.4-rc but I have no estimate when I will be able to spend that time.

Stefan Richter
-=====-===-- -==- ---=-
http://arcgraph.de/sr/