Thread: Changes to the FireWire kernel drivers in Linux 3.4
Brought to you by:
aeb,
bencollins
From: Stefan R. <st...@s5...> - 2012-05-24 20:44:58
|
Hi all, Linux kernel 3.4 has been released last Sunday. These are the IEEE 1394 related changes: <linux/firewire-cdev.h> API: - Added FW_CDEV_IOC_FLUSH_ISO ioctl which lets an application get any currently completed isochronous packets reported. A corresponding libraw1394 update to use this ioctl in raw1394_iso_recv_flush() has been committed to libraw1394.git too and will show up in the next libraw1394 release. firewire-core, -net, -ohci, -sbp2: - All messages to the kernel log are now consistently prefixed by driver name and device name or number. firewire-ohci: - Fix premature completion of multichannel isochronous reception DMA. Also fixed in kernel 3.3.1, 3.2.14, 3.0.27. - Fix missing completion notification in isochronous I/O in case of big intervals between interrupt packets or with big packet headers. firewire-sbp2: - If the target's unit directory contains a Unit_Unique_ID entry, use it instead of the node unique ID as the target's GUID in the ieee1394_id sysfs attribute and consequently in udev's /dev/disk/by-id symbolic links. - Do not try to log into targets on the local node. I/O to such targets is not yet implemented, and local targets are probably meant to be accessed by remote initiators anyway. - Fix handling of SCSI sense data (deferred errors, Valid, Filemark, EOM, ILI). -- Stefan Richter -=====-===-- -=-= ==--- http://arcgraph.de/sr/ |
From: Stefan R. <st...@s5...> - 2012-06-02 09:55:21
|
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/ |