The Troubled Sandy Bridge Platform – Error Codes 0D, 62, 94, D2
UPDATE: I get a lot of mail and links for this article. I thought, I should post an update to this article. After I originally published this article, ASUS rolled out a lot of bios updates for the P67 motherboard. After the recent bios upgrades, I do not face this issue anymore. The bios posts fine in all cases and I can use my USB slots in all configurations. If you face this issue and the solution in this article doesn’t help, try upgrading or downgrading your bios
The Sandy Bridge platform has seen quite a lot of down hill turns in his short life time. First the Cougar Point issue, then a series of Processor and Motherboard delays, and the P67/Z68 Fiasco and the failed attempt to keep the platform up to date with bios and driver releases. Of course, the third party manufacturers like ASUS, Gigabyte and MSI have their share of bad support for the platform as well but it’s mainly Intel that’s to blame. People have faced so many issues on the Sandy Bridge platform that it feels flaky at best. I just wonder my PC would shutdown any moment. It’s happened to me and a lot of other people.
Apart from many of the “bigger” and “widespread” issues with the Sandy Platform, like the one I blogged about some time ago, there has been another issue that’s been plaguing the users of Sandy Motherboards. The issue has something to do with no POST on cold boot and the following error codes:
0C-0D – Reserved for future AMI SEC Error codes
62 – Installation of the PCH Runtime Services
94 – PCI Bus Enumeration has started
D2 – PCH Initialization Error
There is no detailed information about these error codes in the manuals or the AMI website. I picked those definitions up from my P67 manual. I believe it should be the same for all Sandy Bridge motherboards with EFI bioses. Let me go through the error for reminder’s sake:
On a cold boot, your monitor will not show any display and your motherboard won’t POST. If you have the internal speaker attached to your motherboard, you will hear beeps about those error codes as well. However, the error is specifically noticeable when you look at your motherboard physically. The following signs should tell you what’s going on
1. Your VGA LED next to your PCIExpress x 16 slot is constantly lit.
2. If your motherboard has Q Code or Debug Code LEDs on it, you will see it either stuck at 0D, 62 or 94 or in rare cases at D2
3. Your Motherboard boot LEDs might be constantly lit as well.
If you’ve seen any of the above symptoms, you may have scoured the internet for a solution. The issue happens to be more frequent in ASUS motherboards. People on the internet have exchanged their motherboards in hopes to kill the error, and some have been successful after an exchange but others have been unlucky. Some have pointed out that it’s because the PCI Bridge is dead/corrupted or damaged.
Some people have shifted from their primary PciExpress x 16 slots to their secondary slots x8 and the issue seems to go away. However, it has returned for some in that case as well. This is very frustrating if you’ve hit the issue.
Somehow, I was not satisfied with the sudden notion that the hardware went bad just like that. So, I searched myself and found all the same results and then I turned back to the motherboard manual and datasheets from the manufacturers themselves. I found this:
The Image tells us that the PCIExpress x 16 slot shares IRQs with other components on the motherboard. This sounds exactly like where it’s going. An IRQ conflict/sharing issue. I went to the ASUS motherboard pages to verify if the components shared bandwidth as well and I found this for the P8P67/P8Z68 Pro:
*1: The PCIe x16_3 slot shares bandwidth with PCIe x1_1 slot, PCIe x1_2 slot, USB3_34 and ESATA12. The PCIe x16_3 runs at x1 mode by default for system resource optimization.(PCIe x1_2 will be disabled.)
The above note is only mentioned in the P8P67 Pro and lower models and the Deluxe/Extreme models do not have this note displayed. I can’t say if it is only for marketing but perhaps the upper models share bandwidth with the components as well.
Why, you ask? Because I solved the issue by disconnecting the USB3_34 Front Panel slots that share bandwidth with the PCIExpress x 16 slot. I have disconnected, reconnected, changed Graphic cards and slots to test my motherboard and it keeps working with the above solution.
This is strange and is possibly a fault in the BIOS. I recommend you to not upgrade to the Beta bioses posted by ASUS and other manufacturers. These bioses might damage your system because they threw the QA garbage over to the customers.
I’d be glad to know if this works out for any of you. It’s a detailed post, I know but I like to detail what caused the issue in the first place.
© 2016 Most of the work on this site is mine, ask before using. Thanks. –