ICH9R; RAID 5; cannot re-add drive to volume

Hi,

i cannot re-add the 3rd drive to my raid 5 volume after a crash. im very sad about it because i need data-redundancy (important data -.- cant afford to lose it)

Mainboard: GA-P35C-DS3R (ICH9R-chipset)
Storage: 3x SAMSUNG HD501LJ (500GB) @ RAID 5

the intel matrix storage manager gives me the following error when i klick "rebuild on selected drive":

Rebuild RAID Volume Wizard
The volume cannot be rebuilt to the selected hard drive due to one of the following reasons:
- The hard drive contains system files or is the system hard drive
- The hard drive is not large enough to be used for the rebuild action
- The hard drive has reported a SMART event
- The hard drive has reported a failure


to solve the problem...

- i did a lowlevel format on the "not anymore accepted drive" -> no systemdata etc on that drive -> NOT MY PROBLEM
- i checked the size: the "not anymore accepted drive" was in that array before the crash -> if it has not changed its size (and i realy belief that it did not), it cant be to small -> NOT MY PROBLEM
- i checked the SMART-status with speedFan -> all ok, no errors, no warnings -> NOT MY PROBLEM
- checked the raidBIOS -> drive is in "Non-Raid-Mode" and no errors or warnings at all -> NOT MY PROBLEM

so, what is the problem? i dont know what to do... plz help... *cry*

thanks in advice,
ic3

OMG I've just encountered a very similar problem and I'm at my wits end. Seems like intel RAID marks the drive somewhere so it knows that the drive has been used in the array before but for some reason got broken. Like ic3f1re I've done all the low lvl diagnostics even clearing the mbr/bootcode sectors of the drive. I've had to get another harddrive and the intel raid console happily rebuilt the array with the new drive.

I know the rebuild works in some cases as I've a friend who was pulling in and out one of his hd's to use as a temp storage. For his system, the intel bios did detect when the drive was put back and automatically started the rebuild, and on another occasion he manually used the console to begin the rebuilding process, all performed on the same array / harddrives.

I've got a feeling we're missing something about the "broken" drive...

System Information

Kit Installed: 7.8.0.1012
Kit Install History: 7.8.0.1012
Shell Version: 7.8.0.1013

OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 2 Build 2600
System Name: MAGICAL3
System Manufacturer: Gigabyte Technology Co., Ltd.
System Model: P35-DS3R
Processor: Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz
BIOS Version/Date: Award Software International, Inc. F11, 01/04/2008

Language: ENU



Intel(R) RAID Technology

Intel RAID Controller: Intel(R) ICH8R/ICH9R SATA RAID Controller
Number of Serial ATA ports: 6

RAID Option ROM Version: 7.5.0.1017
Driver Version: 7.8.0.1012
RAID Plug-In Version: 7.8.0.1013
Language Resource Version of the RAID Plug-In: 7.8.0.1013
Create Volume Wizard Version: 7.8.0.1013
Language Resource Version of the Create Volume Wizard: 7.8.0.1013
Create Volume from Existing Hard Drive Wizard Version: 7.8.0.1013
Language Resource Version of the Create Volume from Existing Hard Drive Wizard: 7.8.0.1013
Modify Volume Wizard Version: 7.8.0.1013
Language Resource Version of the Modify Volume Wizard: 7.8.0.1013
Delete Volume Wizard Version: 7.8.0.1013
Language Resource Version of the Delete Volume Wizard: 7.8.0.1013
ISDI Library Version: 7.8.0.1013
Event Monitor User Notification Tool Version: 7.8.0.1013
Language Resource Version of the Event Monitor User Notification Tool: 7.8.0.1013
Event Monitor Version: 7.8.0.1013

Array_0000
Status: No active migration(s)
Hard Drive Write Cache Enabled: Yes
Size: 1192.3 GB
Free Space: 0 GB
Number of Hard Drives: 4
Hard Drive Member 1: Hitachi HDT725032VLA360
Hard Drive Member 2: Hitachi HDT725032VLA360
Hard Drive Member 3: Hitachi HDT725032VLA360
Hard Drive Member 4: Missing hard drive
Number of Volumes: 1
Volume Member 1: Data

Data
Status: Degraded
System Volume: No
Volume Write-Back Cache Enabled: Yes
RAID Level: RAID 5 (striping with parity)
Strip Size: 64 KB
Size: 894.1 GB
Physical Sector Size: 512 Bytes
Logical Sector Size: 512 Bytes
Number of Hard Drives: 4
Hard Drive Member 1: Hitachi HDT725032VLA360
Hard Drive Member 2: Hitachi HDT725032VLA360
Hard Drive Member 3: Hitachi HDT725032VLA360
Hard Drive Member 4: Missing hard drive
Parent Array: Array_0000

Hard Drive 0
Usage: Non-RAID hard drive
Status: Normal
Device Port: 0
Device Port Location: Internal
Current Serial ATA Transfer Mode: Generation 2
Model: Hitachi HDT725032VLA360
Serial Number: VFM201R81PAJVN
Firmware: V54OA7EA
Native Command Queuing Support: Yes
System Hard Drive: No
Size: 298 GB
Physical Sector Size: 512 Bytes
Logical Sector Size: 512 Bytes

Hard Drive 1
Usage: Array member
Status: Normal
Device Port: 1
Device Port Location: Internal
Current Serial ATA Transfer Mode: Generation 2
Model: Hitachi HDT725032VLA360
Serial Number: VFM201R81JXTWN
Firmware: V54OA7EA
Native Command Queuing Support: Yes
Hard Drive Write Cache Enabled: Yes
Size: 298 GB
Physical Sector Size: 512 Bytes
Logical Sector Size: 512 Bytes
Number of Volumes: 1
Volume Member 1: Data
Parent Array: Array_0000

Hard Drive 2
Usage: Array member
Status: Normal
Device Port: 2
Device Port Location: Internal
Current Serial ATA Transfer Mode: Generation 2
Model: Hitachi HDT725032VLA360
Serial Number: VFM201R818297N
Firmware: V54OA7EA
Native Command Queuing Support: Yes
Hard Drive Write Cache Enabled: Yes
Size: 298 GB
Physical Sector Size: 512 Bytes
Logical Sector Size: 512 Bytes
Number of Volumes: 1
Volume Member 1: Data
Parent Array: Array_0000

Hard Drive 3
Usage: Array member
Status: Normal
Device Port: 3
Device Port Location: Internal
Current Serial ATA Transfer Mode: Generation 2
Model: Hitachi HDT725032VLA360
Serial Number: VFM201R81K8HVN
Firmware: V54OA7EA
Native Command Queuing Support: Yes
Hard Drive Write Cache Enabled: Yes
Size: 298 GB
Physical Sector Size: 512 Bytes
Logical Sector Size: 512 Bytes
Number of Volumes: 1
Volume Member 1: Data
Parent Array: Array_0000

Hard Drive 4
Status: Missing

Unused Port 0
Device Port: 4
Device Port Location: Internal

Unused Port 1
Device Port: 5
Device Port Location: Internal

I don't run RAID5, but throughout all my reading on various websites everyday, I've come too understand that once a drive is reported "bad", then it's marked somehow so that you cannot use the drive in your RAID5 again to help prevent data loss. Maybe your S.M.A.R.T. shows everything ok now, but maybe when if first dropped out it reported an error and that's when it was "marked" "bad". What HDD's do you have (brand/model)? Maybe you'll have to buy another one, it should work fine then. Anything as large or larger than the other 2 (or more) drives working in the RAID5 will work, but hopefully you'll get the same model.

Maybe search around about this "marking" of the drives to see if you can undo it somehow. That is, if you really trust that the drive is ok, then go ahead and try and use it again. Good luck, keep me posted, I'm curious as how to fix this.

Interesting...

Were you able to try this yet?

Good point. When the Intel Matrix Storage Manager determines that a disk is failed, it will mark the state as "Failed." You can tell it to unmark it as failed by right-clicking on a failed disk and select "Mark as Normal." This will tell the driver to unset that failed bit and treat the disk as healthy again.

While this may have caused the initial RAID degradation above, it does not appear to be the reason you can't re-build. Please note in the attached system report that Hard Drive 0 is not marked as failed. It is possible that it was failed, and the user already marked the disk as normal.

If you do use one of those tools, if it will report the actual drive size (not partition size) with a precision of bytes or kilobytes (greater precision than MB), could you please report that number here as well?

gwolfman,

Re-read my post. If any internal error correction goes on within a healthy single drive - which does occur to prolong the life of a drive - it will take longer than the controller will allow before the controller forces it out of the array. RAID-0 configurations would therefore be especially vulnerable because, as you know, if a drive drops out, for whatever reason, you've lost your stripe.

So, the fact that you've been running over a year without any problem doesn't diminish the fact that you are unnecessarily at risk. At risk because you could lose it all when a healthy drive, undergoing a normal internal process, drops out.

Im having the same issue. I actually had to disable raid to get memtest86+ to run, and when it was re-enabled, one of the disks was 'non-raid member', and raid has a missing member and is marked as degraded. I do not get a rebuild raid option.

The disk is already marked as a non-raid member so resetting it in ROM interface is not an option.
I don't quiet understand workaround 2 - the raid is my system drive....???

by console, do you mean the raid bios, or intel console in windows? if you power down the raid, how do you get into the intel console assuming that your raid drives are your system drives as well

I meant the intel console in windows. I didn't mess with any settings in the raid bios. The way my system is set up is the raid acts as a big storage drive. No system files (other than raid specific) are stored on it. The system drive I use is a standard 150 gig hard drive which is not associated the raid at all.

The raid carriage I have lets me individually power on each drive (if needed). Not too sure how common this is in most carriages but this allowed me to fix the problem I was encountering in my first post.

Im having the same problem. my 4x Raptors are in RAID 5 with the OS and everything (games, photos). I have an old Mobo with only 4 ports. I cant rebuild the system in the BIOS. Anyone, please, correct me if Im wrong:

1) RAID can only be repaired at Windows, never at BIOS.
2) Doesnt mattter wich RAID you use, make sure to have a spare HD with an OS for you to boot in case things go badly. Even HDs built for RAID like the NS and YS may fail for some unexpected reason.

My next system will be just 1 Raptor with the OS and games + 2x 1TB RAID certified drives in RAID 1 for important stuff. This will give me all storage I need and safety. It wont be as fast, but Ill be able to relax and enjoy my PC.

RAID needs to be improved. In fact, there is an article saying that RAID will be dangerous in the future, as HD capacity increases, so does the probability of error during reconstruction of a failed arry, therfore making RAIDs impossibe to repair if you have a 999999999TB HD, wich will happen someday in the future.

I like SATA RAID5. After changing motherboards, the RAID5 was seen and functional without needing addtional word. The Intel Matrix Storage Manager is very simplified, but seems to work well. When a drive failed, just replaced with a new drive and the array was automatically rebuilt. When another drive failed, just formatted it, marked it as normal, then the array was rebuilt.
Yes, RAID 5 has problems, but it's a whole lot better than nothing for rebuilding data.
just my 2 cents worth.

Oh my god, thank you ptr727 for posting this up. I recently setup my X58 i7 with 4 500gb Seagates in RAID10
Unknowingly updated my bios for better stability and whamo! the first disk of the raid dropped out.

Now ive gone about things a little differently then you. I'm back in the operating system with disk 2+3+4 but disk one is out of action and not allowing me to use it for the rebuild, even after using diskpart and 'cleaning' the disk information.

What I did to get back into the OS, was I unplugged the dropped disk, inserted my vista cd and allowed it to write the Vista Ultimate... (repaired) bcd. that got me around the Winload.exe problem, the bsod i got before the winload problem
I was baffled why the OROM or the Intel software wouldn't allow me to rebuild the array.

So all i need to do is unplug all but the dropped one and it will allow me to mark as spare in the OROM?
Wont all the remaining 3 get marked as Missing? will that fix itself when I plug them back in after?

I'm concerned I'm going to ruin it further. however i will follow your steps bit by bit to ensure I can boot again from it as long as it doesn't all go down hill on me. and Hopefully I can reuse the disk since its not bad, its a nasty flaw in the software which I think Intel should be working with motherboard manufactures to correct as it is integrated RAID.

Thanks again ptr727 for posting your raid 10 solution, it will prove a data saver for me
Thanks TH & all the Posters who have contributed to this thread, this issue is a real doozie.

the method i used was like this;
I detached all 4 or my raid 10 disks.

plugged in two non raid standard disks from an old computer.
kept the motherboard bios in raid mode, and then installed windows onto one of the two non raid disks from the old computer. (the data on it didnt matter to me)
Installed the matrix storage manager on the new windows.
shutdown, added the one failed raid disk to the other two new disks.
started up and loaded the Matrix storage manager.
right clicked the failed disk and got to choose mark as spare.

dont setup the windows onto the failed disk, set it up on a disk that is not part of your raid array. then you 'spare' the failed disk with that install, then your done with that install. you go back to rebuilding your array with its remains after you get the disk spare.

perhaps someone could explain it better. but the method does work, it might be a PITA and you'll prolly never bios update again on a raid system because of it, but at least its repairable.

I have a somewhat similar problem at the moment. I also have a Raid 10 array with 4 150GB Raptors and one of them was reported as failed. I have not had any problem booting into XP except when I relocated the "Failed" disk to a JMicron port and booting up would stall at the XP splash screen. I am using an ASUS P5B Deluxe with ICH8R.

To save anyone else from a possible heart attack or crapping your pants, don't do what I tried. Within Windows using the Intel Matrix Storage program, I selected the "Mark drive as normal" to see if this would fix anything. When I did this, the entire PC froze. I mean the entire system - nothing worked including putting Caps on or Num Lock. After a few minutes, it came back alive for a few seconds and then froze again. During this, I was freakin out. After another few minutes, it came back alive and the "Failed" drive was marked as missing. Now, in the Intel Raid BIOS, it shows the bad drive as a SMART event.

I have tried everything to see if the WD Diagnostics program could check the drive but nothing works. When booting to the DOS disk of the WD tool, it says No Drives exist. What friggin crap.

I now figure the drive is actually dead. Lets hope that WD sends me a Velociraptor for my replacement as they did for another member here.

PS The default TLER has not been changed.

Sub mesa, I actually did try and set the BIOS to IDE mode and then booted to the DOS disk and it still said there were no drives. Great minds think alike

I had a similar problem and today i managed to resolve it as follows:

Intel ICHR-9, Raid 5 with 3 drives.

Port 0 Drive failed, so it was kicked out from raid volume.

After try with intel matrix raid manager to put the disk back, it refuses to restore the volume.
The disk was detected from non-raid member to 'spare' if i tried to restore the volume.
Intel bios utility does not help in any way.

Well, the problem was that Intel Matrix or maybe Ichr9 bios, had set a little HPA (Host Protected Area) active on the kicked disk.
So the disk had one megabyte less than before.

To resolve this you need to disable HPA with some program like HDAT2. After that, the disk is detected as offline-raid member,
and you can start a successfull restore of your raid volume.

I hope this help.

Really, isn't it just the meta-sector that you need to wipe from the "broken" disk?

For example, you could also boot to ubuntu livecd (doesn't require any installation) and overwrite the last sector of that drive, with a dd-command in a terminal. That would wipe the (stale) RAID config data which is probably what is the curlpit. Since its only 512 bytes its also much faster than a complete zero-write.

A windows "format" (even a full format) doesn't actually write zeroes to all sectors, just the beginning (first 20MB or so). The rest is just reading the sectors, but not zero-writing them. Thus a windows format would not work in this case.

After the drive looses its last sector with RAID config data, the RAID engine won't know this disk and will mark it as free/unused.

After pulling whats left of my hair out trying to find a solution to my problem, I found this thread. Wow! Great information - sure glad I found it:

I am running 4 - Seagate 500 Gigs in a RAID 10. Over the past few months or so it has started to give me problems with one drive. I would get a BSOD pegging the Iastor.sys file as the culprit. On reboot, my RAID setup entered the Rebuild array state and would do so.

After having this happen about 10 times in 3 months, the drive was reported as an offline member. Try as I might I could not get it back online. That is, until I read this thread.

I have spent countless hours playing around with my system to try and figure it out. Updating the drivers to the latest version did nothing. At one point, I tried to determine which one of my 6 SATA connectors was Port 0, the offending one. Well, I figured wrong and unplugged the wrong drive! Now I couldn't even boot my system. It then reported 3 of my 4 drives as offline. Oh crap! My data!!!! After much effort and experimenting, I found an easy way to tell which port is hooked to which drive. Reading the info on the RAID setup gives the serial numbers of the drives on the 4 ports. So then it was a matter of pulling the drives out, reading the serial numbers and going from there.

I got my system back up and running on 3 drives again by unplugging the one originally reported as Offline. Windows reports this drive as "Misssing"

After I found this thread, I right clicked on the offending drive and was able to set it to a non-raid disk. After doing that I was able to right click again and select rebuild array to this disk. That is what it is doing right now. With over 600 gigs of stuff, it takes a while.

Now my only concern is that this drive may be going south and perhaps that is the reason it was "marked" in the first place.

Bottom line here is, thank you to all who have posted in this thread for the last 21 months or so. This information has been very valuable to me.

BTW, I am running the RAID 10 on an Asus Maximus Extreme board, liquid cooled, dual video cards, and all the other good stuff.

Disks with TLER drop even sooner out of the array; they just give up and report a bad sector. RAID driver hears about bad sector.. and kicks the drive out of the array.

TLER is usefull to make server systems with RAID not 'stall' or 'freeze' whenever an HDD is not working properly. Its a "do or die" setting; either work a 100% or you'll be kicked out of the array really soon. No mercy! TLER is not useful for consumers.

Also, consumer disks like WD Green do support TLER; its just disabled by default because consumers have little need for this feature. So you don't need any "RAID edition" disks; i've used countless desktop-class HDDs in RAID, although i use more advanced software RAID instead of all the onboard RAID windows-only drivers.

Advanced RAID software: BSD geom raid drivers, md-raid and/or ZFS i would consider advanced RAID. Unfortunately windows does not offer any advanced RAID.

TLER = Time-Limited Error Recovery, basically the feature many people are using to say you should get RAID edition disks and not 'normal disks'. This statement can be untrue for two reasons:
1) normal disks sometimes have TLER too, but disabled by default. For example WD Green disks.
2) consumers should not need TLER and it might even harm them. TLER is for servers not for desktop systems.

TLER also won't prevent disks from dropping out of the array. TLER will even make this happen more quickly than disks without TLER. So this is a misconception to what TLER is useful. Its useful for VERY IMPORTANT servers who cannot permit even half a minute to not work or be frozen. If one disk even scratches its bum, they want to kick out that disk and throw in the waste bin, and drop in any of their 200 replacements disks lying on the shelves. This is what TLER is useful for.