2008/6/3 Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>:
[...]
>
> What do you think of a patch like this?
>
> Index: usb-2.6/include/linux/blkdev.h
> ===================================================================
> --- usb-2.6.orig/include/linux/blkdev.h
> +++ usb-2.6/include/linux/blkdev.h
> @@ -221,6 +221,7 @@ struct request {
>
> unsigned int data_len;
> unsigned int extra_len; /* length of alignment and padding */
> + unsigned int min_data_len;
> unsigned int sense_len;
> void *data;
> void *sense;
> Index: usb-2.6/drivers/scsi/scsi_lib.c
> ===================================================================
> --- usb-2.6.orig/drivers/scsi/scsi_lib.c
> +++ usb-2.6/drivers/scsi/scsi_lib.c
> @@ -1125,6 +1125,7 @@ int scsi_setup_blk_pc_cmnd(struct scsi_d
> ret = scsi_init_io(cmd, GFP_ATOMIC);
> if (unlikely(ret))
> return ret;
> + cmd->underflow = req->min_data_len;
> } else {
> BUG_ON(req->data_len);
> BUG_ON(req->data);
>
> Combined with an extra minimum-data-length argument to scsi_execute()
> and scsi_execute_req(), this ought to solve the problem.
>
> (To refresh your memory: The problem is that a weird device responds to
> MODE SENSE with Residue equal to the data length -- so none of the
> returned data is valid -- and Okay status.)
>
> Alan Stern
>
> P.S.: Maybe a safer approach would be to add a new flag bit in struct
> request. Normally the flag would be clear, indicating that for
> BLOCK_PC requests, scmd->underflow should be set to 0. But when the
> flag is set, scmd->underflow would be set to req->data_len.
>
>
It does'n help. I still have "write protect is on" message. Also I see
"usb-storage: queuecommand called" message.
Log (2.6.26-rc2):
http://www.unixy.pl/maciek/download/kernel/2.6.26-rc2/20080613/syslog
--
Maciej Rutecki
http://www.maciek.unixy.pl
--
To unsubscribe from this list: 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
