Hi

 

I have developed a problem with my server. It has started to spit out the below in the syslog extract, although I can still access the shares fine. This happened during a parity check I ran (no correct option). Does this look like a SATA card issue. I have disk 1 and disk 2 on the same PCI SATA Card - and it would seem the problem below is related to ata1 and ata2. I have a 700W power supply. I have made no changes to the hardware configuration for a long time.

 

This may seem like a stupid question but - if I swap out the sata card for a new one is unRAID locked to it in any way i.e. is the drive assignment only locked to the physical disk ID itself and it will not notice a new a new sata card. I'm pretty sure this is a case, but just checking.

 

Thanks

 

Matt

 

Jun 2 04:01:36 Tower logger: mover finished
Jun 2 04:01:48 Tower kernel: ata1: drained 32768 bytes to clear DRQ.
Jun 2 04:01:48 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 2 04:01:48 Tower kernel: ata1.00: failed command: READ DMA EXT
Jun 2 04:01:48 Tower kernel: ata1.00: cmd 25/00:00:77:ae:12/00:04:22:00:00/e0 tag 0 dma 524288 in
Jun 2 04:01:48 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Jun 2 04:01:48 Tower kernel: ata1.00: status: { Busy }
Jun 2 04:01:48 Tower kernel: ata1.00: error: { ICRC UNC IDNF ABRT }
Jun 2 04:01:48 Tower kernel: ata1: hard resetting link
Jun 2 04:01:48 Tower kernel: ata2: drained 32768 bytes to clear DRQ.
Jun 2 04:01:48 Tower kernel: ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 2 04:01:48 Tower kernel: ata2.00: failed command: READ DMA EXT
Jun 2 04:01:48 Tower kernel: ata2.00: cmd 25/00:00:77:ae:12/00:04:22:00:00/e0 tag 0 dma 524288 in
Jun 2 04:01:48 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Jun 2 04:01:48 Tower kernel: ata2.00: status: { Busy }
Jun 2 04:01:48 Tower kernel: ata2.00: error: { ICRC UNC IDNF ABRT }
Jun 2 04:01:48 Tower kernel: ata2: hard resetting link
Jun 2 04:01:49 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Jun 2 04:01:49 Tower kernel: ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Jun 2 04:01:49 Tower kernel: ata1.00: configured for UDMA/33
Jun 2 04:01:49 Tower kernel: ata1: EH complete
Jun 2 04:01:49 Tower kernel: ata2.00: configured for UDMA/33
Jun 2 04:01:49 Tower kernel: ata2: EH complete
Jun 2 04:04:12 Tower kernel: ata1: drained 32768 bytes to clear DRQ.
Jun 2 04:04:12 Tower kernel: ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jun 2 04:04:12 Tower kernel: ata1.00: failed command: READ DMA EXT
Jun 2 04:04:12 Tower kernel: ata1.00: cmd 25/00:00:4f:f8:78/00:04:22:00:00/e0 tag 0 dma 524288 in
Jun 2 04:04:12 Tower kernel: res ff/ff:ff:ff:ff:ff/ff:ff:ff:ff:ff/ff Emask 0x2 (HSM violation)
Jun 2 04:04:12 Tower kernel: ata1.00: status: { Busy }
Jun 2 04:04:12 Tower kernel: ata1.00: error: { ICRC UNC IDNF ABRT }
Jun 2 04:04:12 Tower kernel: ata1: hard resetting link
Jun 2 04:04:13 Tower kernel: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)

sorry i wrote this early in the morning. i meant will it be ok if a use a different sata port for the drives.

 

Thanks

 

Matt

sorry i wrote this early in the morning. i meant will it be ok if a use a different sata port for the drives.

 

Thanks

 

Matt

You can move the drives to any SATA controller and any port when the array is stopped.  At best, unRAID will figure out where you moved the disk.  (It will if you are swapping around disks on the same set of ports)

 

Most times, you will need to use the "Devices" page to assign the drive to the logical slot in the array.  Once you do that, the array will be happy.

 

Joe L.

Joe L.

 

Many thanks for getting back to my post. The results to this issue are.

 

I swapped the 2 drives on the suspected bad SATA card one by one to one of the spare cards, enabling me to correctly assign the device.

 

it would seem that it was indeed a failed SATA PCI card. This is now removed and am parity checking without the error messages as we speak.

 

Again thanks for getting back to me.

 

Cheers

Matt