On 11/9/06, Tejun Heo <htejun@xxxxxxxxx> wrote:
drivers/scsi/sg.c interprets SG_DXFER_TO_FROM_DEV as read while block/scsi_ioctl.c interprets it as write. I guess this is historic thing (scsi/sg.c updated but block/scsi_ioctl.c is forgotten).
Not historic; Jens accidentally implemented it backwards. No one noticed for a long time. I submitted a patch for this a few months ago.
This works for most PATA ATAPI devices. Most devices detect reversed transfer and terminate the command promptly.
No. The rejection is *not* in hardware; it is in software. block/scsi_ioctl.c, at least up to 2.6.16, rejected the TO_FROM_DEVICE request when verifying the command for sanity after setting the transfer direction incorrectly. As far as the *device* can see, TO_FROM_DEVICE and FROM_DEVICE are identical. The difference only applies inside the kernel mid-level driver where TO_FROM_DEVICE prefills the transfer buffer as a way of working around having no other detection path for short DMA transfers.
But this doesn't seem to be true for SATA device.
Then the driver is broken and needs to be fixed. And I'll need to find a workaround for broken kernels that doesn't cause a boom.
Jens, I think we need to match block sg's behavior to SCSI's. Monty, the timeout and hard lock up are due to hardware restrictions.
No., the kernel setting the transfer direction incorrectly. I don't set the transfer direction, the kernel does. In your case, I pass in "SGIO_TO_FROM_DEVICE" and the kernel says "that's a write". The kernel is wrong. It is a read. The original description of what TO_FROM_DEVICE is for is explicit on this point.
Kernel and libata can't do much about it. So, please find other way to detect interface.
Just to be clear-- it is the kernel at fault here, and the kernel can do something about it-- but only if the kernel gets fixed. Also to be clear, given this brokenness, yes I need to find another way. Dammit, dammit, dammit, one step forward, two steps back :-( Monty - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
