From owner-freebsd-sparc64@FreeBSD.ORG Wed Dec 19 23:03:36 2012 Return-Path: Delivered-To: sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F1A244E; Wed, 19 Dec 2012 23:03:36 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 97ABF8FC16; Wed, 19 Dec 2012 23:03:29 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qBJN3Smn050166; Wed, 19 Dec 2012 16:03:28 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qBJN3NsO065767; Wed, 19 Dec 2012 16:03:23 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Call for testing and review, busdma changes From: Ian Lepore To: Jeff Roberson In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Dec 2012 16:03:23 -0700 Message-ID: <1355958203.1198.235.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 20 Dec 2012 00:09:17 +0000 Cc: powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 23:03:36 -0000 On Sat, 2012-12-08 at 08:51 -1000, Jeff Roberson wrote: > Hello, > > http://people.freebsd.org/~jeff/physbio.diff > > I have a relative large patch that reforms the busdma API so that new > types may be added without modifying every architecture's > busdma_machdep.c. It does this by unifying the bus_dmamap_load_buffer() > routines so that they may be called from MI code. The MD busdma is then > given a chance to do any final processing in the complete() callback. > This patch also contains cam changes to unify the bus_dmamap_load* > handling in cam drivers. > > The arm and mips implementations saw the largest changes since they have > to track virtual addresses for sync(). Previously this was done in a type > specific way. Now it is done in a generic way by recording the list of > virtuals in the map. > > I have verified that this patch passes make universe which includes > several kernel builds from each architecture. I suspect that if I broke > anything your machine simply won't boot or will throw I/O errors. There > is little subtlety, it is mostly refactoring. > > The next step is to allow for dma loading of physical addresses. This > will permit unmapped I/O. Which is a significant performance optimization > targeted for 10.0. > > Many thanks for your assistance. Any review feedback is also appreciated. > > Jeff More test results... Today I updated to r244435 and then applied your patches (and my little fix, but not my big set of busdma changes) over that, and built everything fresh for my DreamPlug. I plugged an SSD drive into the eSata port for some testing and right away noticed extreme slowness; 'camcontrol identify' shows the drive running in PIO mode with the patches, but it's fine without them (output below). I'm no ata or cam wizard, but I can easily toggle back and forth between kernels with/without the patches; let me know if I can do anything to generate useful info to track this down. -- Ian -------------------------------- With unpatched -current @ r244435 ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: ATA-9 SATA 2.x device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-9 SATA 2.x device model M4-CT128M4SSD2 firmware revision 000F serial number 0000000012290910F745 WWN 500a07510910f745 cylinders 16383 heads 16 sectors/track 63 sector size logical 512, physical 512, offset 0 LBA supported 250069680 sectors LBA48 supported 250069680 sectors PIO supported PIO4 DMA supported WDMA2 UDMA5 media RPM non-rotating Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART yes yes microcode download yes yes security yes no power management yes yes advanced power management yes yes 254/0xFE automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify yes no 0/0x0 unload yes yes free-fall no no data set management (TRIM) yes -------------------------------- With physbio patches applied to r244435... ada0 at mvsch0 bus 0 scbus0 target 0 lun 0 ada0: ATA-9 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 122104MB (250069680 512 byte sectors: 16H 63S/T 16383C) root@dpcur:/root # camcontrol identify ada0 pass0: < > ATA-0 device pass0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) protocol ATA/ATAPI-0 device model firmware revision serial number cylinders 0 heads 0 sectors/track 0 sector size logical 512, physical 512, offset 0 LBA not supported LBA48 not supported PIO supported PIO0 w/o IORDY DMA not supported Feature Support Enabled Value Vendor read ahead no no write cache no no flush cache no no overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) no SMART no no microcode download no no security no no power management no no advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload no no free-fall no no data set management (TRIM) no -- Ian