I was adding a new drive to my system which I've done several times with no problems.  The array was not coming online in the usual amount of time so I thought the new drive might be bad.  I removed it and tried to start the array again and had the same issue.  It had been working fine for for several months before.  I can eventually get to the web admin interface and it shows all of the disks as missing.  The syslog (attached) shows a problem with ata8 (COMRESET failed) but I'm not sure exactly what that means.  Is it a problem with one of disks?  The SATA card?  Any ideas?

 

Thanks!

About 90% of the time this type of thing is a connection problem between the computer and the hard disk.  Usually a cable or a connection inside a backplane.

About 90% of the time this type of thing is a connection problem between the computer and the hard disk.  Usually a cable or a connection inside a backplane.

Since all of the disks are missing, you might try re-seating the SATA controller card.  Use a anti-static writs strap when handling the cards, drives, and cables.  This time of year the air indoors is very dry and static electricity discharge damage is very common.  You do not have to feel the discharge for it to cause damage.

 

Google "Wrist Strap ESD" to learn more.

 

Joe L.

Thanks for the suggestion, but it didn't work.  I re-seated the cards and checked all of the SATA cable connections to both the controller cards and the backplane.  I also made sure all of the drives are securely connected.  I hooked up a monitor and watched the boot process.  After the Promise SATA card does it's drive detection, I get an error that says 'Warning - The BIOS does not find proper hardware configuration, Please check your system again'  It hangs there for several minutes and then goes on through the Unraid boot process.  Any other possibilities?

If the BIOS does not recognize the drives properly, unRAID doesn't have a chance.

 

Have you looked for a motherboard BIOS update?

 

You might try resetting default BIOS settings and then reapplying your customized settings.

 

In BIOS, disable any special stuff you're not using (parallel ports, serial ports, sound cards, etc.)

 

Put drives in AHCI mode (versus IDE or RAID mode).  If AHCI doesn't work, you can try IDE mode (but not RAID mode).

 

 

You have unfortunately an unusual problem.  One failing drive or port hung the drive identification and setup so long, over 3 minutes, that when unRAID checked the Device Inventory, after waiting almost a minute, not one drive had been registered, so they all looked like they were missing.  The 8 other drives did finally get registered, and if unRAID had rechecked, would have found them.

 

Here is what happened:  you booted at 7:48:28, and the kernel got as far as identifying the drive controllers and hard drives.  It found a SiI3132 (or comparable) controller (ata1, ata2) and a Promise controller (ata3, ata4, ata5, ata6), but neither had drives connected, so continued on to the second Promise controller (ata7, ata8, ata9, ata10).  It identified a drive on ata7, then tried to identify whatever was connected to ata8, and here's where everything hangs.  It seems to know there is something there, but can't connect to it or identify it, so it begins a long process of resets and waits, over 3 minutes, to 7:51:42, before finally giving up and moving on to the rest of the drives.  It then finds the third drive on ata9 on that Promise card, then locates the rest of the drives on the motherboard, 8 in all.  But this was 2.5 minutes *after* the unRAID modules had looked for them, and had written them off.

 

There were numerous error flags reported on ata8, some I've never seen before, and even hotplug issues reported.  I would check for bad or loose cabling, improperly seated drive in backplane, not sure what else, possibly bad drive, possibly bad port or Promise card.  I can't identify the missing drive, but the 2 good drives that were identified on the Promise card are Seagates, a 1TB and a 1.5TB.  If the ports are in pairs, then this ata8 drive is paired with the 1TB drive.

 

By the way, you have 2 fast SATA ports, probably on a SiI3132 chipset, that are unused.  I would move 2 drives that are currently connected to the Promise card over to those 2 ports.  That would also move them off the PCI bus.

My use of the term 'registered' is not technically correct, and there may be other technically inaccurate statements and terminology in my comments above.  My terms, above and below, should be considered at best 'analogous' to the correct terms.

 

What appears to happen in the kernel's drive identification and setup phase, is in several steps.  That is, the kernel finds a controller, such as the Promise one, and then identifies all of the drives attached, one by one, then goes back and begins setting them up and assigning device ID's to them, which is the part analogous to 'registering' them.  Only when they get their device ID (eg. sdf, hda), are they visible and available to the system.  That is why the kernel identified a drive on ata7 at 7:48:28, but it was not set up until it had finished checking ata8 (bad), ata9 (good 1.5TB), and ata10 (empty), 3 minutes later (7:51:42).  unRAID checked the Device Inventory at 7:49:24.

Thanks for the detailed analysis.  It was a failed drive.  I physically removed all of the drives on the SATA controller card and everything started normally (obviously, had missing drives, but none of the other start-up errors).  Added the drives back one by one until I found the bad one.  The odd thing is that everything was working normally...no errors, no problems whatsoever.  Is there anyway to identify when something like this is happening?  I run a parity check once a month and the last one in December showed no problems.

 

Thanks again for the help!

Are you sure this drive is bad, that the problem is not the controller card?  Have you hooked the drive up to an unused port on a different controller?

 

Normally, the SMART system monitors drive parameters and can be used to detect failing drives.  (The parity check is for data verification in software, not useful for hardware problems.)  But in this case, the drive just suddenly stopped talking, and therefore SMART was unusable, since you could not access the drive.  One possible cause of this would be a bad power spike, or static discharge, that fried some chip, in the drive or on the controller card.  Don't give up on the drive until you have tried on a different controller, or even a different computer.