March 25, 201016 yr Mar 25 07:53:24 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:53:24 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:53:24 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:53:24 Server kernel: ata16: hard resetting link Mar 25 07:53:25 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:53:25 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:53:25 Server kernel: ata16: EH complete Mar 25 07:57:17 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:57:17 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:57:17 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:57:17 Server kernel: ata16: hard resetting link Mar 25 07:57:18 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:57:18 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:57:18 Server kernel: ata16: EH complete 0 errors on disks, but I see this twice in my syslog. First time was 3 days ago and I ignored it because I noticed no problems. Now it happened again, I still notice no problems but it can't be normal. I don't even know what drive "ata16" is. This happened 1 hour after parity sync finished. So to my knowledge any drive in the system should have been spun down.. so I don't get how it's producing errors.
March 25, 201016 yr Mar 25 07:53:24 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:53:24 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:53:24 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:53:24 Server kernel: ata16: hard resetting link Mar 25 07:53:25 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:53:25 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:53:25 Server kernel: ata16: EH complete Mar 25 07:57:17 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:57:17 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:57:17 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:57:17 Server kernel: ata16: hard resetting link Mar 25 07:57:18 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:57:18 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:57:18 Server kernel: ata16: EH complete 0 errors on disks, but I see this twice in my syslog. First time was 3 days ago and I ignored it because I noticed no problems. Now it happened again, I still notice no problems but it can't be normal. I don't even know what drive "ata16" is. This happened 1 hour after parity sync finished. So to my knowledge any drive in the system should have been spun down.. so I don't get how it's producing errors. Check out this post I found using google: https://bugzilla.redhat.com/show_bug.cgi?id=404851 Similar error, same make disk drives as you. Do you have NCQ enabled for that disk? If so, try disabling it. Joe L. PS. If you attached a full syslog you would see where ata16 is affiliated with a physical disk. Hint: ata16 = sd 16:0:0:0. Look for sd 16:0:0:0: in the syslog.
March 25, 201016 yr Author Mar 25 07:53:24 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:53:24 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:53:24 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:53:24 Server kernel: ata16: hard resetting link Mar 25 07:53:25 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:53:25 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:53:25 Server kernel: ata16: EH complete Mar 25 07:57:17 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Mar 25 07:57:17 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Mar 25 07:57:17 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Mar 25 07:57:17 Server kernel: ata16: hard resetting link Mar 25 07:57:18 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Mar 25 07:57:18 Server kernel: ata16.00: configured for UDMA/133 Mar 25 07:57:18 Server kernel: ata16: EH complete 0 errors on disks, but I see this twice in my syslog. First time was 3 days ago and I ignored it because I noticed no problems. Now it happened again, I still notice no problems but it can't be normal. I don't even know what drive "ata16" is. This happened 1 hour after parity sync finished. So to my knowledge any drive in the system should have been spun down.. so I don't get how it's producing errors. Check out this post I found using google: https://bugzilla.redhat.com/show_bug.cgi?id=404851 Similar error, same make disk drives as you. Do you have NCQ enabled for that disk? If so, try disabling it. Joe L. PS. If you attached a full syslog you would see where ata16 is affiliated with a physical disk. Hint: ata16 = sd 16:0:0:0. Look for sd 16:0:0:0: in the syslog. After reading about NCQ it seems like it's a pretty big feature and disabling it would cause the drives to operate much slower. I have pretty much all greens in my system and it's only ata16 causing it. Mar 24 20:29:55 Server kernel: scsi 16:0:0:0: Direct-Access ATA WDC WD15EADS-00P 01.0 PQ: 0 ANSI: 5 Mar 24 20:29:55 Server kernel: sd 16:0:0:0: [sdh] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB) Mar 24 20:29:55 Server kernel: sd 16:0:0:0: [sdh] Write Protect is off Mar 24 20:29:55 Server kernel: sd 16:0:0:0: [sdh] Mode Sense: 00 3a 00 00 Mar 24 20:29:55 Server kernel: sd 16:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Mar 24 20:29:55 Server kernel: sdh: sdh1 Mar 24 20:29:55 Server kernel: sd 16:0:0:0: [sdh] Attached SCSI disk So ata16 = SDH? No SMART errors, same firmware as my other greens that don't suffer from this problem. I've never messed with any NCQ stuff. I don't think i'm going to disable NCQ unless this error is actually causing a problem. It seems like it's not.
March 25, 201016 yr In parens is [sdh] This will also show on your "devices" page in (parens) Click on the "settings" page on the web-interface. Towards the bottom is "Force NCQ disabled?" Set it to yes. You might need to reboot to see the new value take effect. If you see lines in the syslog disabling NCQ, then perhaps not... If it is only the one disk, then that might be the disk with the heavy activity getting the disk NCQ code confused... or the worse power supply noise, or the SATA cable getting the most noise, or a different firmware version that is causing the timeouts. As for impact, Google is your friend. If the errors occurred 1 hour after parity sync finished it is entirely possible the spin-down command was the one that was not being acted on. Sorry for being so general... If you had posted a syslog, we might have had the clues for a better analysis. Joe L.
March 25, 201016 yr Author In parens is [sdh] This will also show on your "devices" page in (parens) Click on the "settings" page on the web-interface. Towards the bottom is "Force NCQ disabled?" Set it to yes. You might need to reboot to see the new value take effect. If you see lines in the syslog disabling NCQ, then perhaps not... If it is only the one disk, then that might be the disk with the heavy activity getting the disk NCQ code confused... or the worse power supply noise, or the SATA cable getting the most noise, or a different firmware version that is causing the timeouts. As for impact, Google is your friend. If the errors occurred 1 hour after parity sync finished it is entirely possible the spin-down command was the one that was not being acted on. Sorry for being so general... If you had posted a syslog, we might have had the clues for a better analysis. Joe L. Force NCQ disabled was set to YES. I guess thats the default for unRAID? No idea whats causing this now. Same firmware as my other drives, SATA cables are grouped together, and the power cables are grouped together (they are a good foot apart from each other, since I use hotswap bays). This is the 1.5TB model, and I have 2TB models in my system. So this drive was spun down long before this error occured. I have a hard time blaming SATA/Power noise because the drive should have been spun down completely well before the time this error occured. I'll post a syslog.
April 2, 201016 yr Author Bumping this... just did my monthly parity check and I see these errors again. Same drive. Apr 1 08:34:54 Server kernel: md: sync done. time=30196sec rate=64694K/sec Apr 1 08:34:54 Server kernel: md: recovery thread sync completion status: 0 Apr 1 08:37:31 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Apr 1 08:37:31 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Apr 1 08:37:31 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Apr 1 08:37:31 Server kernel: ata16: hard resetting link Apr 1 08:37:32 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 1 08:37:32 Server kernel: ata16.00: configured for UDMA/133 Apr 1 08:37:32 Server kernel: ata16: EH complete Apr 1 08:38:20 Server kernel: ata16: exception Emask 0x10 SAct 0x0 SErr 0x10002 action 0xe frozen Apr 1 08:38:20 Server kernel: ata16: edma_err_cause=00000008 pp_flags=00000000, dev disconnect Apr 1 08:38:20 Server kernel: ata16: SError: { RecovComm PHYRdyChg } Apr 1 08:38:20 Server kernel: ata16: hard resetting link Apr 1 08:38:20 Server kernel: ata16: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Apr 1 08:38:21 Server kernel: ata16.00: configured for UDMA/133 Apr 1 08:38:21 Server kernel: ata16: EH complete Seems like it's still happening AFTER parity check is finished? The drive should have been spun down an hour before these errors just like before. Apr 1 07:13:54 Server kernel: mdcmd (48849): spindown 6 The drive WAS spun down 1 hour 20 minutes before the errors according to the syslog. How can a spun down drive be producing errors? Is this an unRAID bug possibly? I can't see it being a SATA error, as there was no activity going on at this time. 1 Power cable is used for 2 hot swap bays in my case, so if that was the case then the other drive should be acting up too? Only thing I can think of is unRAID bug (this didn't happen before 4.5.3), or the drive is faulty. However, this only happens after a parity check after the drive has been spun down for about an hour. If I never checked the syslog I wouldn't even know of these errors either. syslog.txt
April 2, 201016 yr I see these types of errors when a drive takes to long to respond to something the kernel wants it to do. Usually I see it on my seagate drives, but I have seen it happen on my 2TB hitachi's also. My one suggestion is to eliminate the hot swap bays. They are a great thing to have for convenience sake but can cause all kinds of problems if they decide to fail. THe worse part is that some of the bays will work fine while other will not play nice. You can try swapping the drive to a different bay and see if the problem persists, and also eliminate the bays all together.
Archived
This topic is now archived and is closed to further replies.