http://bugzilla.novell.com/show_bug.cgi?id=556397
http://bugzilla.novell.com/show_bug.cgi?id=556397#c14
Tejun Heo changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
Info Provider| |badshah400@gmail.com
--- Comment #14 from Tejun Heo 2009-11-27 03:32:44 UTC ---
Okay, UDMA CRC error got incremented. I think the following is what's going
on.
* Transmission error occurs. Host doesn't record transmission problems in
SError so probably the direction which has problem is from host to device.
This increments the UDMA_CRC error count.
* FIS transmission should be retried or the device should try to renegotiate
the connection if something doesn't work but the command execution simply hangs
and the controller doesn't notice that there's a link problem. This isn't
supposed to happen but unfortunately does happen on certain configurations,
especially with older controllers and devices.
* Command eventually times out and EH resets the link. The drive for some
reason aborts SET_MAX issued during device recovery (it's okay). The abort is
recorded in the error log.
So, the root cause is transmission glitch. Transmission glitches aren't too
uncommon in SATA and, in better working configurations, things like this are
immediately reported to the driver and recovery happens quickly but it
unfortunately leads to timeouts on your configuration.
Please try "libata.force=1.5Gbps" and then "libata.force=noncq" and see whether
the problem goes away.
Thanks.
--
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.