Re: "Fix ATAPI transfer lengths" causes CD writing regression

From: Tejun Heo
Date: Thu Nov 01 2007 - 03:25:24 EST


Tejun Heo wrote:
> Hello, Jeff.
>
> Jeff Garzik wrote:
>> That's easy for the PIO case. But CD writing is normally DMA, which
>> means you will get a DMA engine exception if the device wants to give
>> you more data than the scatter/gather entries permit.
>
> For sense data and mode pages, the standard-sanctioned way to know the
> transfer size is to issue command with short buffer size just enough to
> contain the fixed size header part, determine actual transfer size from
> it and issue the command again with the correct buffer size. This
> doesn't happen for READ/WRITE commands. Transfer sizes are
> pre-determined for those commands and WRITE's to optical devices often
> can't be retried w/o side effect.
>
> I've just went through the ATA spec and this basically means we can't
> use DMA for these variable-transfer-length commands. Some DMA engines
> have "throw away what's left over bit" in its command structure or SG
> entry but not all do and none of drivers we currently has such feature
> enabled.
>
> Hmmm.... reading ide-cd.c::cdrom_pc_intr(). OIC, ide-cd is dealing with
> this problem by draining PIO after BMDMA engine is done. This is
> possible for BMDMA engines as they simply step out when the SG entries
> are exhausted; then, the interrupt handler kicks in and drains the
> left-over using PIO. This just isn't possible with more modern DMA engines.
>
> This really makes me think libata should do these commands via PIO
> unless we're gonna enable leftover draining for each DMA engine
> implementation or blacklist the ones which can't drain individually.
> Then again, nobody really knows how well those features would work as
> probably none has actually used them.

Eeek, please ignore this. I somehow completely forgot about Allocation
Length fields in CDBs.

Thanks.

--
tejun
-
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/