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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux