Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Dec 2012 16:03:23 -0700
From:      Ian Lepore <freebsd@damnhippie.dyndns.org>
To:        Jeff Roberson <jroberson@jroberson.net>
Cc:        powerpc@freebsd.org, marcel@freebsd.org, mips@freebsd.org, John Baldwin <jhb@freebsd.org>, mav@freebsd.org, scottl@freebsd.org, attilio@freebsd.org, kib@freebsd.org, sparc64@freebsd.org, arm@freebsd.org
Subject:   Re: Call for testing and review, busdma changes
Message-ID:  <1355958203.1198.235.camel@revolution.hippie.lan>
In-Reply-To: <alpine.BSF.2.00.1212080841370.4081@desktop>
References:  <alpine.BSF.2.00.1212080841370.4081@desktop>

next in thread | previous in thread | raw e-mail | index | archive | help
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: <M4-CT128M4SSD2 000F> 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: <M4-CT128M4SSD2 000F> 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: <M4-CT128M4SSD2 000F> 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





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1355958203.1198.235.camel>