Problem with adding additional drive to 4.5.1

 

I recently posted a message regarding a very slow system with parity checks.

 

http://lime-technology.com/forum/index.php?topic=5449.0

 

However, it seems that the problem is much deeper than originally thought. When the system is running with the “original” setup, there are no problems as I can see them and parity checks are fast and error-free. However, when add an additional drive, which was checked and working on a Windows system, the parity checks become dreadfully slow and there are sync errors. I have attached syslogs for both before and after introduction of the new 1TB drive into the system. Can someone please tell me what is going on?

 

Thanks,

 

Lev

syslog-2010-03-01_v1.txt

Sorry. I cannot seem to attach a second syslog. I get an error message that the file is too large...

 

I split it into two part.

syslog-2010-03-03_v1_part1.txt

syslog-2010-03-03_v1_part2.txt

One of your disks is apparently not able to communicate with the disk controller and is being constantly reset by the operating system because of CRC errors when trying to send commands to it.

 

Mar  1 07:05:53 Tower kernel: ata7.00: ATA-8: Hitachi HDT721010SLA360, ST6OA31B, max UDMA/133

Mar  1 07:05:53 Tower kernel: ata7.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)

Mar  1 07:05:53 Tower kernel: ata7.00: configured for UDMA/133

 

Mar  3 09:07:59 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x780100 action 0x6

Mar  3 09:07:59 Tower kernel: ata7.00: irq_stat 0x08000000

Mar  3 09:07:59 Tower kernel: ata7: SError: { UnrecovData 10B8B Dispar BadCRC Handshk }

Mar  3 09:07:59 Tower kernel: ata7.00: cmd 25/00:00:47:40:00/00:04:00:00:00/e0 tag 0 dma 524288 in

Mar  3 09:07:59 Tower kernel:          res 50/00:00:46:40:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)

Mar  3 09:07:59 Tower kernel: ata7.00: status: { DRDY }

Mar  3 09:07:59 Tower kernel: ata7: hard resetting link

Mar  3 09:08:00 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar  3 09:08:00 Tower kernel: ata7.00: configured for UDMA/133

Mar  3 09:08:00 Tower kernel: ata7: EH complete

Mar  3 09:08:00 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x700100 action 0x6

Mar  3 09:08:00 Tower kernel: ata7.00: irq_stat 0x08000000

Mar  3 09:08:00 Tower kernel: ata7: SError: { UnrecovData Dispar BadCRC Handshk }

Mar  3 09:08:00 Tower kernel: ata7.00: cmd 25/00:00:47:6c:00/00:04:00:00:00/e0 tag 0 dma 524288 in

Mar  3 09:08:00 Tower kernel:          res 50/00:00:46:6c:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)

Mar  3 09:08:00 Tower kernel: ata7.00: status: { DRDY }

Mar  3 09:08:00 Tower kernel: ata7: hard resetting link

Mar  3 09:08:00 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar  3 09:08:00 Tower kernel: ata7.00: configured for UDMA/133

Mar  3 09:08:00 Tower kernel: ata7: EH complete

Mar  3 09:08:00 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x780100 action 0x6

Mar  3 09:08:00 Tower kernel: ata7.00: irq_stat 0x08000000

Mar  3 09:08:00 Tower kernel: ata7: SError: { UnrecovData 10B8B Dispar BadCRC Handshk }

Mar  3 09:08:00 Tower kernel: ata7.00: cmd 25/00:00:47:7c:00/00:04:00:00:00/e0 tag 0 dma 524288 in

Mar  3 09:08:00 Tower kernel:          res 50/00:00:c6:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)

Mar  3 09:08:00 Tower kernel: ata7.00: status: { DRDY }

Mar  3 09:08:00 Tower kernel: ata7: hard resetting link

Mar  3 09:08:01 Tower kernel: ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Mar  3 09:08:01 Tower kernel: ata7.00: configured for UDMA/133

Mar  3 09:08:01 Tower kernel: ata7: EH complete

Mar  3 09:08:01 Tower kernel: ata7: limiting SATA link speed to 1.5 Gbps

Mar  3 09:08:01 Tower kernel: ata7.00: exception Emask 0x10 SAct 0x0 SErr 0x700100 action 0x6

Mar  3 09:08:01 Tower kernel: ata7.00: irq_stat 0x08000000

Mar  3 09:08:01 Tower kernel: ata7: SError: { UnrecovData Dispar BadCRC Handshk }

Mar  3 09:08:01 Tower kernel: ata7.00: cmd 25/00:f8:47:8c:00/00:03:00:00:00/e0 tag 0 dma 520192 in

Mar  3 09:08:01 Tower kernel:          res 50/00:00:46:8c:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)

Mar  3 09:08:01 Tower kernel: ata7.00: status: { DRDY }

Mar  3 09:08:01 Tower kernel: ata7: hard resetting link

Mar  3 09:08:01 Tower kernel: ata7: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

Mar  3 09:08:01 Tower kernel: ata7.00: configured for UDMA/133

Mar  3 09:08:01 Tower kernel: ata7: EH complete

 

If I'm interpreting the syslog correctly, this is /dev/sdg  (the only hitachi with the same disk model number)

Mar  1 07:05:53 Tower emhttp: pci-0000:05:00.0-scsi-0:0:0:0 host7 (sdg) Hitachi_HDT721010SLA360_STF607MH3E8W1K

 

You probably have either a bad disk, or a bad cable to the disk, or a cable picking up induced noise, or a loose cable making a poor connection, or a bad disk controller port.

Joe,

I've changed the cables, and made sure that they are seated well. The only other thing that I have not yet tried is to move the drive to another SATA connector on my AB9 Pro mobo. I guess what I can also do is to put the Hitachi back into my Windows machine and run some more tests on it to make sure that there are no errors.

Joe,

I've changed the cables, and made sure that they are seated well. The only other thing that I have not yet tried is to move the drive to another SATA connector on my AB9 Pro mobo. I guess what I can also do is to put the Hitachi back into my Windows machine and run some more tests on it to make sure that there are no errors.

It could also be a problem with power to the drive.  You can try moving it to a different power supply connector, especially if there are splitters in line and even more so if the supply is not one with a single supply rail.  The drive might work just fine in the windows box if it is the disk controller port that is bad or if the power supply to it is noisy or low in voltage because of a series of high-resistance connections.

So, before moving to a Win machine, I should try moving to a different controller and change power supply connector. Can I attempt each step separatelly, attempt to run parity check, and if I see problems abort the check and try the next step?

So, before moving to a Win machine, I should try moving to a different controller and change power supply connector. Can I attempt each step separatelly, attempt to run parity check, and if I see problems abort the check and try the next step?

Exactly... It is a process of elimination.  You did not post your hardware config, so I don't know the power supply you are using.  It could be it is at its limit and the last drive on the rail you are using it putting it over its capacity.

Many supplies use one rail for the motherboard, another for the PCI cards, and a third for the disks.  The capacity available to the disks is a third of that advertised.

 

Or, we've had LOTS of users with splitters that made bad connections... myself included. 

Here is my partial parts list:

 

Motherboard - AB9 Pro

PSU - Ultra 500P

The hard drive in question is being housed in an Addonics 3-in-1 internal SATA enclosure as disk 2. The other two slots are also populated, one of the drives being the cache drive. Here is the link to the enclosure page:

http://www.addonics.com/products/raid_system/images/3sa_diagram_large.gif

http://www.addonics.com/products/raid_system/ae4rcs35nsa.asp

 

It is the 3-in-1 unit.

 

The drive is connected to SATA 8 connector on the board, not that it probably matters.

 

I am not using any additional splitters of the PSU, but the cable does have several connectors of of it.

 

I have other PSUs at home, namely ACZ 700w unit. Do you think that I should try that first? It seems strange that that is the only drive that you are seeing problems with. You'd think that other drives on the same cable should also be effected.

 

Anyway, it looks like I still have about 1230 minutes left to go on parity sync, since I took that drive out of the array before I can try any new mods. Or should I stop it now and try some of the steps outlined?

Here is my partial parts list:

 

Motherboard - AB9 Pro

PSU - Ultra 500P

The hard drive in question is being housed in an Addonics 3-in-1 internal SATA enclosure as disk 2. The other two slots are also populated, one of the drives being the cache drive. Here is the link to the enclosure page:

http://www.addonics.com/products/raid_system/images/3sa_diagram_large.gif

http://www.addonics.com/products/raid_system/ae4rcs35nsa.asp

 

It is the 3-in-1 unit.

 

The drive is connected to SATA 8 connector on the board, not that it probably matters.

 

I am not using any additional splitters of the PSU, but the cable does have several connectors of of it.

 

I have other PSUs at home, namely ACZ 700w unit. Do you think that I should try that first? It seems strange that that is the only drive that you are seeing problems with. You'd think that other drives on the same cable should also be effected.

 

Anyway, it looks like I still have about 1230 minutes left to go on parity sync, since I took that drive out of the array before I can try any new mods. Or should I stop it now and try some of the steps outlined?

According to this review of your power supply it has a single 12 volt rail rated at 28 Amps.  It also seemed to fall below 12 volts when loaded by one of the larger video cards.

 

IF you have 10 disk drives, and they all draw 2 amps when first starting, that is 20 of the 28 amps possible.  In my opinion, that is cutting it too close.  It really does not leave a lot for the motherboard.  It is therefore also a possibility.  Don't forget you are also powering the case fans, etc.  If the new disk is slightly intolerant of voltage variations it would be all it takes to work properly in one PC and not the other.

 

You also have more connections involve than just the SATA cables.  The SATA connectors plug into your 3-in-1 backplane, it in turn plugs into drives.  I'm not pointing at any one thing, but you'll have a few iterations to find the issue.  If it is easy to swap in the alternate power supply I'd give it a try once you get past the easier choices.  You might try just connecting to the drive directly, without the backplane in between.  Also, which of the power connectors did you use on the backplane?  Did you use only one? or multiple?

 

 

I guess what I'm saying is it might be the disk, or the disk controller, or the drive tray, or the power supply, or something entirely else...

You've started on the "process of elimination" so we'll have to see how it goes.

 

Joe L.

Joe,

 

Thank you for the support. I spoke to the manufacturer of the enclosure and the power connection scheme that I have right now is the recommended one by them.

 

I guess the easy part would be first is to take out the drive out of the enclosure and connect it by itself to the board, by a separate SATA / power connector. Also, I'll use the other free SATA connector on the board. I think that I should wait till the parity sync is finished. There is still at least 19 hours to go... One step at a time.

I guess one other thing I may want to try is a different SATA drive... See if that one works in the same slot. If that one fails then I'll know that it is problem with the setup and not the Hitachi drive.

Now I am completely baffled. I took out my cache drive which was on a SATA port that I knew was working and replaced it with a 1.5TB data drive that was also working well. I took one of the two IDE drives out of the system and replaced it with the above SATA drive. So, the SATA drive should have had no problems as it was running on a previously working SATA channel. The parity sync ran fast and without any errors. However, just to be safe, I decided to run another parity check right afterwords and am getting a ton of errors. The parity check is also extremely slow. Attached is a new syslog. Please, anything that I am doing that I can correct? This thing is driving me batty! 

syslog-2010-03-08.zip

Just as a follow up...

 

No matter what I did, including trying different hard drives, different SATA ports and new power supply, when ever I would run a parity check the system would come to a screeching halt and there would be thousands of errors reported. Finally, I placed an old rinky dinky 2-port PCI SATA controller (Promise) and ran a parity check. There were 99,173 errors reported, but the check ran fast. Subsequently, I ran a second consecutive check and that one ran without a single error. Go figure. It seems that the SATA ports on my Abit AB9 Pro were going bad. Otherwise, I have no explanation. At least, all's well that ends well.