On 11/9/06, Tejun Heo <[email protected]> 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-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
