Call for testing and review, busdma changes
Ian Lepore
freebsd at damnhippie.dyndns.org
Wed Dec 19 23:03:36 UTC 2012
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 at 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 at 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
More information about the freebsd-sparc64
mailing list