Andrew de Quincey wrote:
On Thursday 08 December 2005 01:59, Andrew de Quincey wrote:
eject -s sends the following SCSI packet command to the sbp/ipod device:
1b 00 00 00 02 00 with a direction of DMA_NONE
eject -r results in the same via the CDROMEJECT translator in
scsi_cmd_ioctl(), but with a direction of DMA_TO_DEVICE. Thats what crashes
it - looks like its trying to set up a DMA transfer for 0 bytes or
something. I just added a really horrible hack to the start of
sbp2_send_command() to check, as follows:
if (*cmd == 0x1b) {
SCpnt->sc_data_direction = 3;
}
Now, eject -r works perfectly. Though thats obviously not a good way to fix
it :)
That was a long time ago when sbp2 had to take care of data direction. I
think we don't want to go back there. :-)
Possible "proper" patch attached - no idea if its a good way to do this.
Basically if it gets a command with a scsi_request_bufflen of zero bytes, it
forces dma_dir to DMA_NONE.
The ipod works perfectly with this now.
...
[in sbp2_create_command_orb]
+ /* check for duff DMA transfer direction with a zero length buffer */
+ if (scsi_request_bufflen == 0)
+ dma_dir = DMA_NONE;
What if you replace WRITE by READ in
drivers/scsi/scsi_ioctl.c::scsi_cmd_ioctl()::case CDROMEJECT ?
And BTW, can/should this latter case block be converted to use
scsi_execute() or scsi_execute_req()?
--
Stefan Richter
-=====-=-=-= ==-- -=---
http://arcgraph.de/sr/
-
: 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
