When an internal command fails, it should be failed directly without invoking
EH. In the original implemetation, this was accomplished by letting internal
command bypass failure handling in ata_qc_complete(). However, later changes
added post-successful-completion handling to that code path and the success
path is no longer adequate as internal command failure path. One of the
visible problems is that internal command failure due to timeout or other
freeze conditions would spuriously trigger WARN_ON_ONCE() in the success path.
This patch updates failure path such that internal command failure handling is
contained there.
[/quote]
In Karmic there is a new stable kernel 2.6.31-17.54 /bugs.launchpad .net/ubuntu/ +source/ linux/+ bug/480144> that refer to kernel. org/pub/ linux/kernel/ v2.6/ChangeLog- 2.6.31. 6> is mentioned this cd48c3070dcf6a7 6c69e540cc with this description:
<https:/
upstream kernel 2.6.31.6; in the changelog
<http://
commit 9982364654c186a
[quote] cd48c3070dcf6a7 6c69e540cc
commit 9982364654c186a
Author: Tejun Heo <email address hidden>
Date: Fri Oct 16 13:00:51 2009 +0900
libata: fix internal command failure handling
commit f4b31db92d163df 8a639f5a8c8633b deb6e8432d upstream.
When an internal command fails, it should be failed directly without invoking -completion handling to that code path and the success
EH. In the original implemetation, this was accomplished by letting internal
command bypass failure handling in ata_qc_complete(). However, later changes
added post-successful
path is no longer adequate as internal command failure path. One of the
visible problems is that internal command failure due to timeout or other
freeze conditions would spuriously trigger WARN_ON_ONCE() in the success path.
This patch updates failure path such that internal command failure handling is
contained there.
[/quote]
Could be related to this bug?