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). > > > 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. -- Kai - : 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
