The aic7xxx driver is doing it because it's getting a CHECK_CONDITION return
from the CD device. Since CHECK_CONDITION is the proper response in the case
that parity errors cause an aborted transfer to the device, we have to accept
it as a possible indicator that there might be transfer problems, so we then
perform domain validation. Please note that domain validation in the aic7xxx
driver uses the same code as SDTR/WDTR negotiations, so I seriously doubt it
locked up your system, it just happened to be the last message displayed.
Also note that most devices only rarely return CHECK_CONDITION responses, but
CDs do so in order to signal a disk change, so yes, you will get a domain
validation with each CD change. You'll also get them with each reset, and
several other conditions, but in general, they should be rare.
I could actually poke around in the sense data returned after a check
condition and see if we actually need to perform a domain validation, but that
would just be another case of the low level driver doing something it
shouldn't be doing at all (parsing generic error returns in sense data and
deciding what to do next, this stuff is all generic SCSI protocol stuff and
shouldn't be in the low level driver IMO).
--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/