I am having the exact same problem after every hard reset / loss of power etc. The 4th drive in my RAID 10 always comes up as failed. I reset the drive and the system rebuilds the RAID.
The same thing happens to a new machine I built with P8H67-M LE and 2 x WD2002FAEX (Black) SATA3 drives.
Only it happens every cold boot, have not had to do a hard reset yet.
Message was edited by: Paul Casali, correcting HDD model number
I ma having a similar problem with an Asus P8H67-M LX board. After a hard reset, the intitial RST Option ROM info screen shows one of the drives in my RAID-5 volume as missing (and always the first port in the array, no matter which port I choose) and the volume shows as degraded. Then, if I Ctrl-I into the configuration menu, the missing drive is back at the bottom of the list, and the drives are in rebuild status. I;ve tried all the drives with different cables and connected to different ports and drives; it is definitely a controller issue.
I did some more tinkering and found that a RAID-0 volume will do something similar in that it will also show a drive as missing on a hard reset, and report the volume as failed on the initial info screen, but then when I go into the configuration menu itself, the drive is back and reports as normal. I also found that in any configuration the missing drive will show up on the info screen again if I cycle from "Force BIOS" to "Keep Current" and back again in the BIOS menu, but any volume with redundancy will still be in rebuild status; however, RAID-0 will report as normal in both screens after this.
I get the feeling this is some sort of bug in the option ROM in that the the ROM initially reads one drive as missing, but later decides that it is indeed present. I'm with Mr. Casali on this one; I think an ROM update to a newer version could possibly fix it. However, ASUS is most likely responsible for providing a BIOS update. I imagine ASUS can easily get their hands on the code from Intel and are simply behind in addind the newer Option ROM into an updated BIOS for release.
i'm a bit in late and with a very strong headache (and two nights passed wout to sleep) due to the same problem... but i could find the solution!
My array, any array, results degraded after a cold reboot (hard reset)... and almost always the first drive (not a drive in particular but always the one connected to the first sata port)... but entering IRST config menu the hard drive came back! ****!
The problem is the boot up of the mainboard is too fast and the IRST boot rom is inovoked too early when the disks r not fully spinned up (i'm using 4 big Hitachi 3TB) and so not ready yet to be detected by IRST... Here is the reason that always the disk, connected to the first SATA port, is missed... cause it's the first one (in time) attempting to be detected by IRST... It's also the reason that rebooting the machine wout turning it off it doesn't give any problem (yes, of course, all the drives r already ready!)
Now how to workaround the problem?
Sure it would be better to ask ASUS to increase the delay in the invoking IRST boot rom or at least to put an option in bios to set this delay. Ok, it's already present in bios a delay for post screen (settable in seconds) but it's referred to the second post screen, the one that appears after IRST boot rom (already too late!)
Here how i could workaround the problem:
1) Insert any additional controller raid card (even cheap) in any slot. The rom of this additional controller will be invoked before than IRST boot rom, giving the time to the disks to spin up fully and to be ready when IRST attempts to detect them.
2) In alternative u can set up the USER password in BIOS. Doing so, when u turn on the pc, the password will be prompted u first. So just the time to type the password and all ur disks will be already ready to be detected by IRST.
Try to believe!
Milan - Italy
Brilliant Ottavio, grazie! I had theorized that the Option ROM was somehow loading too early and causing problems, but I didn't put it together and come up with a probable solution like you did. Bravissimo! I can confirm that setting a user password works.
Now if only Intel can fix their option ROM so it waits for a few milliseconds before assuming that the drives are missing, or ASUS can update their BIOS so it delays the ROM from loading too early as you suggested.
Ottavio, great job! Really great job!
But as for my problem is that PC using as a "server" without operator assistance. And i already has no free slots to add any other card
Now I'm not shure that problem is really in ASUS BIOS delay not in RST OROM itself. I'll try to ask ASUS about this. Maybe, if the problem in OROM, the version 10.6 of it can fix this bug, i don't know
Thanks a lot! But i was also a bit lucky. I could ustand when - after almost one hundred time i deleted and recreated the array - i turned off and then immediately on the pc so fast that the array resulted not degraded... i asked myself "why this time not degraded?!" Then i had a flash! Sure the disks were not spinned down totally and they needed less time to spin up and to be ready again!
Now i'm really full of work in this period but i will try to submit the problem to asus techincal support a.s.a.p.
Happy that it could work for u too
p.s. Where do u live?
Yes, of course, the best thing it would be Asus could fix the bug.
Anyway now u know the cause and u can try to workaround the problem in some way.
For example try to put dvd-rom or maybe a spare disk or another non raid disk to a lower numbered port so the time to detect it will be enough for the array's disks to come up ready.
I already tried to connect an internal usb card-reader. Usually they introduce a delay in the bios post screen. But it doesn't work, cause it's detected after IRST bios rom post screen.
Now i'm a bit full of work but i'll try to submit the problem to the ASUS technical support as soon as possible.
Thanks for ur feedback.
I've alreay submitted it to ASUS Tech Support. I had an outstanding ticket open (they even sent me a beta BIOS with the newest OROM, which didn't work either). Hopefully, they will post a BIOS fix to correct the issue. I'll post back here if I hear anything.
I live on the extreme east coast of Canada, in St. John's, NL.
Thank you for your advices. Unfortunately, my 1st and 2nd SATA ports are only 6Gb/s ports on the board and my set of 2 WDC Green 3Tb drives is also SATAIII. That was the primary target of chosing this ASUS board for the SOHO "server"
As for testing, I've ordered set of WD RE drives to change WDC Green in RAID, so soonely I can test the "RAID-ready" drives with this RST and send a reply
Today I've got very intresting update about this bug. Looks like it also depends on HDDs
I've tried to use 2 "old-style" HDDs Seagate Barracuda ES (ST3320620NS, RAID-ready) in RAID-1. It seems fine, no bug! This RAID was tested in both types of SATA ports (3Gb/s and 6Gb/s) and everything is good...
So it looks like we have some kind of incompatibility: BIOS try to boot-up system as fast as possible and HDDs going to spin-up very slowly to save a lot of power (Hello, Greenpeace!)
But the theory must be proofed with 2 defferent ways, so I'm still waiting for my order of WD RE4 drives
Thanks! I hope ASUS will fix the problem very soon cause i'm in hurry to deliver this server to the customer. I should deliver it already 2 weeks ago :-/
I've also submitted the problem to ASUS today... just to shake them a bit!
Nice and interesting region u live! It's a pity it's so far to reach... We could enjoy one beer!
I've never been in Canada but i would like to come one day... but always no time!
Yes, sure... it's also depends on the hard disks...
These big hard disks have a high numbers of disks inside that need to spin up till 7200rpm. Also the recents low power consumption rules force the manufacturers to use not so strong spin motors and it causes the slowness of these disks. Maybe using RE WD disks u can workaorund the problem.
As for me I hope ASUS will fix the problem asap cause i cannot change my 4 hard disks and i would like to take out the user pwd from bios.
Waiting for news by ASUS, my best regards. Thanks, Ottavio.