Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Sep 2009 13:31:56 -0600
From:      Scott Long <scottl@samsco.org>
To:        Alexander Motin <mav@freebsd.org>
Cc:        Ryan Rogers <webmaster@doghouserepair.com>, current@freebsd.org
Subject:   Re: non aligned DMA transfer attempted
Message-ID:  <E26273AF-E19A-404E-9EA0-BAACE448CA76@samsco.org>
In-Reply-To: <4AA1FA41.1030804@FreeBSD.org>
References:  <h7p0a3$k3m$1@FreeBSD.cs.nctu.edu.tw> <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <A1B223C6-7291-4F86-B8AC-4EB5EF12F409@samsco.org> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Sep 4, 2009, at 11:42 PM, Alexander Motin wrote:

> Matthew Dillon wrote:
>> :>    The physio code directly maps the userland buffer via vmapbuf 
>> () and
>> :>    supplies it as a BIO to the device.  The ATA driver does not  
>> use
>> :>    BUSDMA (and never has)... it assumes BIOs are minimally  
>> aligned.
>> :
>> :Wrong.
>>
>>    By the way Scott, do you honestly believe that idiotic one-line
>>    answers just as a means to try to screw over my postings are
>>    appropriate for someone of your standing in the FreeBSD community?
>
> His answer is short, but correct, because all ATA drivers do use  
> BUSDMA.
> And as I have already said, BUSDMA manages proper alignment there, by
> implementing bounce buffers.
>

Matt typically doesn't listen to what others have to say in  
disagreement anyways, so I didn't see a whole lot of value in wasting  
my time with long answers with him.  However, others have asked me for  
more thorough explanations in private, and I'll attempt to provide  
them here:

1.  Alexander is correct, ata has used busdma for many years.  This  
may be different in DillonBSD, but we're talking about FreeBSD here.  
As such, it was hard to engage further in the conversation given the  
basic disconnect in understanding.

2. The CAM passthrough doesn't care a whole lot about alignment  
because alignment is the concern of the SIMs in conjunction with  
busdma, not the periph and transport layers of CAM.  There is one  
exception to this, which is the physaddr data transfer mode in CAM.   
busdma doesn't understand this mode.  However, nothing in FreeBSD uses  
this mode; it's a legacy remnant from many years ago.  Most SIMs  
choose to ignore this interface anyways (recall that SIMs are  
responsible for alignment, not the rest of CAM), so it's not an issue  
except on a small selection of hardware, using custom software (i.e.  
close source large appliance software not found in the ports tree)  
that deliberately selects the interface.

3. Adding alignment bouncing logic to every driver in the tree is  
silly when it already exists in busdma.  Granted, I didn't implement  
this feature very well originally, so there were bugs that made it  
less useful.  However, I think that most of those bugs have been  
fixed, and any that remain can and should be fixed.

4. The vast majority of the storage drivers in the tree use busdma and  
use it correctly for deferred loads.  This wasn't the case many years  
ago, and may not be the case in DillonBSD, but again, we're talking  
about FreeBSD here.  There might be a few drivers left that don't  
fully conform to the API (ATA was a big one, which is one of the many  
reasons that the new generation of SATA drivers was written), and I'm  
happy to help others fix any drivers that remain and are causing  
problems.

Again, I'm happy to discuss this further.  I apologize for the terse  
answers to the community, and I hope this has cleared up the problem.

Scott




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E26273AF-E19A-404E-9EA0-BAACE448CA76>