UEFI Support: 3TB Drives & Mouse Support Pre-Boot

Remember the mountain of issues I had trying to get Seagate’s 3TB HDD to work as a boot drive in my X58 system? A couple of weeks ago Intel released version 10.1 of its storage drivers, which added software support for drives larger than 2.2TB. That’s one piece of the puzzle. With Sandy Bridge, many motherboard manufacturers are moving to UEFI instead of traditional 32-bit PC BIOSes. Combine that with a GPT partition and your new Sandy Bridge system should have no problems booting to and accessing 3TB drives made of a single partition.


ASUS' entire SNB lineup is UEFI enabled

ASUS sent over a couple of its 6-series motherboards which boast a custom skinned UEFI implementation. You get all of the functionality of a traditional BIOS but with a GUI, and yes, there’s full mouse support.

You’re either going to love or hate the new UEFI GUIs. They do take a little time to get used to but pretty much everything is where you’d expect it to be. Navigating with the mouse can be quicker than the keyboardin some situations and slower in others. Thankfully the interface, at least ASUS’, is pretty quick. There’s scroll wheel support although no draggable scroll bars, which makes quickly scrolling a little frustrating.

Unlike P55, you can set your SATA controller to compatible/legacy IDE mode. This is something you could do on X58 but not on P55. It’s useful for running HDDERASE to secure erase your SSD for example. If you do want to use HDDERASE on a 6-series motherboard you’ll need to first run HDDERASE4 to disable the UEFI initiated security on your drive and then run HDDERASE3 to secure erase it.

The biggest improvement to me honestly is POST time. Below is a quick comparison of time from power on to the Starting Windows screen. I’m using the exact same hardware in all three cases, just varying motherboard/CPU:

  Intel P67 Intel P55 Intel X58
Time from Power on to Boot Loader 22.4 seconds 29.4 seconds 29.3 seconds
The 6-series Platform & 6Gbps SATA Performance The Future: Z68 Chipset in Q2, LGA-2011 in Q4
Comments Locked

283 Comments

View All Comments

  • dgingeri - Monday, January 3, 2011 - link

    I have a really good reason for X58: I/O

    I have 2X GTX 470 video cards and a 3Ware PCIe X4 RAID controller. None of the P67 motherboards I've seen would handle all that hardware, even with cutting the video cards' I/O in half.

    This chip fails in that one very important spot. if they had put a decent PCIe controller in it, with 36 PCIe lanes instead of 16, then I'd be much happier.
  • Exodite - Monday, January 3, 2011 - link

    That's exactly why this is the mainstream platform, while x58 is the enthusiast one, though. Your requirements aren't exactly mainstream, indeed they are beyond what most enthusiasts need even.
  • sviola - Monday, January 3, 2011 - link

    You may want to look at the Gigabyte GA-P67A-UD5 and GA-P67A-UD7 as they can run your configuration.
  • Nihility - Monday, January 3, 2011 - link

    Considering the K versions of the CPUs don't have it.

    If I'm a developer and use VMs a lot, how important will VT-d be within the 3-4 years that I would own such a chip?

    I know that it basically allows direct access to hardware and I don't want to get stuck without it, if it becomes hugely important (Like how you need VT-x to run 64 bit guests).

    Any thoughts?
  • code65536 - Monday, January 3, 2011 - link

    My question is whether or not that chart is even right. I'm having a hard time believing that Intel would disable a feature in an "enthusiast" chip. Disabling features in lower-end cheaper chips, sure, but in "enthusiast" chips?! Unless they are afraid of those K series (but not the non-K, apparently?) cannibalizing their Xeon sales?
  • has407 - Monday, January 3, 2011 - link

    Relatively unimportant IMHO if you're doing development. If you're running a VM/IO-intensive production workload (which isn't likely with one of these), then more important.

    Remember, you need several things for Vt-d to work:
    1. CPU support (aka "IOMMU").
    2. Chip-set/PCH support (e.g., Q57 has it, P57 does not).
    3. BIOS support (a number of vendor implementations are broken).
    4. Hypervisor support.

    Any of 1-3 might result in "No" for the K parts. Even though it *should* apply only to the CPU's capabilities, Intel may simply be saying it is not supported. (Hard to tell as the detailed info isn't up on Intel's ark site yet, and it would otherwise require examining the CPU capability registers to determine.)

    However, it's likely to be an intentional omission on Intel's part as, e.g., the i7-875K doesn't support Vt-d either. As to why that might be there are several possible reasons, many justifiable IMHO. Specifically, the K parts are targeted at people who are likely to OC, and OC'ing--even a wee bit, especially when using VT-d--may result in instability such as to make the system unusable.

    If Vt-d is potentially important to you, then I suggest you back up through steps 4-1 above; all other things equal, 4-2 are likely to be far more important. If you're running VM/IO-intensive workloads where performance and VT-d capability is a priority, then IMHO whether you can OC the part will be 0 or -1 on the list of priorities.

    And while VT-d can make direct access to hardware a more effective option (again, assuming Hypervisor support), it's primary purpose is to make all IO more efficient in a virtualized environment (e.g., IOMMU and interrupt mapping). It's less a matter of "Do I have to have it to get to first base?" than "How much inefficiency am I willing to tolerate?" And again, unless you're running IO-intensive VM workloads in a production environment, the answer is probably "The difference is unlikely to be noticeable for the work [development] I do."

    p.s. code65536 -- I doubt Intel is concerned with OC'd SB parts cannibalizing Xeon sales. (I'd guess the count of potentially lost Xeon sales could be counted on two hands with fingers to spare.:) Stability is far more important than pure speed for anyone I know running VM-intensive loads and, e.g., no ECC support on these parts is for me deal killer. YMMV.
  • DanNeely - Tuesday, January 4, 2011 - link

    For as long as MS dev tools take to install, I'd really like to be able to do all my dev work in a VM backed up to the corporate lan to ease the pain of a new laptop and to make a loaner actually useful. Unfortunately the combination of lousy performance with MS VPC, and the inability of VPC to run two virtual monitors of different sizes mean I don't have a choice about running visual studio in my main OS install.
  • mino - Wednesday, January 5, 2011 - link

    VMware Workstation is what you need. VPC is for sadists.

    Even if your budget is 0(zero), and VPC is free, KVM/QEMU might be a better idea.

    Also, Hyper-V locally and (via RDP) is pretty reasonable.
  • cactusdog - Monday, January 3, 2011 - link

    If we cant overclock the chipset how do we get high memory speeds of 2000Mhz+? Is there still a QPI/Dram voltage setting?

  • Tanel - Monday, January 3, 2011 - link

    No VT-d on K-series? FFFFUUUU!

    So just because I want to use VT-d I'll also be limited to 6 EUs and have no possibility to overclock?

    Then there's the chipset-issue. Even if I got the enthusiast targeted K-series I would still need to get the:
    a) ...H67-chipset to be able to use the HD-unit and QS-capability - yet not be able to overclock.
    b) ...P67-chipset to be able to overclock - yet to lose QS-capability and the point of having 6 extra EUs as the HD-unit can't be used at all.

    What the hell Intel, what the hell! This makes me furious.

Log in

Don't have an account? Sign up now