Kai Makisara wrote:
On Sat, 17 Sep 2005, Mike Christie wrote:
On Sat, 2005-09-17 at 10:55 -0500, Mike Christie wrote:
Mike Christie wrote:
Kai Makisara wrote:
I think I may have found the problem: scsi_execute_async does not use
the parameter retries (the same applies to scsi_execute btw). This
leads to retrying the reads at filemark and this is not correct. I
added the hack below to scsi_execute_async and after this the simple
tests succeed.
ah ok. I think when we prep the command we need to copy the retries from
the command. So in st.c st_init_command callout we need to copy that
value (we are just copying the timeout today).
oh I guess there is not retries count on the request like there is for
timeout :)
But it looks like retried is always 0. I guess st's init_command could
just do
SCpnt->allowed = 0;
This does not work because st_init_command() is not called (called only
with SG_IO ioctls).
The scsi_execute* functions actually send all commands down as
REQ_BLOCK_PC commands like SG_IO so we are always going through the
st_init_commad().
Or how about this patch it was made against my updated patches here:
http://www.cs.wisc.edu/~michaelc/block/use-sg/v6/
It is the 06-add-retry-field.patch patch. All it does it add a retries
count onto the request so it can be passed around like the timeout
value.
[patch cut]
This looks like a clean approach because it allows passing the retries
parameter of scsi_execute_* to the request processing.
I tested this but it does not quite work: there are now two retries in the
same test that previously gave six retries. Unfortunately I don't just now
have time to study the problem further.
ok I will try to look into it.
-
: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
