From owner-freebsd-current@FreeBSD.ORG Sat Sep 5 19:33:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 955C6106566B; Sat, 5 Sep 2009 19:33:18 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id 4247C8FC12; Sat, 5 Sep 2009 19:33:18 +0000 (UTC) Received: from [IPv6:::1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n85JVvGg011353; Sat, 5 Sep 2009 13:31:57 -0600 (MDT) (envelope-from scottl@samsco.org) Mime-Version: 1.0 (Apple Message framework v1075.2) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes From: Scott Long In-Reply-To: <4AA1FA41.1030804@FreeBSD.org> Date: Sat, 5 Sep 2009 13:31:56 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <4AA03346.5010608@FreeBSD.org> <200909032210.n83MA67F059073@apollo.backplane.com> <200909042314.n84NEMAS072077@apollo.backplane.com> <4AA1FA41.1030804@FreeBSD.org> To: Alexander Motin X-Mailer: Apple Mail (2.1075.2) X-Spam-Status: No, score=-2.6 required=3.8 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Ryan Rogers , current@freebsd.org Subject: Re: non aligned DMA transfer attempted X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2009 19:33:18 -0000 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