# Asus P8Z68-V PRO (Z68 chipset) support



## jkcarrol (May 14, 2011)

Hi All,

I'm anxiously awaiting the parts for my new server I'm planning to build, and I'm wondering if anyone has details about the Asus P8Z68-V PRO motherboard and what I might have trouble with regarding FreeBSD support.

I'm currently running 8.2-RELEASE, and would consider 8-STABLE if needed to support any of the SATA ports. I have 6 hard drives in here currently along with an optical drive. While the optical drive would be nice to keep, I'd sacrifice that for a HDD, since my 6 hard drives are in two separate zpools and 6 ports are the absolute minimum I need to be able to use this board.

The motherboard I ordered is an Asus P8Z68-V PRO. Here's a breakdown of the hardware in this system and my guess as to support, but I'd appreciate any information on the Marvell controller (e.g. finding the specific Marvell SATA-III chipset it uses, I couldn't find it on asus's specs page for the board).

- CPU: Core i7 2600k
- Motherboard: Asus P8Z68-V PRO
  * 2 Intel 6 Gbps SATA ports (ICH10? Not sure which)
  * 4 Intel 3 Gbps SATA ports (same controller as the 6Gbps?)
  * 2 Marvell 6 Gbps SATA ports (not sure which Marvell controller)
  * 1 JMicron 362 eSATA port
  * USB 3.0 and 2.0 (only need 2.0 for a UPS and mouse; but is the 3.0 supported?)
- LAN: 1 on the mobo (Intel gigE), 1 PCI-Express Intel card (<a href="http://www.newegg.com/Product/Product.aspx?Item=N82E16833106033">this one</a>)

So my questions:

1. Is the Intel ICH controller one controller for both the 6Gbps and 3Gbps ports? Or is it two separate ones? And if so, are they both supported? Or if not specifically supported, would they just work as AHCI? I'm already using ahci and my disks are adaN.

2. How can I find out which Marvell controller it is, and whether it's supported? Or is it again a case where it would "just work" in AHCI mode as a generic AHCI controller?

3. Is support for the JMicron 362 just a matter of adding the proper PCI ID, etc since it is probably similar to the 361 or 363? E.g. does it just require proper identification, or does it need a separate Marvell-specific driver?

4. Regarding the Intel Core i7 2600k, should I be leaving hyperthreading off? I know the previous generation (P4/Pentium D) HTT was both a) a security risk and b) made things worse because the scheduler or OS didn't know the difference between a logical and physical core? I'm planning to do some testing with and without it to see which is optimal for my particular work load, but I'm wondering if, in general, enabling HTT on these new i7s is recommended or not.

Thanks in advance for any information or advice you can provide!


----------



## jkcarrol (May 14, 2011)

Doh. It looks like the Marvell controller is the 88SE9172. A cursory grep of /usr/src/sys doesn't appear to be supported. 

If the Intel ports aren't supported, I guess I'll be SOL until it gets support. Or I'll have to shell out a ton of money for 1 or 2 PCI-Express SATA cards. Sigh.

Please, please tell me the Intel ports are supported...


----------



## mav@ (May 15, 2011)

1. Intel ports should be supported. If AHCI enabled in BIOS, all of them should be present on the same AHCI controller.
2. I have no idea about 88SE9172, but 88SE9182 were recently added. I can suppose that 88SE9172 could be somethingclose. You could try to add it's ID into ahci.c, rebuild/reboot and report the result.
3. I have no idea, but it would be nice for you to start from providing `pciconf -lvcb` output from that system.
4. HT effectiveness much improved from the first supporting CPU models. If software you are going to use is able to handle so many CPUs, I would tell -- enable.


----------



## jkcarrol (May 15, 2011)

Thanks very much for the reply. I did find a thread containing dmesg output which looks promising:



> ```
> ahci0: <Intel Cougar Point AHCI SATA controller> port 0xff00-0xff07,0xfe00-0xfe03,0xfd00-0xfd07,0xfc00-0xfc03,0xfb00-0xfb1f
> mem 0xfbffc000-0xfbffc7ff irq 19 at device 31.2 on pci0
> ```



So I think you're right that the 6 Intel ports should work. So that should suffice for the time being. At least my two zpools will be operational. I rarely use the optical drive anyway, but obviously long term I'd want to find a way to use it.

Regarding the Marvell and JMicron controllers, I will certainly post verbose boot output, pciconf output, and anything else that would be beneficial. I will try adding the PCI IDs for both the Marvell and JMicron controllers and see if that helps (unless they are somehow operational without those additions to ahci).

I suppose HT effectiveness depends largely on the task at hand. I'll do some testing of my own and see which is better for my particular use cases. But I'd be glad to post the results. I wrote a little perl module to automate running arbitrary commands as a benchmark (either timing the commands or parsing output). So I'll post the results of those workloads with and without HT.

Once I have the hardware and can get the pcifonf/etc output, I'll post back. Thanks again.


----------



## jkcarrol (May 20, 2011)

mav@ said:
			
		

> 4. HT effectiveness much improved from the first supporting CPU models. If software you are going to use is able to handle so many CPUs, I would tell -- enable.



Wow, I'll say! I'm doing some comparisons and although the buildkernel is a wash (*make -j5* with hyperthreading off is almost identical in time to *make -j7* with hyperthreading enabled), I'm seeing improvements of between 18 and 35 % on ffmpeg encodes, depending on the input (SD vs. 720p vs. 1080p).

So it definitely seems like hyperthreading is making a difference for ffmpeg encoding. I'm going to run through some buildworlds with and without hyperthreading tomorrow night, but so far I'm impressed with the new hyperthreading, although it does add quite substantially to the CPU cores' temperatures. I'm seeing a peak of about 54 C with HTT off and 61 with HTT on.

Is there a way to distinguish the cores? E.g. determine which of them are the physical cores and which are the logical ones? The reason I ask, is I graph each core's CPU temperature and I'd like to only graph the 4 physical cores' temperatures. I'm not even sure the HTT cores' temperatures even make any sense.


----------



## mav@ (May 22, 2011)

All cores are equal. The correct question is which cores share resources. Try: 

```
sysctl -b kern.sched.topology_spec
```


----------



## jkcarrol (May 22, 2011)

Right, understood the scheduler should know which share resources (e.g. which logical HTT core shares cache with the physical core). But doesn't the scheduler need to be able to distinguish a normal core from a logical/HTT core?

As for the Marvell controller, although it does show up in dmesg:


```
ahci0: <AHCI SATA controller> port 0xb040-0xb047,0xb030-0xb033,0xb020-0xb027,0xb010-0xb013,0xb000-0xb00f mem 0xfb810000-0xfb8101ff
 irq 19 at device 0.0 on pci9
ahci0: [ITHREAD]
ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS
```

I could not see the hard drive attached to it in camcontrol devlist output. The disk is detected at boot time.

Is it as simple as adding the PCI ID, rev etc to ahci.c? Does it not attach any SATA devices if it doesn't match a specific PCI ID? I had hoped if it showed the controller in pciconf attached to ahci, that drives connected to it might work. I'll try updating ahci.c and see if the drive is detected. Thanks!


----------



## jkcarrol (May 22, 2011)

*88SE9172 in ahci.c*

I added an entry for the 88SE9172 to sys/dev/ahci.c and the hard drive attached to it then works properly with no issues (so far):


```
ahci0: <Marvell 88SE9172 AHCI SATA controller> port 0xb040-0xb047,0xb030-0xb033,0xb020-0xb027,0xb010-0xb013,0xb000-0xb00f
 mem 0xfb810000-0xfb8101ff irq 19 at device 0.0 on pci9
ahci0: [ITHREAD]
ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: [ITHREAD]
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich1: [ITHREAD]
```

And camcontrol shows it:


```
scbus0 on ahcich0 bus 0:
<>                                 at scbus0 target -1 lun -1 ()
scbus1 on ahcich1 bus 0:
<WDC WD4000AAKS-00A7B0 01.03B01>   at scbus1 target 0 lun 0 (ada0,pass0)
<>                                 at scbus1 target -1 lun -1 ()
```

The zpool that ada0 is a part of also seems to work fine.

My bluray drive is now attached to the 6th Intel PCH port, and is detected properly:


```
<ATAPI iHBS212   2 5L06>           at scbus7 target 0 lun 0 (cd0,pass6)
```

However, I tried to burn a small ISO (the 8.2 bootonly image) and it failed miserably. But that's another topic entirely. There seems to be something wrong with this particular drive or it is doing something FreeBSD does not like.

For what it's worth, here is the additional entry I added to ahci.c:


```
{0x91721b4b, 0x11, "Marvell 88SE9172",  AHCI_Q_NOBSYRES},
```


----------



## DutchDaemon (May 23, 2011)

jkcarrol, system output always needs to be placed inside 
	
	



```
tags.
```


----------



## mav@ (May 26, 2011)

Added 88SE9172 ID to FreeBSD 9-CURRENT.


----------



## jkcarrol (May 26, 2011)

mav@ said:
			
		

> Added 88SE9172 ID to FreeBSD 9-CURRENT.



Great, thanks a lot! You can probably take and close this PR :

http://www.freebsd.org/cgi/query-pr.cgi?pr=157281


----------



## jkcarrol (May 26, 2011)

mav@ said:
			
		

> Added 88SE9172 ID to FreeBSD 9-CURRENT.



I'm not sure if it matters, but it looks like in your commit the rev is 0x0, but in my case at least, it's 0x11. This is the code I added to 8.2's ahci.c which is working:


```
{0x91721b4b, 0x11, "Marvell 88SE9172",  AHCI_Q_NOBSYRES},
```

But the commit has:


```
{0x91721b4b, 0x00, "Marvell 88SE9172",  AHCI_Q_NOBSYRES},
```

Thanks again!


----------



## mav@ (May 26, 2011)

That was intentional. I don't know any difference between 0x11 and earlier chip revisions, so have no point to differentiate them.


----------



## jkcarrol (May 26, 2011)

mav@ said:
			
		

> That was intentional. I don't know any difference between 0x11 and earlier chip revisions, so have no point to differentiate them.



Ok, thanks. I was under the false impression that the revision had to match what I was seeing in pciconf output, which for me is 0x11. If that's not the case, then it should be fine.


----------



## jkcarrol (May 29, 2011)

mav@ said:
			
		

> That was intentional. I don't know any difference between 0x11 and earlier chip revisions, so have no point to differentiate them.



I'm sure it will come as no surprise, but I figured I would mention it anyway.  When I rebuilt my kernel with the ZFS v28 patchset, I used your patch on ahci.c (or rather, that one addition) and it is working just fine. I just wanted to let you know things are working well. Thanks again for committing the update.


----------



## yshdsnd (Jul 3, 2011)

Hi,

I'm using the same motherboard, Asus P8Z68-V PRO. Two HDDs are connected to the Marvell 88SE9172 and configured as ZFS mirror. When I run *zfs scrub*, checksum errors often occur. When these HDDs are connected to the Intel controller, such errors do not occur.
I suspect the ahci driver. 

Has anyone ever seen a phenomenon same as me?


```
FreeBSD 8.2-STABLE #11: Sat Jul  2 01:21:42 JST 2011
    [email]root@eagle.ys.sokohiki.org[/email]:/usr/obj/usr/src/sys/eagle amd64
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (3411.15-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x206a7  Family = 6  Model = 2a  Stepping = 7
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,
 PBE>
 Features2=0x17bae3ff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,TSCDLT,AESNI,
 XSAVE,AVX>
  AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
  AMD Features2=0x1<LAHF>
  TSC: P-state invariant
...

ahci0: <Marvell 88SE9172 AHCI SATA controller> port 0xb040-0xb047,0xb030-0xb033,0xb020-0xb027,0xb010-0xb013,0xb000-0xb00f mem 0xfb810000-
 0xfb8101ff irq 19 at device 0.0 on pci9
ahci0: [ITHREAD]
ahci0: AHCI v1.00 with 2 6Gbps ports, Port Multiplier supported with FBS
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich0: [ITHREAD]
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich1: [ITHREAD]

...

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: <WDC WD20EARS-00MVWB0 50.0AB50> ATA-8 SATA 2.x device
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
ada1 at ahcich1 bus 0 scbus1 target 0 lun 0
ada1: <WDC WD20EARS-00MVWB0 50.0AB50> ATA-8 SATA 2.x device
ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada1: Command Queueing enabled
ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C)
```


```
# zpool status
  pool: ztest0
 state: ONLINE
status: One or more devices has experienced an error resulting in data
        corruption.  Applications may be affected.
action: Restore the file in question if possible.  Otherwise restore the
        entire pool from backup.
   see: [url]http://www.sun.com/msg/ZFS-8000-8A[/url]
 scan: scrub canceled on Sun Jul  3 01:37:42 2011
config:

        NAME             STATE     READ WRITE CKSUM
        ztest0           ONLINE       0     0     3
          mirror-0       ONLINE       0     0     6
            gpt/wd2tb-0  ONLINE       0     0     6
            gpt/wd2tb-1  ONLINE       0     0     6

errors: 3 data errors, use '-v' for a list
```


----------



## Neco (Oct 13, 2011)

Yep, same issue as you. CKSUM-errors on those drives (ada0 and ada1 in my case).
Same motherboard as you.


----------



## mav@ (Oct 17, 2011)

Pity to hear it, but without having chip documentation, not speaking about it's errata, I can't say anything. Reliable, simple and quick way to reproduce that problem could help.

Generally I would consider to connect different mirror components to the different controllers. In that case single controller failure should not affect the data availability.


----------



## yshdsnd (Oct 18, 2011)

mav@ said:
			
		

> Pity to hear it, but without having chip documentation, not speaking about it's errata, I can't say anything. Reliable, simple and quick way to reproduce that problem could help.
> 
> Generally I would consider to connect different mirror components to the different controllers. In that case single controller failure should not affect the data availability.



This issue occurs not only with this mother board but also the HighPoint RocketRAID 620 SATA RAID card. I posted about it to freebsd-table on September 11.

http://www.mail-archive.com/freebsd-stable@freebsd.org/msg117245.html

I tested it from that several times, but an error occurred only in ZFS. When I used UFS, the data corruption seemed not to occur as far as I tested it. Regarding the test of UFS/ZFS, I simply copied some large(4-5GB) files and compared MD5.

I heard this issue had also occurred with the Marvell 88SE9123 controller. I also suspect ZFS, but do not know how I examine it. Any ideas?


----------

