saved and restore result for timed out commands
A message that is not in the archive (sent off-list or not yet received): [email protected]
[Now on-list]
Quoted 13 lines · Patrick Mansfield
Quoted 3 lines · Alan Stern
As for lost Unit Attentions, what about events like media changes? I can easily imagine those sorts of notifications getting swallowed by the error handler.
Yeh ... that sounds bad.
And the
scsi_eh_tur()losing the media change looks broken! Seedrivers/scsi/scsi_lib.c, search for "->changed". I am thinking there are other similar cases, probably search and compare handling of other UNIT ATTENTIONs and checking of sense result.
Quoted 5 lines
scsi_eh_tur()should do the same things asscsi_test_unit_ready(). We need some helper function(s).And we have to handle sd and sg both getting the media change, again might be true for other UNIT ATTENTIONs.
Actually it looks like media change is the worst case. The use_10_for_rw stuff in scsi_io_completion() and other various retry pathways shouldn't be invoked for sg.
Quoted 7 lines
We might be able to pass back the data to sg by conditionally (just UNIT ATTENTION, or all cases???) not clearing the sense data (as per current code) and marking the sense data as present, prehaps just "
scmd->result&=CHECK_CONDITION".This seems a bit tricky. I have not thought this through, and don't have any patches :-)
I don't have any patches either, and it's not clear that simply passing the sense data through would work. Other status bits would lead the client to believe that the original command aborted without returning Check Condition status (although the error handler's TUR did get CC), so the client might not bother to look at the sense data.
Quoted 4 lines
So we should verify all command completions in
scsi_error.care OK, and add a helper function(s) called for all scsi IO completions to check UNIT ATTENTION etc. And then maybe keep sense data from the TUR for use with the timed out command.
Maybe. It might work if you can fool the client into thinking the timed-out command failed with the appropriate status. Making up fake return values like this doesn't seem to be a good idea... but perhaps for Unit Attention it's acceptable.
Come to think of it, the error handler doesn't stop when it sees Unit Attention, does it? It sends another TUR, looking for valid status. (As a side issue, this behavior needs to be fixed as well. TUR will always fail when no medium is present; the error handler should accept such a failure and not try to do any further error recovery.)
Alan Stern