I was running a parity check last night on my new array, trying to test it thoroughly before announcing it "production".

 

I got the errors below about an hour before the parity check ended.  (The complete syslog is also attached.)

 

I am not sure if this is something related to the beta or not, but thought I'd start in general support.

 

Can someone take a look and give me your interpretation.  The parity check completed with no errors.

 

C2SEE Motherboard, 4G Memory, unRAID 5.0b6a

 

Here is the info on ata10 from the boot (it seems like the troublemaker). This disk in on the SASLP controller.

 

[size=11pt]Mar 20 02:42:06 Shark kernel: ata10.00: ATA-8: WDC WD20EADS-00W4B0, 01.00A01, max UDMA/133
Mar 20 02:42:06 Shark kernel: ata10.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 31/32)
Mar 20 02:42:06 Shark kernel: ata10.00: configured for UDMA/133[/size]

 

Section of syslog where problem occurred (includes a line or 2 above and below the section).

 

[size=11pt]Mar 21 02:42:15 Shark dhcpcd[1170]: eth0: renewing lease of 192.168.1.6
Mar 21 02:42:16 Shark dhcpcd[1170]: eth0: leased 192.168.1.6 for 86400 seconds
Mar 21 04:39:00 Shark kernel: sas: command 0xf6f62d80, task 0xc502ca00, timed out: BLK_EH_NOT_HANDLED
Mar 21 04:39:00 Shark kernel: sas: Enter sas_scsi_recover_host
Mar 21 04:39:00 Shark kernel: sas: trying to find task 0xc502ca00
Mar 21 04:39:00 Shark kernel: sas: sas_scsi_find_task: aborting task 0xc502ca00
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 1703:<7>mv_abort_task() mvi=c5300000 task=c502ca00 slot=c531163c slot_idx=x2
Mar 21 04:39:00 Shark kernel: sas: sas_scsi_find_task: querying task 0xc502ca00
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 1632:mvs_query_task:rc= 5
Mar 21 04:39:00 Shark kernel: sas: sas_scsi_find_task: task 0xc502ca00 failed to abort
Mar 21 04:39:00 Shark kernel: sas: task 0xc502ca00 is not at LU: I_T recover
Mar 21 04:39:00 Shark kernel: sas: I_T nexus reset for dev 0400000000000000
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x89800.
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x1001
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2111:phy4 Unplug Notice
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x199800.
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x11081
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2138:notify plug in on phy[4]
Mar 21 04:39:00 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2163:plugin interrupt but phy4 is gone
Mar 21 04:39:02 Shark kernel: mvsas 0000:02:00.0: Phy4 : No sig fis
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2024:phy4 Attached Device
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x89800.
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x1001
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2111:phy4 Unplug Notice
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x199800.
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x81
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2083:port 4 ctrl sts=0x199800.
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2085:Port 4 irq sts = 0x10000
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 2138:notify plug in on phy[4]
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 1224:port 4 attach dev info is 0
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 1226:port 4 attach sas addr is 4
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 378:phy 4 byte dmaded.
Mar 21 04:39:02 Shark kernel: sas: sas_form_port: phy4 belongs to port3 already(1)!
Mar 21 04:39:02 Shark kernel: drivers/scsi/mvsas/mv_sas.c 1586:mvs_I_T_nexus_reset for device[3]:rc= 0
Mar 21 04:39:02 Shark kernel: sas: I_T 0400000000000000 recovered
Mar 21 04:39:02 Shark kernel: sas: sas_ata_task_done: SAS error 8d
Mar 21 04:39:02 Shark kernel: ata10: translated ATA stat/err 0x01/04 to SCSI SK/ASC/ASCQ 0xb/00/00
Mar 21 04:39:02 Shark kernel: ata10: status=0x01 { Error }
Mar 21 04:39:02 Shark kernel: ata10: error=0x04 { DriveStatusError }
Mar 21 04:39:02 Shark kernel: sas: --- Exit sas_scsi_recover_host
Mar 21 04:40:01 Shark logrotate: ALERT - exited abnormally.
Mar 21 05:43:33 Shark kernel: md: sync done. time=27828sec[/size]

syslog-bjp999-2011-03-21.zip

It sure looks like the drive disconnecting and reconnecting to the controller. But, I'm thinking it could be the controller resetting the connection to the drive when the drive didn't respond to some command or timed out on some command.

 

Peter

It sure looks like the drive disconnecting and reconnecting to the controller. But, I'm thinking it could be the controller resetting the connection to the drive when the drive didn't respond to some command or timed out on some command.

 

Peter

 

It looked like it was detected like it was a hotswap unplug, and then it recognized the drive on a different port.  I am surprised it sorted it all out and resolved the issue without something going terribly wrong!  Had never seen this before and though others might find it interesting.

 

I think I will try replacing the sata cable to the affected drive, and reseating the molex plugs into the drive cage.  Hope it will keep this error from repeating.

I'm still leaning towards a recovery from the drive timing out, for example taking too long to spin-up or not responding to a wake-up command. See the sas timeout and Enter recovery lines before;

 

Mar 21 04:39:00 Shark kernel: sas: command 0xf6f62d80, task 0xc502ca00, timed out: BLK_EH_NOT_HANDLED

Mar 21 04:39:00 Shark kernel: sas: Enter sas_scsi_recover_host

 

And then the sas exit recovery after;

 

Mar 21 04:39:02 Shark kernel: sas: --- Exit sas_scsi_recover_host

 

The card driver appears to disconnect and reconnect the drive in an attempt to recover it.

 

Peter

 

I think you are right. Besides replacing the Sata cable and checking power connections, any other suggestions to avoid these in the future?

It appears that you have three different controllers in your system - one SM, one BR10i and one ARECA. Perhaps they do not like each other, or how they are placed...or...?

 

It appears that you have three different controllers in your system - one SM, one BR10i and one ARECA. Perhaps they do not like each other, or how they are placed...or...?

 

I would think that if the controllers didn't get along, it would create more frequent symptoms.  But you are right, with something like this you just don't know where to point your finger.  I can't think of any way to know for sure.  But unless there is more evidence implicating one of the controllers, I don't think I'll be trying to remove one.

 

I cannot replace the cable as I don't have an extra 8087 FB cable, but will at least unplug and replug both ends.  I will also take a look to see if there could be some possible electrical interference ocurring.  I tried to do some cable management - maybe ai did more harm than good!