Benchmarking the Latest Hardware is Fun, Unless... Part Two?

[Rob Williams]

From our front-page news:

Earlier this month, I posted a small rant about how benchmarking can be fun unless something goes wrong. I'm not sure what it is, but no matter what I do, or how hard I try to get on top of things, something is always destined to go wrong. This past weekend was no different! Once again, we planned for a busy week of content, ranging from motherboard reviews, to even a new CPU review, but alas, the poltergeist that sits in our lab won't let that happen easily.

As we received our copies of Windows 7 recently, I decided it would be a great idea to begin using it for our testing where able. Since we polished off a new methodology for our motherboards, I figured it'd be a great idea to begin using the OS there. So far, so good, and all the issues I've experienced are absolutely not related to the OS, which is a stark contrast with how things went down during the Vista launch.

So what problem could I have possibly run into? Well, to understand that, it may pay to check out our recent testing methodologies article (still a work-in-progress). Essentially, to make our lives easier we install the OS we're going to use, along with the applications we need, and then back up the entire thing as an Acronis backup, so that we can restore that same image each time we test a new motherboard, processor, graphics card, et cetera.

Of course, we don't install system drivers prior to making a backup, because that would cause issues down the road. Neither do we use an image on platforms it's not intended for. For example, if we create an image built on a P55 motherboard, we don't use it on anything except P55 motherboards. We've done this for quite a while, and haven't had a real problem up to this point.
​

<table border="0" align="center"> <tbody> <tr> <td>
Our Windows 7 Desktop for Motherboard-Testing </td> </tr> </tbody> </table>
Until this weekend, of course. I am not pointing fingers here, but the problem lies with our Gigabyte P55-UD5, and the issue comes down to AHCI. We have used AHCI mode for our S-ATA and ODDs for the past year or so, as it's faster and newer, but something about the Gigabyte board doesn't agree with the others. Since it's been the P55-UD5 that we began out our testing with, I decided to create the image on there.

The problem is this. After taking that image and restoring it to any other board with AHCI enabled, such as the ASUS P7P55D Pro or Intel DP55KG, Windows would blue-screen-of-death upon boot. After a lot of trial and error, I deemed this issue specific to Gigabyte's board. If I create an image on ASUS' or Intel's board, and restore it to either or, there's no problems. It all comes down to the P55-UD5, and how it handles AHCI.

Recently, Gigabyte introduced a feature called "Extreme HD" on their boards, which essentially overwrites AHCI - meaning, you will not see mention of AHCI in their BIOS'... just Extreme HD (or xHD). If you enable Extreme HD, it either means you're going for a RAID setup, or you simply want AHCI enabled. So my question is... what is it about Gigabyte's board that's causing issues between boards? This is not a real issue, or a fault of Gigabyte's (per se), as it's only specific to people who would ever want to move their Windows over to another machine, but since I've never experienced the issue before, I'm definitely a little stumped.

Any motherboard vendor has the option of using secondary HD controllers, but for the primary on the system, they use the S-ATA controller in the chipset, so I'm ruling out the possibility of it being a secondary controller that's causing an issue. Even then, I've restored images across many motherboards before without issue, which adds to this confusion. I'm in contact with Gigabyte regarding this, and I hope to hear back soon. If you have any idea what the problem could be, don't hesitate to shoot off your ideas in our thread!
​

 

[2Tired2Tango]

Any motherboard vendor has the option of using secondary HD controllers, but for the primary on the system, they use the S-ATA controller in the chipset, so I'm ruling out the possibility of it being a secondary controller that's causing an issue. Even then, I've restored images across many motherboards before without issue, which adds to this confusion. I'm in contact with Gigabyte regarding this, and I hope to hear back soon. If you have any idea what the problem could be, don't hesitate to shoot off your ideas in our thread!
[/INDENT]

Rob... can someone who's installed hundreds of motherboards and OSs offer you a tiny bit of advice here?

9 out of 10 times changing a motherboard will break a working system... You can have the same everything else, but changing the MOBO is suicidal OS wise.

Windows HAL drivers are selected at install time and will not change adaptively for new motherboards... ACPI, HAL and CPU code are not adaptive drivers... the result is that with any slight difference between motherboards and these core drivers end up broken. If the system can't access it's core hardware, it's dead in the water. BSOD and there you sit.

Also if the chipset is different by even revision numbers I've seen IDE and SATA fail on boot leaving you once again with a BSOD.

As I tried, falteringly, to explain before the problem is that your imaging technique is not adaptive. It can't look at the hardware and say "Oh... we need this" ... if the image, which is very rigid doesn't match the mother board's needs exactly, it's going to fail.

For many years, every time I change motherboards I end up re-installing the OS... it never misses.

This, of course, is only going to get worse with the ongoing proliferation of chipsets and features... the more things diverge, the worse it will get.

 

[Rob Williams]

9 out of 10 times changing a motherboard will break a working system... You can have the same everything else, but changing the MOBO is suicidal OS wise.

As I mentioned in the above news post, I have re-imaged these machines hundreds of times, and have even in the past (for personal testing) carried an OS from one motherboard to another with a completely different chipset, and still have this work. This is the <strong><em>first</em></strong> time I have ever tried to re-image that I've encountered a problem. I am not counting the times when I've gone from chipset to chipset to see what would break or not.

Windows HAL drivers are selected at install time and will not change adaptively for new motherboards... ACPI, HAL and CPU code are not adaptive drivers.

This is not the major issue you make it out to be. These motherboards are not going to change <em>that</em> much from one to another, especially when the same chipset is being used. As for different revisions of a chipset, that's a new one on me, because I've never known Intel to release a follow-up to their desktop chipsets (if I'm wrong, so be it).

As I tried, falteringly, to explain before the problem is that your imaging technique is not adaptive. It can't look at the hardware and say "Oh... we need this" ... if the image, which is very rigid doesn't match the mother board's needs exactly, it's going to fail.

It doesn't need to be adaptive. We're not installing the most important system drivers (chipset, LAN, audio, storage) until after the OS is restored. I'm not concerned about minor things like ACPI, nor have I ever had an issue where that or anything else is concerned.

 

[2Tired2Tango]

As I mentioned in the above news post, I have re-imaged these machines hundreds of times, and have even in the past (for personal testing) carried an OS from one motherboard to another with a completely different chipset, and still have this work.

It's not about sound or video... those are Plug and Play drivers that can be installed anytime after the initial install. It's about "text mode" drivers that have to be installed before the system can access it's busses... These drivers lay at the Hardware Abstraction Layer of the machine and have to be present even before Windows installer can begin copying files for the install. They are so crucial to the system they have to be loaded before the multi-tasker can even start.

These drivers are configured by the installer for a particular motherboard and will not follow changes in hardware...

It is a mistake to think that Gigabyte motherboards have the same underlying structure as Asus... even more true when you are talking AMD vs INTEL... look at the enormous differences in system structure between AMD's built in memory manager and Intel's high speed buss... You cannot reasonably expect to run the same HAL code on both...

And yes, ACPI is part of the HAL as is the PCI driver... These are text mode drivers that have to be working before the CPU can access any of it's IO structures... including disks, PCI, etc.

I'm glad you got away with this as long as you did... but it looks like it just caught up to you, Rob.

 

[Rob Williams]

I'm glad you got away with this as long as you did... but it looks like it just caught up to you, Rob.

That might be, but I'm still highly skeptical. After all, it's the Gigabyte board here that's proven to be the weak link, and they actually renamed AHCI in the BIOS. It seems, to me, that they did a little more than simple renaming, or else this is all just a major coincidence. As I mentioned, I can share the exact-same OS install between the ASUS and Intel boards no problem.

These drivers lay at the Hardware Abstraction Layer of the machine and have to be present even before Windows installer can begin copying files for the install. They are so crucial to the system they have to be loaded before the multi-tasker can even start.

As I have to manually install HAL each time I setup a Gentoo machine, I'm well-aware of what it is and how it functions. HAL is not the point. I have restored images created on one motherboard to many, and have not once ever had an issue. It's only been when I've tried using an OS created on one chipset and then use it on another when an issue would arise. Again, the latter example is for personal testing and intrigue - it's not something we'd do for our real testing.

Do I agree that fresh installs is the best course-of-action? Of course! In a perfect world, we'd do fresh installs on all of our hardware, but this isn't a perfect world, and I'd rather spend the hours it takes to install an OS and all its applications each time to more important things - like writing content. I'm not alone here. Interestingly enough, I used to use fresh installs for everything. It wasn't until a few colleagues from other websites clued me into the process of making images.

It is a mistake to think that Gigabyte motherboards have the same underlying structure as Asus... even more true when you are talking AMD vs INTEL... look at the enormous differences in system structure between AMD's built in memory manager and Intel's high speed buss... You cannot reasonably expect to run the same HAL code on both...

I didn't say that there was no difference in HAL code between different architectures, nor did I insinuate that I used the same install across all the different motherboards I use for testing. I made it clear that I'll never "mix and match" our images, and I'd never restore an image on a motherboard that features a different chipset than what I originally created it on. That chipset is the heart of the motherboard, plain and simple.

I split up my images based on chipset, since it's the easiest. So, I have one for P45 boards, P55 boards, X58 boards, AM2+ boards, AM3 boards and whatever else might come along. These five just happen to cover all the current architectures. Once again, and I know I sound like a broken record here, but between Acronis, and what we used to use, Norton Ghost, I've never had a single show-stopping issue like this.

 

[Psi*]

I have changed out failed m/bs and I sooo try to get as similar m/b as what I had. After a year or 2 you can never get the same board from the same manufacturer as they just do not exist or enough user knowledge finally exists on the net and they *all* have had the identical problem to your own! So, it would be nuts to get the identical obsolete m/b anyway! Who knew?

Having done this too many times, I will say that reusing the same installed OS is little different than OC-ing just a little bit too much ... you have a completely unreliable system. And for me when I have to wait for several hours to a few days for a solution ... ehhhh! ... I will always make a fresh install. PITA but less of a PITA.

 

[Rob Williams]

So... after even more trial and error, I figured out that the problem was rather simple. It was the BIOS.

As I mentioned before, Gigabyte recently took to renaming AHCI to "Extreme HD", and it was my hunch that there was more to the story. So, I created a brand-new image on the ASUS board, and booted back up on the Gigabyte with "Extreme HD" enabled. BSOD, as expected. So, I reverted to the BIOS that came on the board originally, where it was called AHCI (as it should be), and the OS booted just fine.

I'm not sure what Gigabyte did to that BIOS, but it just wasted three days of mine

 

[Rob Williams]

/me swallows some humble pie.

It turns out that this is not an issue with the Gigabyte board, but rather to do with the fact that I'm an idiot. You see... I'm not sure what got it into my head that Extreme HD = AHCI, but it turns out that there's more to it than that. Extreme HD = RAID, from what I can tell.

Because I had it in my head so far that Extreme HD = AHCI, I just chose it as an option and left it alone. Little did I notice the "PCH SATA Control Mode" option right below it... with AHCI as an option. I could NOT feel like a bigger idiot right now.

What stumped me more, is that when I installed the OS under "Extreme HD" mode, Intel's Matrix Storage Manager installed fine, and since I thought that that software would only install under AHCI mode... well, you get the idea.

No fault of Gigabyte's... all the fault of my own. I admit it.

 

[Psi*]

sooooooo ... whats your conclusion?

Driver-less images are not a bad thing? Loose nuts on keyboards are a continuing hazard? Or, maybe its the hours that you keep?

 

[Rob Williams]

It wasn't me who ever suggested that driver-less images were a bad thing. I've made my self very clear about those, and I'm more than confident in using them, regardless of what other people think. This issue didn't come down at all to the hardware between the boards, but the fact that I enabled a form of RAID rather than AHCI, without cluing in a lot sooner.

Or, maybe its the hours that you keep?

Hah, I wouldn't rule that out. Since last Friday, I've been hitting the sack way too late (5:00AM on average), so I'm definitely in a ridiculous schedule. Gotta snap out of it with IDF happening next week ;-)

 

[Kougar]

As usual, I tend to agree and disagree with both of y'all on various points.

I agree in almost all cases a user can't take an NVIDIA chipset install and migrate it to an Intel or AMD chipset. On the flipside if the chipset vendor is the same Windows Vista and Windows 7 will often be able to work just fine across various motherboards on a SATA drive... it can be extremely messy with XP and require the OS to reactivate itself, but it works fine.

XP is far more finicky, but I've goofed around with that OS too and had no issues migrating installs around similar Intel chipsets made in the last couple years. On the other hand Vista and Windows 7 both I've migrated between 965P, P31, P35, and X58 boards across both the same and different manufacturers, different PCB revisions, and different P35 chipset revisions. Using a SATA drive helps make this possible.

The best example I have is when I took the Windows 7 RC install from my X58-UD5 rig, and to verify a faulty motherboard wasn't behind a rash of problems I couldn't pin down I plugged the drive into a P35-DS4. Two reboots later all drivers and devices were recognized and installed, the OS reactivated, and in short order I determined the motherboard + GPU hardware was perfectly fine since the problems persisted on a completely different computer. I even used the system as normal over a period of a few days without an issue, beyond those I were troubleshooting to begin with. Amusingly I later put it back into my X58 rig and it reverted itself to the previous drivers without a problem (I don't remember it needing even a reboot, but my memory is fuzzy on that).

I am still using this OS as I type this, because I've not noticed any sort of driver morass that I expected to occur that would happen with XP. Of course I still have some of the original problems, but I now know they are OS level or program level software issues, and not my hardware nor my overclock.

I fully agree XP does have problems detecting low level hardware. Last I used it XP still couldn't even detect the low level SMBus driver to enable system audio on most Intel motherboards. Vista and Windows 7 both alleviated this problem and do actively search for new low level hardware buses. XP always requires the additional Universal Audio Architecture Bus driver. Windows 7 in particular displayed each new bus in the systray that it would find while it actively installed drivers for everything, and it found quite a few at that.

Windows HAL drivers are selected at install time and will not change adaptively for new motherboards... ACPI, HAL and CPU code are not adaptive drivers... the result is that with any slight difference between motherboards and these core drivers end up broken. If the system can't access it's core hardware, it's dead in the water. BSOD and there you sit.

Vista and Windows 7 removed some of the HAL layer (such as in regards to sound), but I don't know the full details beyond that. I am not sure but I presume part of the explanation is the HAL layer comes in several generalized flavors, and most modern PC's share the use of the same flavor today. http://windowsitpro.com/article/articleid/48583/what-is-the-hardware-abstraction-layer-hal.html

This, of course, is only going to get worse with the ongoing proliferation of chipsets and features... the more things diverge, the worse it will get.

I beg to disagree here. For whatever reason this has become less of an issue from my current experiments in abusing OS installs... Windows 7 is the most resilient OS I've used so far and takes this kind of abuse well (Ignoring the stupid activation issues)... at least with Intel chipsets. I honestly can't speak for NVIDIA or AMD because all the systems I've built or used have been Intel since the 865P line.

Also, more and more features are tied into the chipset, or use controllers from well known names such as Marvel, Realtek, and JMicron. Even when Windows 7 doesn't know of the driver it polls Microsoft and almost always finds it for a quick install. Windows 7 takes it a step further and actively hunts the network for manageable devices (NAS, router) and displays links to those, along with USB devices.

If moving from a native X58 install to a P35 motherboard, then back to the X58 board couldn't break Windows 7, then most Intel chipsets should be safe now. That is assuming the user isn't going to run out of OS reactivations, use a non-AHCI install on an AHCI board, or one of sevearl other showstoppers... Of course MSDN and RC/beta software both allow 10 system installs per key, so that at least helps.

 

[Rob Williams]

You raise a few good points, Kougar, and I should have pointed out some of the same... such as the fact that Vista and 7 are far more resilient when it comes to changing hardware than XP ever was. Still, changing from an Intel chipset to an NVIDIA chipset, as an example, <em>will</em> cause issues even in Vista (at least, in my experience).