Messages in this thread | | | Date | Thu, 09 Nov 2006 09:14:16 -0500 | From | Jeff Garzik <> | Subject | Re: 2.6.19-rc3 system freezes when ripping with cdparanoia at ioctl(SG_IO) |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |