Which SATA controllers to use on my Z68?

P

Perm

Weaksauce
Joined
Nov 1, 2004
Messages
82
Hi guys,

It has been a few years (~5) since I built a new rig (I really extended the life of my old one) so I did some research on motherboards and ended up going with the z68 for my new one I put together last night, specifically: Asus P8Z68-V Pro (review done in May here: http://www.hardocp.com/article/2011/05/11/asus_p8z68v_pro_z68_chipset_motherboard_review )

My question is I'm a little confused about the SATA controllers on this thing. There is a "Marvel" and an Intel SATA controller, and in the BIOS it shows only the Intel controller having 6gb/s functionality. So I plugged my Crucial SSD into that controller (I also have a 1TB platter drive plugged into the other Intel 6gb/s channel.)

I then slapped my dvd drive onto the Intel 3gb/s controller channel and attempted a boot. I had a Win7 bootable disc in the drive, but the system didn't seem to recognize it as such. I'm used to seeing the "hit any button to boot from this drive" OR "no operating system found" text showing up at some point, but basically BIOS recognizes all drives, but after it gets through all sequences it just sits at a prompt blinking.

It was late last night when I got to first boot, so I have a lot more work to do in troubleshooting, but the first thing I did was moved the dvd drive to the marvel controller just to see if that made a difference. It didn't seem to. Ultimately I got it to boot off the dvd drive by putting my win xp cd in the drive... so it makes me think that my controllers aren't seeing the win7 boot files for some reason?

I found a file on ASUS' site that also shows a Marvel 6gb/s sata driver for Win7, so I'm wondering if I should install that and move my hard drives over to the Marvel controller? Does it matter?

Any thoughts are appreciated. Today at work I actually copied my win7 contents to both a flash drive and my SSD, so I think I'm more prepared for this evening when I get home.

Thank you!

ETA: I also brought this up because I heard some quibbles that sometimes these two controllers don't work quite right simultaneously... but I thought that was only if you were trying to use them both in RAID configurations at the same time, which I'm not using either of them in RAID at the moment.

ETA2: Just a random update for anyone who might stumble across this later. There is a minor asterisk in the mobo manual that says "Marvell controller does not support ATAPI devices," so I'll have to ensure my DVD drive isn't sitting on that controller. Although I could swear that I had it plugged into both the Intel and Marvel controllers at one point, and BIOS detected it the same way on either one...
 
Last edited:
Well after another evening of playing, I'll response to this post with more info... hopefully to help others in the future.

First of all, after googling Asus P8Z68-V Pro and going through setup myself... it is clear that these SATA controllers are quirky. If you start a project build with one of these boards and can't immediately figure out why it won't boot... don't give up, it's probably not you, and the board probably isn't defective, it's just not intuitive.

I'll try to summarize my experience so this post doesn't turn into a novel (because I feel like it's going to!) :)

Hardware:
Mobo - Asus P8Z68-V Pro
Proc - Intel i7-2600K
RAM - Gskill - 4x4gb (16gb total)
SSD - Crucial M4 CT128M4SSD2CCA 2.5" 128GB SATA III
Platter drive - Western Digital - 1TB 7200 RPM 32MB Cache SATA
ATAPI/Optical drive - Lite On DVD R/W
Vid Card: ASUS GeForce GTX 560 Ti (Fermi) 1GB 256-bit GDDR5

Originally I had both hard drives plugged into the Intel 6gb/s controller, and the dvd drive to the Intel 3gb/s controller. I setup the BIOS so the DVD drive was the first boot option, the SSD the second boot option. Both of my Win7 DVDs (I have a 32 and 64 bit install) would literally do nothing... it was like the DVD drive was not set to boot. However, when I put my Win XP cd in, it WOULD boot.

In BIOS all drives were recognized completely as they should be.

To help in troubleshooting I coped my win 7 64 cd to a USB flash drive. I also discovered in the meantime that adding the platter drive to the 6gb/s controller was not optimal, so I moved that to the Marvel 3g/s controller.

I set the USB flash drive to the first boot device, and voila... Win7 install started as expected. However, same thing in the DVD drive as a CD? Nothing. (Important note: make sure optical drives aren't on the Marvel controller either, according to Marvel they won't work... even though the controller seems to recognize them)

So I go all the way through setup, get Win7 installed and my 1TB drive just disappears on me. I thought I had seen it in explorer when I first got the install done, but it looked like on one of the reboots it just disappeared? I wasn't sure, so I rebooted my machine and the drive just reappeared again. I continued on my way, installed Steam.. noticed that steam was downloading updates in my notification tray so all seemed well. However, I then saw the steam client just disappear from the notification tray. I go into explorer and sure enough, the D drive (where the steam.exe resides) is just gone. I was able to reproduce this behavior a couple more times on reboots, where I could see the drive and everything was good.. then the drive would literally just disappear from explorer (and you couldn't see it in disk management or anything.. it was just *gone.*) At some point I powered the machine off, turned it back on, and it was fine.

At this point I thought... well why not flash the BIOS? I had one revision behind, and noticed there was an updated file on ASUS' website, so I decide to go flash it. First of all... be warned that their "AI Suite" that's supposed to do BIOS updates from the internet looks awesome... and it probably is, if it would actually install. There are numerous threads about this, I was one of the unlucky people who couldn't get it to run. I also couldn't get the .rom file to read from the BIOS "EZ Flash" utility (it would just say "this is not a efi rom file" even though the file I was pointing the utility to clearly was a bios for this board.) Ultimately I had to use the DOS bios flash utility.. but it seemed to work.

So, after new BIOS is flashed I reboot... nothing. No boot. Drives are all in the same place, drives are all completely recognized by the BIOS.. no boot. The *only* way I could get it to boot was to put my Win7 USB drive back into place and literally reinstall from scratch. Important Note: just flash your BIOS before you start the install... I just didn't anticipate these headaches at all.

So after going all the way through another Win7 install... things seem to be ok. I have to say I'm still nervous about turning the power off though. I've powered off and rebooted a few times, and things seem ok for now... but I'm definitely not filled with confidence at this point.

The good news is things are running well and the system screams. I think the only thing wrong with this board are the SATA controllers... and possibly the SATA controllers only as it relates to certain SSDs maybe?

ASUS also needs to fix their AI Suite bullshit, so you can do a BIOS update from the web on all systems. I tried everything to get that damn app to install.... there are entire threads on the web for the last two years about this problem, but they haven't seemed to bother themselves with a fix.

Overall I'm happy, but man what a pain. One of those builds where you think you're going crazy or missing something obvious, but after weird things happen repeatedly and you see others posting the same thing, it starts to become slightly more clear that there's just something going on with the drive controllers.

I guess I have no idea why they have two different brands of controllers on the board. Why have 2 Intel 6gb/s and 4 Intel 3gb/s and then 2 Marvel 3gb/s? Why not just put 6 Intel 3gb/s controllers on and be done with it? Something tells me that has at least something to do with it...

Yep... my intuition was right... it was a novel. :)
 
FYI, the Intel disk controller is part of the Z68 chip, which has to be driven by a CPU (and the architecture only allows for one per CPU). Hence the third-party disk controllers. Boards which support multiple processors would have multiple chipsets but that takes you out of Z68 territory into the Land of the Servers. Bring your wallet.
 
Intel controller is better than the Marvell controller. Only use the Marvell if necessary.

Intel only put 2 6Gbps controllers in this generation ICH chip. They'll probably switch them all over later, but for now, there are only 2.
 
The Intel controller is the better of the two. Secondly, like most boards these days you can't actually use more than one controller in RAID mode at a time. There is insufficient option ROM space to do so.
 
Dan_D said:
The Intel controller is the better of the two. Secondly, like most boards these days you can't actually use more than one controller in RAID mode at a time. There is insufficient option ROM space to do so.
Click to expand...

Really? That's still a limitation on current boards? I thought that was a thing of the past. Or, really, I think it depends on the board. I mod OROMs on another site, and it seems to vary.

Marvell and Intel RAID OROMs are much larger than, say, JMicron. The JMicron RAID OROM is actually smaller than just the DIFFERENCE in size between Intel 10.1 and 10.5. 10.5 added the >2TB boot support which explains it getting bigger, but the thing is 119KB compared to JMicron's 32KB...
 
bar_review said:
FYI, the Intel disk controller is part of the Z68 chip, which has to be driven by a CPU (and the architecture only allows for one per CPU). Hence the third-party disk controllers. Boards which support multiple processors would have multiple chipsets but that takes you out of Z68 territory into the Land of the Servers. Bring your wallet.
Click to expand...

The amount of CPUs has nothing to do with anything. The chipset was simply designed to handle only six ports. Chipsets designed for servers aren't really any better. In fact generally speaking, their feature set is more dated or at best the same as the consumer chips. Anyone serious about disk I/O will bring their own high performance SAS controller and drop it in a PCIe x4 or x8 slot. Intel knows this and deemed a chipset with 6+ SATA ports on it useless for the server market. Consumers rarely use that many disk drives so again, 6 ports should have been plenty (and are) for most people. The motherboard manufacturers can integrate whatever they want if they wish to expand the feature set of the board for additional market segmentation.

dandragonrage said:
Really? That's still a limitation on current boards? I thought that was a thing of the past.

Marvell and Intel RAID OROMs are much larger than, say, JMicron. The JMicron RAID OROM is actually smaller than just the DIFFERENCE in size between Intel 10.1 and 10.5. 10.5 added the >2TB boot support which explains it getting bigger, but the thing is 119KB compared to JMicron's 32KB...
Click to expand...

It's a problem on many P67 boards, some newer X58 boards (even Intel's own DX58SO2) and every single Z68 board I've ever seen. 890FX and 990FX aren't any better either.
 
Dan_D said:
Chipsets designed for servers aren't really any better. In fact generally speaking, their feature set is more dated or at best the same as the consumer chips.
Click to expand...

Most of the server boards use the same ICH10R (1156/1366) or whatever it's called for 1155 (ICH11R?) as the desktop boards. Some lower end boards have SATA 6Gb/s disabled (C202).

Dan_D said:
Anyone serious about disk I/O will bring their own high performance SAS controller and drop it in a PCIe x4 or x8 slot.
Click to expand...

Advice: don't use ASUS PIKE, it uses the PCI-e x4 1.0 (or now, 2.0) off the southbridge, which is slower than the lanes available from the CPU. Worse, they do that on 1366 AS WELL! (and most of their 1366 boards don't use all the IOH lanes for ports either)

Dan_D said:
Intel knows this and deemed a chipset with 6+ SATA ports on it useless for the server market.
Click to expand...

Intel feels that nobody will uses more than 6 SATA drives for a server (well, maybe SSDs, but this has been going for way before SSDs were economical), so they left the market to LSI (Supermicro, Intel and Tyan love to stick this chip directly on the board for a VERY low price) and Marvell for the HBA/RAID 10 chips.
 
dandragonrage said:
Marvell and Intel RAID OROMs are much larger than, say, JMicron. The JMicron RAID OROM is actually smaller than just the DIFFERENCE in size between Intel 10.1 and 10.5. 10.5 added the >2TB boot support which explains it getting bigger, but the thing is 119KB compared to JMicron's 32KB...
Click to expand...

Because Intel and Marvell make good chips with good software. JMicron only makes crap, so that's to be expected. Intel and Marvell use as much code as they deemed necessary to support the RAID features properly and fast enough, JMicron just did a dirty job and called it a day.
 
Really? That's still a limitation on current boards? I thought that was a thing of the past.
Click to expand...
Hasn't this MB BIOS size limitation always been like this?
 
Old Hippie said:
Hasn't this MB BIOS size limitation always been like this?
Click to expand...

I've seen a lot of boards that didn't have these problems but it seems more recent boards do. It really depends on the motherboard and how much crap eats up option ROM space.
 
Dan_D said:
I've seen a lot of boards that didn't have these problems but it seems more recent boards do. It really depends on the motherboard and how much crap eats up option ROM space.
Click to expand...
As usual I'm must be picking the wrong boards. :D
 
Old Hippie said:
As usual I'm must be picking the wrong boards. :D
Click to expand...

Well all the "recent" ones I've seen that don't have this problem either didn't support USB 3.0 or didn't support RAID beyond the chipset's controller. The Rampage III Black Edition for example supports USB 3.0, but only the ICH10R supports RAID. The SATA 6G ports and eSATA ports do not. Now my EVGA X58 3X SLI Classified Edition has no problems with running more than one storage controller in RAID mode, however it does not have USB 3.0 support of any kind as it predates USB 3.0 as a standard. Again I think the level of integration many of the high end boards have is causing these issues. Manufacturers haphazardly add features to the boards and make a check mark in a box of possible features their competitors will have just so they can be on a level playing field. No one seems to give a shit if all this crap works or not because most people, even those who buy high end boards don't actually use all that stuff. Even I have to admit that a lot of features on high end boards in my systems go totally unused.

For example, while I'm using the Rampage III Black Edition, I'm not running a RAID array at all. I might in the future off the ICH10R but that would be it. I've got two drives in the machine now. An Intel X25-M 80GB for the OS use with some applications installed on it, and a Western Digital WD1200FAEX 1.0TB Caviar Black drive for data storage, games, etc. But I don't use things like IEEE1394a ports, or even USB 3.0 at this point. I'm not using the eSATA ports or the SATA 6G controller. (Mainly because the Marvell controller isn't all that impressive.) I'm using a good amount of the PCIe real estate for my ThunderBolt and GTX 580 cards. The main appeal of a board like this is being able to handle multi-GPU setups well and overclock like crazy.

In my server I've got a couple drives on the ICH9R but I don't have anything else running on it and certainly no RAID arrays. I've got an LSI MegaRAID 8308ELP running all the drive arrays for anything important.
 
Last edited:
At this rate, the Intel Matrix RAID OROM is gonna be as big as your friggin' OS. So I suppose it does make sense that space is running out. I wonder what happens if one inserts an OROM uncompressed into a BIOS... normally, they are compressed and the OROM space that runs out is some sort of memory location that the OROM is decompressed into. I wonder if it still needs to use that space if it's inserted uncompressed into a BIOS that has enough space for it.
 
Well all the "recent" ones I've seen that don't have this problem either didn't support USB 3.0 or didn't support RAID beyond the chipset's controller.
Click to expand...
I'm kinda a step behind with my P6T but the BIOS wouldn't support a dual RAID either.

AAR I always thought there was a BIOS capacity/limitation that was a standard.

I did some Googling after I read this thread and it doesn't look like the BIOS has inherent limitations.

More than likely my BIOS limitation thought has a brain-stamp on it that I can't read.

In other words, I'm out-of-date and thinking about the past. :)

You'll have that! LOL!
 
dandragonrage said:
At this rate, the Intel Matrix RAID OROM is gonna be as big as your friggin' OS. So I suppose it does make sense that space is running out. I wonder what happens if one inserts an OROM uncompressed into a BIOS... normally, they are compressed and the OROM space that runs out is some sort of memory location that the OROM is decompressed into. I wonder if it still needs to use that space if it's inserted uncompressed into a BIOS that has enough space for it.
Click to expand...

As I understand it, the problem is with the space reserved in memory for option ROMs. This space is largely determined by the chipset design. Some chipsets are worse than others. The nForce 2200 was among the worst. It had far less OROM space than it's Intel counterparts. This made the use of RAID controllers a nightmare in some configurations.
 
As I understand it, the problem is with the space reserved in memory for option ROMs. This space is largely determined by the chipset design.
Click to expand...
Pretty much what I got out of my Googleing but if the ROM space is technically unlimited the other factor would be cost of the BIOS ROM chip or compatability with a 3 tier manfgs."price point" manufacturing?
 
Old Hippie said:
Pretty much what I got out of my Googleing but if the ROM space is technically unlimited the other factor would be cost of the BIOS ROM chip or compatability with a 3 tier manfgs."price point" manufacturing?
Click to expand...

It has nothing to do with the ROM chips themselves. It's all about option ROM space in memory. That being said some manufacturers do not bother to optimize their ROM code leaving it more complex and larger than it needs to be. This isn't all the board maker's faults. Sometimes it lies with whomever coded the ROM. In the case of JMicron or Marvell, they are responsible for their firmware. Gigabyte, ASUS, MSI etc. are integrators and nothing more. They can sometimes customize the ROM and enable / disable features as they see fit, but they ultimately do not really control the size of the ROMs.
 
It has nothing to do with the ROM chips themselves. It's all about option ROM space in memory.
Click to expand...
So the ROM space in a BIOS chip has nothing to do with the cost of the chip?

My thought was that a larger BIOS (like from Intel) would need a larger ROM chip and that would cost more money which would make Intel's BIOS less attractive to manfgs?

All sizes of BIOS chips cost the same?

Or am I missing the point here?

Can a manfg dedicate more spare space to a BIOS chip (probably with an increased cost for a larger size chip) that would allow extra BIOS options?
 
Old Hippie said:
So the ROM space in a BIOS chip has nothing to do with the cost of the chip?

My thought was that a larger BIOS (like from Intel) would need a larger ROM chip and that would cost more money which would make Intel's BIOS less attractive to manfgs?

All sizes of BIOS chips cost the same?

Or am I missing the point here?

Can a manfg dedicate more spare space to a BIOS chip (probably with an increased cost for a larger size chip) that would allow extra BIOS options?
Click to expand...

You are missing the point. The size of the ROM chip has nothing to do with the problem. It is the space reserved for the BIOS / Option ROMs in system memory that is the problem. How much space there is for OROMs in system memory is determined by the design of the chipset. Once this space is exceeded, some of the OROMs will fail to load and therefore won't initialize properly and be unavailable to the system. This can lead to systems that won't boot, RAID arrays that won't be recognized, or in some cases, the OROM configuration for a given controller or device will be unavailable to configure allowing you to do nothing with it. The only time where the size of the actual ROM becomes relevant is with regard to how full it is or rather, how many integrated devices are using it. All your Marvell, JMicron and your LAN controllers option ROMs are stored on the BIOS chip so they can be upgraded whenever your BIOS is all in one shot. You will still have OROM issues if you've got three RAID controller OROMs and dual digabit LAN adapter boot ROMs all trying to load whether your board has a 32mbit flash ROM or a 64mbit flash ROM. Again the size of the ROM chip itself is irrelevant. It's the amount of crap your board has on and what's enabled currently that's the issue.

Take the Gigabyte Z68X-UD3H-B3 as an example. It has a Marvell 9172 controller and a Intel controller built into the Z68 Express chipset itself. If I set the Marvell 9172 to RAID and configure an array on that controller, I can no longer create a RAID array on the Intel controller and vice versa. So if I used the Marvell 9172 for something, I'd lose the ability to use RAID arrays and even the Smart Response Technology features built into the chipset. The reverse is also true. Let's say I've used every port built into the chipset. 5 hard drives and one optical drive. At that point I decide I want to add two more drives to the system to use in a RAID 1 array for redundancy. I'm shit out of luck because the Marvel 9172 will prevent the system from booting once set to RAID mode. Worse yet I won't even be able to configure anything in the 9172 because the OROM will not appear and I'll get no prompts allowing me to enter the configuration. I'm still doubly fucked because I can't even throw an LSI or Areca card into a PCIe slot because one of two things will happen.
  • Either there will be insufficient OROM space for that controller as well leading to the same problem.
  • There will be sufficient OROM space because LSI and Areca are better optimized than the Marvell 9172, however I won't be able to run the card anyway because there is something fucked up with the PCIe implementation optimizing the board's PCIe space for graphics cards and to ensure greater stability while overclocking leaving me little else in the way of options.
This is why higher end drive controllers are hit and miss when it comes to their use on consumer grade motherboards.
 
Last edited:
You need space in the BIOS for the OROMs which are compressed, and you need space in memory for them to decompress to and run from. My thought from earlier was that perhaps the space in memory could be bypassed if they were put into the BIOS image uncompressed (which is possible with some BIOS platforms) but that is probably not the case, and Dan_D also does not seem to think that the case. Reading it straight from the BIOS would probably be too slow, anyway...
 
My thought from earlier was that perhaps the space in memory could be bypassed if they were put into the BIOS image uncompressed (which is possible with some BIOS platforms)
Click to expand...
I never thought about that.

I thought there were BIOS capacity limitations because I remember (from a long time ago) some of my friends had to modify the BIOS to play some games.

I think they were removing some things to make room for something the game needed to be played?

This happened long before I was into computers.

I was into audiophile equipment at the time and wasn't paying attention to this new-fangled computer stuff. :)

AAR, it looks like that's a thing of the past for various reasons.
 
Old Hippie said:
I never thought about that.

I thought there were BIOS capacity limitations because I remember (from a long time ago) some of my friends had to modify the BIOS to play some games.

I think they were removing some things to make room for something the game needed to be played?

This happened long before I was into computers.

I was into audiophile equipment at the time and wasn't paying attention to this new-fangled computer stuff. :)

AAR, it looks like that's a thing of the past for various reasons.
Click to expand...

The BIOS should not be confused with the autoexec.bat and config.sys files of the old days. What you are talking about is the 640k memory limit for DOS and by extension Windows 9x. Different problems though they do sound alike. Option ROMs from the BIOS and other firmware have to load into memory just like anything else. Unfortunately the space allocated for that is too small. It's a similar problem in broad terms but the main difference is that users could control what was loaded into memory with DOS and could run different configurations. Firmware and what, or how much is loaded isn't really up to us. we have very little control over integrated devices. Disabling them doesn't even mean that they are completely disabled. Sure Windows may no longer detect them, but they still initialize with the rest of the firmware and generally end up loading into that reserved OROM space. Things like LAN boot ROMs and to a lesser extent storage controllers we do have some control over, but again it's not always enough.

In order for this problem to be solved on a permanent or semi-permanent basis, BIOS and how it loads into memory has to change. UEFI doesn't seem to be the answer as many of the boards I've seen these issues with feature UEFI.
 
What you are talking about is the 640k memory limit for DOS and by extension Windows 9x.
Click to expand...
This is probably what I remember.

The were using a Hex Editor to do this.

I forget what I was trying to do but I also used a hex editor.....pretty scary in there. :)

I'm basically just a knowledge junkie and I really appreciate the education I get from this site and the people that participate.

Thanks for educating this Old Hippie!
 
Old Hippie said:
This is probably what I remember.

The were using a Hex Editor to do this.

I forget what I was trying to do but I also used a hex editor.....pretty scary in there. :)

I'm basically just a knowledge junkie and I really appreciate the education I get from this site and the people that participate.

Thanks for educating this Old Hippie!
Click to expand...

That was just edit you probably used. It's not actually a hex editor as I recall.
 
BIOS and UEFI can both handle as much space as the company releasing it wants to (within reasonable limits). If a motherboard manufacturer wanted us to be able to load lots of OROMs at once, they could certainly make it so. It's like how companies like Asus and EVGA had a limit in their code that prevented OROMs over 64KB from loading while other companies such as Gigabyte did not have that problem. That was a problem on Asus and EVGA (and maybe others) even for X58 boards, coming with IMR 8.0 and not allowing versions greater than 8.5 because 8.5 was the last one that was <= 64KB. And it wasn't very good for SSDs, and doesn't allow >2TB partitions to boot (need 10.5.0 or higher for that). SSDs were the main issue, so we consumers were able to successfully rally both Asus and EVGA to fix the problem in at least some of their boards. If they thought it worth it, they could just as easily give us more OROM space, but they probably see no reason to. Few of us will care about that, and perhaps it would even cannibalize some of their server chipset motherboard sales as certain people might be using desktop-grade equipment if it were possible. It's not going to drive away many customers, and they would have to pay engineers to develop the changes required, as well as go through a lengthy validation process. When they are unlikely to make any extra money from the idea, they are unlikely to bother. If we were somehow able to get a 'movement' going that told them that we want this problem fixed, they might do it. But that's not going to happen, and they will thus only fix it when it comes time that they have to - like when Intel Matrix RAID 12.0 OROM comes out and the thing is 5MB or something ridiculous, considering how much heft they keep adding.
 
dandragonrage said:
BIOS and UEFI can both handle as much space as the company releasing it wants to (within reasonable limits). If a motherboard manufacturer wanted us to be able to load lots of OROMs at once, they could certainly make it so. It's like how companies like Asus and EVGA had a limit in their code that prevented OROMs over 64KB from loading while other companies such as Gigabyte did not have that problem. That was a problem on Asus and EVGA (and maybe others) even for X58 boards, coming with IMR 8.0 and not allowing versions greater than 8.5 because 8.5 was the last one that was <= 64KB. And it wasn't very good for SSDs, and doesn't allow >2TB partitions to boot (need 10.5.0 or higher for that). SSDs were the main issue, so we consumers were able to successfully rally both Asus and EVGA to fix the problem in at least some of their boards. If they thought it worth it, they could just as easily give us more OROM space, but they probably see no reason to. Few of us will care about that, and perhaps it would even cannibalize some of their server chipset motherboard sales as certain people might be using desktop-grade equipment if it were possible. It's not going to drive away many customers, and they would have to pay engineers to develop the changes required, as well as go through a lengthy validation process. When they are unlikely to make any extra money from the idea, they are unlikely to bother. If we were somehow able to get a 'movement' going that told them that we want this problem fixed, they might do it. But that's not going to happen, and they will thus only fix it when it comes time that they have to - like when Intel Matrix RAID 12.0 OROM comes out and the thing is 5MB or something ridiculous, considering how much heft they keep adding.
Click to expand...

Check your facts. All the recent Gigabyte boards I've tested have insufficient OROM space to run more than one storage controller in RAID mode at once. In fact I spoke with one of their technical managers on the phone about the problem and he told me that the Z68 chipset specifically lacks support for the necessary amount of OROM space. Now, there may or may not be truth to that, but I've got no reason to doubt it. Furthermore, as I said before, the Gigabyte boards made now certainly have the limitation. I've also got boards from EVGA and ASUS and even DFI that do NOT have this problem either. All are X58 boards. So what you are saying simply doesn't pan out in the real world.
 
Dan_D said:
Check your facts. All the recent Gigabyte boards I've tested have insufficient OROM space to run more than one storage controller in RAID mode at once. In fact I spoke with one of their technical managers on the phone about the problem and he told me that the Z68 chipset specifically lacks support for the necessary amount of OROM space. Now, there may or may not be truth to that, but I've got no reason to doubt it. Furthermore, as I said before, the Gigabyte boards made now certainly have the limitation. I've also got boards from EVGA and ASUS and even DFI that do NOT have this problem either. All are X58 boards. So what you are saying simply doesn't pan out in the real world.
Click to expand...

I think you misunderstood what I was saying. I didn't say that Gigabyte has bypassed that particular limitation. I discussed a different limitation that was related. Basically what I said is that they could fix this limitation (well, there will always be SOME limitation, but they can make it not an issue) if they wanted to and that it's not inherent to the BIOS/UEFI design.
 
Last edited:
Perm said:
Well after another evening of playing, I'll response to this post with more info... hopefully to help others in the future.

First of all, after googling Asus P8Z68-V Pro and going through setup myself... it is clear that these SATA controllers are quirky. If you start a project build with one of these boards and can't immediately figure out why it won't boot... don't give up, it's probably not you, and the board probably isn't defective, it's just not intuitive.

I'll try to summarize my experience so this post doesn't turn into a novel (because I feel like it's going to!) :)

Hardware:
Mobo - Asus P8Z68-V Pro
Proc - Intel i7-2600K
RAM - Gskill - 4x4gb (16gb total)
SSD - Crucial M4 CT128M4SSD2CCA 2.5" 128GB SATA III
Platter drive - Western Digital - 1TB 7200 RPM 32MB Cache SATA
ATAPI/Optical drive - Lite On DVD R/W
Vid Card: ASUS GeForce GTX 560 Ti (Fermi) 1GB 256-bit GDDR5

snip :)
Click to expand...

To bring this back to its origin, I have the SAME motherboard/proc/SSD and JUST built my machine last night. I forgot about no IDE drives (old DVD drives) so I had to install my Win 7 x64 from a flash drive using WinToFlash and it worked great, 10 minute install. So you are saying I will have to likely reinstall once I flash the bios? Have not updated yet to newest.

I am ABOUT to start sticking another 4 platters (1 to 2TBs) and a SATA DVD drive in this machine.

Will it seem likely in my real-world situation that I will have troubles slapping that many drives down on this machine with the current SATA controllers?

Sounds like I'd better at least update the bios before I do though?
 
Yes, definitely update the BIOS. If you're saying that you forgot to enable RAID mode in the Intel controller then you're all set - RaidFix. Run that, enable RAID mode, reboot and then install the latest RST drivers. (Note that it will NOT prevent IDE mode from working - you'll still have that option.)
 
dandragonrage said:
Yes, definitely update the BIOS. If you're saying that you forgot to enable RAID mode in the Intel controller then you're all set - RaidFix. Run that, enable RAID mode, reboot and then install the latest RST drivers. (Note that it will NOT prevent IDE mode from working - you'll still have that option.)
Click to expand...

Just to be clear, I'm not going to RAID. I am just incrementally slapping drives in my rig for increased media storage as I fill it up. The stuff is all non-critical (I have that stuff backed up separately) so I'm not concerned with redundancy.

I just want to know if I hook up 4 more separate 1 to 2TB drives (I think 3 1TB and 1, maybe 2 more 2TB drives possibly) will it wreak havoc on my system.

One item to note though that was interesting - when I attached my eSATA 2TB drive, it made the system pause (mouse freeze) quite frequently. When I took it, I couldn't replicate. Issue there?
 
funny enough I have one of those cards. Way old and I'm sure not putting in a new build though.

Ran the 0606 bios, went fine with BIOS flash utility.

Took another poster's advice, trimmed file name to 8 letters and stuck on FAT32 flash inserted after BIOS load.

Worked like a charm.
 
You must log in or register to reply here.
Back
Top