Most recent kernel where this bug did not occur: 2.6.10 Distribution: slack Hardware Environment: ia32 Software Environment: Problem Description: Heavy disk I/O causes MPT driver to stall and attempt recovery with this error message: un 17 17:30:45 s21 kernel: sd 0:0:0:0: SCSI error: return code = 0x8000002 Jun 17 17:30:45 s21 kernel: sda: Current: sense key: Aborted Command Jun 17 17:30:45 s21 kernel: Additional sense: Information unit CRC error detected This problem increases with processor speeds (i.e. disabling hyper-threading causes a reduction in the number of errors reported). If enough errors are reported, the file system is mounted read-only. In addition to performance issues, this is quite a nasty. Discovered on an IBM x225 with 2x3gb Xeons, 2.5GB ram and 2 U320 SCSI disks. Chipset 35c1030 ****** This bug shows a regression in the code for the MPT driver that disables the IU at speeds >= 160MB as documented by LSI logic. It is documented that the IU is unreliable at these speeds. The system I'm using is u320, thus the errors are reported even more frequently. This is documented at: http://www.lsilogic.com/files/support/ssp/fusionmpt/Linux/LinuxMPT_20628.txt Steps to reproduce: cp or mv a large file
Your end device is having CRC errors. My guess is your hard drive is probably on its last leg. Try replacing it, that is my recommendation. That release note you provide a link to is for 2.4 kernel, and a 2.06.08 driver that was released back in November 2004, says to turn off IU, which is packatized commands for U160 devices or slower. Not for U320 devices. U320 devices can run with IU enabled. I guess you found that on our website. Thats not a bug, and shouldn't impact your U320 devices. The 2.4 kernel driver is much different than you will find in the 2.6 kernel. By the way, in 2.6.17 kernel, the driver is using spi transport layer, and generic domain validation. YOu can fine turn your negotiaiton in the /sysfs. You can contact James Bottomley on that. Eric Moore
Any updates on this problem? Thanks.
Please reopen this bug if it's still present with kernel 2.6.22.