Last night I was preparing to copy some data from one drive to another, and since it would be taking some hours to do I thought I'd do this at the console rather than using telnet.  So I moved from my Windows box and turned on the unraid monitor and pressed CTRL-ALT-DEL to login...

 

Oooooppppssss!

 

Windows really gets you conditioned to hit CTRL-ALT-DEL to get a login prompt these days.

 

So my unraid box responds by shutting down...  but NOT a clean shut down (which is really what it should do)...

 

When it reboots it wants to do a parity check...

 

Groan! Says I!

 

So I let it run for a few minutes, and in the mean time start up unmenu to check the syslog...

 

The unraid box seems particularly slow, and when I finally get an HTTP connection I find that a parity check is running and that it will be expected to finish in about one MONTH!  Its running at about 72kB/sec (that's kilo bytes not mega bytes).

 

Ok, I stop the parity check and do a full shutdown (including unplugging power for a short time) and restart and try again.  Same behaviour, except I have to manually start the parity check.

 

So I stop the parity check again and go to bed.

 

This morning I try again, get the same trouble but let it run longer and after about 15 minutes things seem to be behaving normally, its now doing a check at 77664kB/sec (so 77MB/sec).  However the syslog shows something odd with one SATA channel after the parity check started:

 

Aug 17 06:43:22 saturn kernel: mdcmd (9): check

Aug 17 06:43:22 saturn kernel: md: recovery thread woken up ...

Aug 17 06:43:22 saturn kernel: md: recovery thread checking parity...

Aug 17 06:43:22 saturn kernel: md: using 1152k window, over a total of 976762552 blocks.

Aug 17 06:44:23 saturn kernel: ata6.00: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x6 frozen

Aug 17 06:44:23 saturn kernel: ata6.00: cmd 60/00:00:cf:0d:00/04:00:00:00:00/40 tag 0 ncq 524288 in

Aug 17 06:44:23 saturn kernel: res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:44:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:44:23 saturn kernel: ata6.00: cmd 60/f8:08:cf:11:00/00:00:00:00:00/40 tag 1 ncq 126976 in

Aug 17 06:44:23 saturn kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:44:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:44:23 saturn kernel: ata6.00: cmd 60/00:10:c7:12:00/04:00:00:00:00/40 tag 2 ncq 524288 in

Aug 17 06:44:23 saturn kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:44:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:44:23 saturn kernel: ata6.00: cmd 60/08:18:c7:16:00/00:00:00:00:00/40 tag 3 ncq 4096 in

Aug 17 06:44:23 saturn kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:44:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:44:23 saturn kernel: ata6: hard resetting link

Aug 17 06:44:23 saturn kernel: ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Aug 17 06:44:23 saturn kernel: ata6.00: configured for UDMA/133

Aug 17 06:44:23 saturn kernel: ata6: EH complete

Aug 17 06:44:23 saturn kernel: sd 6:0:0:0: [sde] 1953525168 512-byte hardware sectors (1000205 MB)

Aug 17 06:44:23 saturn kernel: sd 6:0:0:0: [sde] Write Protect is off

Aug 17 06:44:23 saturn kernel: sd 6:0:0:0: [sde] Mode Sense: 00 3a 00 00

Aug 17 06:44:23 saturn kernel: sd 6:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Aug 17 06:45:23 saturn kernel: ata6.00: exception Emask 0x0 SAct 0x6 SErr 0x0 action 0x6 frozen

Aug 17 06:45:23 saturn kernel: ata6.00: cmd 60/00:08:cf:1a:00/04:00:00:00:00/40 tag 1 ncq 524288 in

Aug 17 06:45:23 saturn kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:45:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:45:23 saturn kernel: ata6.00: cmd 60/00:10:cf:1e:00/01:00:00:00:00/40 tag 2 ncq 131072 in

Aug 17 06:45:23 saturn kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Aug 17 06:45:23 saturn kernel: ata6.00: status: { DRDY }

Aug 17 06:45:23 saturn kernel: ata6: hard resetting link

 

Similar messages get repeated about once a minute until 06:51.

 

I've attached the complete syslog too.

 

 

Thanks,

 

Stephen

 

 

 

Hi, I have a tool called powercontrol which adds some hooks into the rc shutdown phase.

This assists in shutting down unRAID gracefully.

 

http://code.google.com/p/unraid-powercontrol/

 

Regarding slow speeds.

 

I noticed this.

Aug 17 06:47:26 saturn kernel: ata6.00: NCQ disabled due to excessive errors

 

Did you try setting NCQ off in emhttp and saving it?

 

Also check the cable or reseat the cable to this drive just in case it is a victim of heat creep.

 

Hi, I have a tool called powercontrol which adds some hooks into the rc shutdown phase.

This assists in shutting down unRAID gracefully.

 

http://code.google.com/p/unraid-powercontrol/

 

 

I'll have a look at that.

 

 

Regarding slow speeds.

 

I noticed this.

Aug 17 06:47:26 saturn kernel: ata6.00: NCQ disabled due to excessive errors

 

Did you try setting NCQ off in emhttp and saving it?

 

How do you do this?  What's emhttp?

 

 

Also check the cable or reseat the cable to this drive just in case it is a victim of heat creep.

 

 

I've reseated the cable, tried two other cables and even reconnected the drive to a different SATA port.  In all cases (so far) it is only wanting to run at the 1.5Gbps link speed (though I have other WD10EADS drives that run at the 3Gbps link speed).  I've also tried it on both the motherboard controller and a SiL3132 based PCI-e controller card.  The card is one of these from monoprice:

 

http://www.monoprice.com/products/product.asp?c_id=104&cp_id=10407&cs_id=1040702&p_id=2530&seq=1&format=2

 

The behaviour with the PCI-e card is better because it seems to negotiate for the 1.5Gbps link right away, so when you start the parity check you don't get any more errors (which is what happens with the motherboard port).

 

I'm going to try some more cable swapping and also try some different ports on the motherboard.

 

Stephen

 

I've reseated the cable, tried two other cables and even reconnected the drive to a different SATA port.  In all cases (so far) it is only wanting to run at the 1.5Gbps link speed (though I have other WD10EADS drives that run at the 3Gbps link speed).  I've also tried it on both the motherboard controller and a SiL3132 based PCI-e controller card.  The card is one of these from monoprice:

 

http://www.monoprice.com/products/product.asp?c_id=104&cp_id=10407&cs_id=1040702&p_id=2530&seq=1&format=2

 

The behaviour with the PCI-e card is better because it seems to negotiate for the 1.5Gbps link right away, so when you start the parity check you don't get any more errors (which is what happens with the motherboard port).

 

I'm going to try some more cable swapping and also try some different ports on the motherboard.

 

Did you check for a drive jumper that might be forcing the drive to stay at 1.5Gbbs?

Did you check for a drive jumper that might be forcing the drive to stay at 1.5Gbbs?

 

I *think* I did... I know my first 1TB seagate drives had those (and I removed them) but I don't recall ever seeing one on a WD drive.  But I'll have to have another look.

 

Stephen

 

 

Did you check for a drive jumper that might be forcing the drive to stay at 1.5Gbbs?

 

I *think* I did... I know my first 1TB seagate drives had those (and I removed them) but I don't recall ever seeing one on a WD drive.  But I'll have to have another look.

 

Stephen

 

 

 

I found one jumper, on the Seagate 750GB drive, I've removed it and now all drives are linking at 3 Gbps and staying there.  Reading the syslog can be pretty confusing! The problem with the WD 1TB drive dropping down to 1.5 Gbps as soon as parity checking started has been solved, though I'm uncertain if it was a bad cable,  loose connector or bad port on the motherboard.

 

Stephen