Re: 2.6.19-rc3 system freezes when ripping with cdparanoia at ioctl(SG_IO)
From: Jeff Garzik
Date: Thu Nov 09 2006 - 09:14:47 EST
Tejun Heo wrote:
This works for most PATA ATAPI devices. Most devices detect reversed
transfer and terminate the command promptly. But this doesn't seem to
be true for SATA device. Many just hang and time out commands with the
wrong transfer direction. If you consider that most early SATA ATAPI
devices are actually PATA + bridge, this is sorta inevitable. The
PATA-SATA bridge cannot issue D2H FIS to abort the command by itself.
It's just mirroring the status of PATA side and PATA side doesn't know
SATA protocol mismatch has occurred.
So, IDENTIFY w/ write-DMA protocol times out after quite some seconds.
This is where things go worse from bad. SATA controllers which have
shadow TF registers don't handle timeout conditions very well,
especially when they're waiting for data transfer. They basically hold
the PCI bus and hang till the transfer completes (which never happens).
That's where the hard lock up comes from.
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. Kernel
and libata can't do much about it. So, please find other way to detect
interface.
Mapping 'bidirectional' is a bit difficult. It might be reasonable to
interpret that as "userspace doesn't know" at lower layers, and then
fill in a data transfer direction based on ATA command opcode.
Given that there are stupid apps/libs out there in the field with this
behavior, even if the apps are fixed I think we are stuck with the
stupidities. At the very least, we could abort commands that transfer
data in the opposite direction from indicated, based on a command opcode
table.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/