illumos gate

On a MCP61 system which has its rpool on such a controller, I added those PCI IDs with update_drv and rebooted. Basic I/O seems to work, but I could not test hotplugging.

prtconf -Dv excerpt:

pci1043,8234, instance #0 (driver name: nv_sata)
name='compatible' type=string items=7
    value='pci10de,3f6.1043.8234.a2' + 'pci10de,3f6.1043.8234' + 'pci1043,8234' + 'pci10de,3f6.a2' + 'pci10de,3f6' + 'pciclass,010185' + 'pciclass,0101'

The man-page for nv_sata should be updated, too.

Hans Rosenfeld wrote:

On a MCP61 system which has its rpool on such a controller, I added those PCI IDs with update_drv and rebooted. Basic I/O seems to work, but I could not test hotplugging.

Thanks, that at least establishes feature parity with ata/cmdk.

prtconf -Dv excerpt:
[...]

The man-page for nv_sata should be updated, too.

Will do.

Additionally, two MCP04 (CK804) IDs are missing, pci10de,36 and pci10de,3e.

Yes this update to /etc/driver_aliases (proposed by Albert Lee above) seems to work fine with a MCP61P chipset - my experiences below:

WRT sata support for a Compaq Compaq-Presario system (CQ5329F) with 1 SATA DVD and one SSD SATA hard disk (no IDE drives and no USB items except the kybd and mouse) AMD Athlon(tm) II X2 240, with a NVIDIA nForce MCP61P chipset. Note the BIOS (Compaq's American Megatrends Inc. 5.15) is very brain dead and has absolutely no configuration.

I have been running this system since Feb 1, 2012 and it looks pretty clean.

admin@oi151a1:/etc$ uname -a
SunOS oi151a1 5.11 qsicpq i86pc i386 i86pc Solaris

I added the following specifically to /etc/driver_aliases - via a hand edit of the file. Note since a few ID's (5) already exist for nv_sata the following command will not work add_drv -i '"pci10de,3e7" "pci10de,3e7" "pci10de,3f7"' -v nv_sata - that is why I do the hand edit. Just search for nv_stata (there are already 5 lines) and add the below three.

nv_sata "pci10de,3e7" 
nv_sata "pci10de,3f6" 
nv_sata "pci10de,3f7" 

Then I ran update_drv nv_sata followed by a reboot init 6 and you should now see the Nvidia Sata stuff in /var/messages or use the command dmesg

Feb  1 00:10:24 oi151a1 sata: [ID 663010 kern.info] /pci@0,0/pci103c,2a99@8,1 :
Feb  1 00:10:24 oi151a1 sata: [ID 761595 kern.info]     SATA disk device at port 0
Feb  1 00:10:24 oi151a1 sata: [ID 846691 kern.info]     model OCZ-ONYX
Feb  1 00:10:24 oi151a1 sata: [ID 693010 kern.info]     firmware 1.6
Feb  1 00:10:24 oi151a1 sata: [ID 163988 kern.info]     serial number TG7DBSJ5XBR06K29798V
Feb  1 00:10:24 oi151a1 sata: [ID 594940 kern.info]     supported features:
Feb  1 00:10:24 oi151a1 sata: [ID 981177 kern.info]      48-bit LBA, DMA, Native Command Queueing, SMART, SMART self-test
Feb  1 00:10:24 oi151a1 sata: [ID 643337 kern.info]     SATA Gen2 signaling speed (3.0Gbps)
Feb  1 00:10:24 oi151a1 sata: [ID 349649 kern.info]     Supported queue depth 32, limited to 1
Feb  1 00:10:24 oi151a1 sata: [ID 349649 kern.info]     capacity = 62533296 sectors
Feb  1 00:10:24 oi151a1 scsi: [ID 583861 kern.info] sd1 at nv_sata1: target 0 lun 0

Here we see the original "5" lines followed by the new "3" lines in /etc/driver_aliases

admin@oi151a1:/etc$ cat driver_aliases | egrep nv_sata
nv_sata "pci10de,266" 
nv_sata "pci10de,267" 
nv_sata "pci10de,37f" 
nv_sata "pci10de,54" 
nv_sata "pci10de,55" 
nv_sata "pci10de,3e7" 
nv_sata "pci10de,3f6" 
nv_sata "pci10de,3f7" 

Perhaps there should be an RTI to get these items into illumos gate (or openindian? as driver_aliases seems to be empty in illumos gate), I am not sure if the three new lines will "always be unique" (I think so but I don't do a lot of driver and PCI id stuff).

I just want to document that it seems to work great for me on this chipset, MCP61P with an AMD Athlon(tm) II X2 240 processor. It might be nice if we had an RTI for people running OI, SmartOS or illumian on older boxes.

Albert, here is a test of webrev http://trisk.deadgerbil.com/webrevs/il_1023/ it works for me on a Compaq-Presario CQ5329F (e.g. chipset MCP61).

However there is an small (non-code) issue with the current patch only for the man page "nv_sata.7d" see http://www.pastie.org/3721696 for full details of my test.

Albert,

First

I was working on a tiny fix to your il_1023.patch e.g. an issue with patching the man page not a code issue my version that works has a small change at about line 10 (below)

< -.TH nv_sata 7D "22 Jul 2008" "SunOS 5.11" "Devices" 
---
> -.TH NV_SATA 7D "Jul 22, 2008" 

The required change (above) to -.TH NV_SATA 7D" makes your patch work without any errors for applying to oi_151a5 (I was seeing Hunk #1 FAILED at 1.)

See http://pastie.org/4229017 for full diff e.g. "diff il_1023.patch il_1023b.patch" where il_1023b.patch is my version.

Second

But ever single time I try to make a webrev (nightly with lint) with my MCP61 system that has just 2GB RAM (with your patch applied) I get the following message to the console over and over every time I try to do a nightly with lint

WARNING: /pci@0,0/pci103c,2a99@8,1: 
sata_dma_buf_setup: no buf DMA resources ffffffff

then the system eventually freezes, this always happens during 'lint' in my run of "time ./nightly.sh illumos.sh".

Now I don't think this is an issue related to your patch, because even without your patch (for nv_sata) when my SSD and DVD are attached as IDE devices (after a stock oi_151a5 from the ISO) I also get a freeze during a nightly build with lint. I don't know what message is printed to console in this IDE case - but it almost always freezes too (I have only succeeded once out of ten times in completing a 'lint' run in my nightly build).

For the second issue, is your system running out of memory or swap space? Try this change:

$ diff nightly-orig nightly   
1696c1696
< TMPDIR="/tmp/nightly.tmpdir.$$" 
---
> TMPDIR="/var/tmp/nightly.tmpdir.$$" 

Thanks Gary, the TMPDIR change did the trick (solving my system freeze during my nightly build).

I was able to make a new webrev on oi_151a5 with my minor update to Albert Lee's patch (il_1023) for the nv_sata.7d man page such that the patch now installs without error e.g. http://cr.illumos.org/~webrev/jon_strabala/il_1023b/

I have an ASROCK N68C-GS FX with NVIDIA® GeForce 7025 / nForce 630a (MCP61)

I also needed to # update_drv -a -i "pci10de,3f6" nv_sata .

Mar 15 16:09:14 x3200 nv_sata: [ID 517869 kern.info] NOTICE: inst0 port1: rev id is A2 and is not capable of 40-bit DMA addressing
Mar 15 16:09:14 x3200 pcplusmp: [ID 805372 kern.info] pcplusmp: pci10de,3f6 (nv_sata) instance 0 irq 0x14 vector 0x40 ioapic 0x4 intin 0x14 is bound to cpu 2
Mar 15 16:09:14 x3200 sata: [ID 663010 kern.info] /pci@0,0/pci1849,3f6@8 :
Mar 15 16:09:14 x3200 sata: [ID 761595 kern.info]     SATA disk device at port 0
Mar 15 16:09:14 x3200 sata: [ID 846691 kern.info]     model INTEL SSDSA2M080G2GN                    
Mar 15 16:09:14 x3200 sata: [ID 693010 kern.info]     firmware 2CV102M3
Mar 15 16:09:14 x3200 sata: [ID 163988 kern.info]     serial number CVPO00700560080BGN  
Mar 15 16:09:14 x3200 sata: [ID 594940 kern.info]     supported features:
Mar 15 16:09:14 x3200 sata: [ID 981177 kern.info]      48-bit LBA, DMA, Native Command Queueing, SMART, SMART self-test
Mar 15 16:09:14 x3200 sata: [ID 643337 kern.info]     SATA Gen2 signaling speed (3.0Gbps)
Mar 15 16:09:14 x3200 sata: [ID 349649 kern.info]     Supported queue depth 32, limited to 1
Mar 15 16:09:14 x3200 sata: [ID 349649 kern.info]     capacity = 156301488 sectors
Mar 15 16:09:14 x3200 scsi: [ID 583861 kern.info] sd4 at nv_sata0: target 0 lun 0
Mar 15 16:09:14 x3200 genunix: [ID 936769 kern.info] sd4 is /pci@0,0/pci1849,3f6@8/disk@0,0
Mar 15 16:09:14 x3200 genunix: [ID 408114 kern.info] /pci@0,0/pci1849,3f6@8/disk@0,0 (sd4) online

what I don't get is why NCQ depth is 1 instead of 32...

I glossed over the first line of my extract, indicative I wasn't getting dma.
After applying Jon's update of Albert's patch the message is no longer there and I get a noticeable performance boost on the above mentioned machine.

I believe this patch should be integrated. It fixes as well the incorrect assumption that any device with rev < a3 is an MCP5x, the devid not being checked.