Jaco2k

Nope - problem is still there, and it is not affecting the same drive... *sigh* Dec 29 02:14:36 Tower kernel: ata14: limiting SATA link speed to 1.5 Gbps Dec 29 02:14:36 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 02:14:36 Tower kernel: ata14.00: failed command: READ DMA EXT Dec 29 02:14:36 Tower kernel: ata14.00: cmd 25/00:00:50:5b:4f/00:03:0f:00:00/e0 tag 4 dma 393216 in Dec 29 02:14:36 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 02:14:36 Tower kernel: ata14.00: status: { DRDY } Dec 29 02:14:36 Tower kernel: ata14: hard resetting link Dec 29 02:14:37 Tower kernel: ata14: SATA link up 3.0 Gbps (SStatus 123 SControl 310) Dec 29 02:14:37 Tower kernel: ata14.00: configured for UDMA/133 Dec 29 02:14:37 Tower kernel: ata14.00: device reported invalid CHS sector 0 Dec 29 02:14:37 Tower kernel: ata14: EH complete Dec 29 02:15:08 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 02:15:08 Tower kernel: ata14.00: failed command: READ DMA EXT Dec 29 02:15:08 Tower kernel: ata14.00: cmd 25/00:00:50:8d:50/00:03:0f:00:00/e0 tag 24 dma 393216 in Dec 29 02:15:08 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 02:15:08 Tower kernel: ata14.00: status: { DRDY } Dec 29 02:15:08 Tower kernel: ata14: hard resetting link Dec 29 02:15:09 Tower kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 02:15:09 Tower kernel: ata14.00: configured for UDMA/133 Dec 29 02:15:09 Tower kernel: ata14.00: device reported invalid CHS sector 0 Dec 29 02:15:09 Tower kernel: ata14: EH complete Dec 29 02:15:41 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 02:15:41 Tower kernel: ata14.00: failed command: READ DMA EXT Dec 29 02:15:41 Tower kernel: ata14.00: cmd 25/00:00:50:9a:52/00:03:0f:00:00/e0 tag 24 dma 393216 in Dec 29 02:15:41 Tower kernel: res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 02:15:41 Tower kernel: ata14.00: status: { DRDY } Dec 29 02:15:41 Tower kernel: ata14: hard resetting link Dec 29 02:15:42 Tower kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 02:15:42 Tower kernel: ata14.00: configured for UDMA/133 Dec 29 02:15:42 Tower kernel: ata14.00: device reported invalid CHS sector 0 Dec 29 02:15:42 Tower kernel: ata14: EH complete Dec 29 02:16:13 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 02:16:13 Tower kernel: ata14.00: failed command: READ DMA EXT Dec 29 02:16:13 Tower kernel: ata14.00: cmd 25/00:00:90:26:53/00:03:0f:00:00/e0 tag 15 dma 393216 in Dec 29 02:16:13 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 02:16:13 Tower kernel: ata14.00: status: { DRDY } Dec 29 02:16:13 Tower kernel: ata14: hard resetting link Dec 29 02:16:14 Tower kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 02:16:14 Tower kernel: ata14.00: configured for UDMA/133 Dec 29 02:16:14 Tower kernel: ata14.00: device reported invalid CHS sector 0 Dec 29 02:16:14 Tower kernel: ata14: EH complete Dec 29 02:16:24 Tower emhttp: cmd: /usr/local/emhttp/plugins/dynamix/scripts/tail_log syslog Dec 29 02:16:45 Tower kernel: ata14.00: limiting speed to UDMA/100:PIO4 Dec 29 02:16:45 Tower kernel: ata14.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 02:16:45 Tower kernel: ata14.00: failed command: READ DMA EXT Dec 29 02:16:45 Tower kernel: ata14.00: cmd 25/00:00:90:86:53/00:03:0f:00:00/e0 tag 27 dma 393216 in Dec 29 02:16:45 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 02:16:45 Tower kernel: ata14.00: status: { DRDY } Dec 29 02:16:45 Tower kernel: ata14: hard resetting link Dec 29 02:16:46 Tower kernel: ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 02:16:46 Tower kernel: ata14.00: configured for UDMA/100 Dec 29 02:16:46 Tower kernel: ata14.00: device reported invalid CHS sector 0 Dec 29 02:16:46 Tower kernel: ata14: EH complete

Answering my own question - with the full logs I was able to determine what was the exact disk. Switched to another slot and it worked just fine, so... - It is either a SATA cable (most probably) - The cage slot - The controller Since the disk and the controller are both new and the disk is working well now in another slot in the drive cage, I will need to find out which one is the faulty cable. Oh, well... Cheers and thanks anyway

Hello - currently I am experiencing very slow performance on my array, but with 15 disks inside, bit hard to say which one is the exact culprit. The log I pulled out probably has the answer, but I have no idea what to make of it: Dec 29 01:12:22 Tower kernel: ata13.00: device reported invalid CHS sector 0 Dec 29 01:12:22 Tower kernel: ata13: EH complete Dec 29 01:13:00 Tower kernel: ata13.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 01:13:00 Tower kernel: ata13.00: failed command: WRITE DMA EXT Dec 29 01:13:00 Tower kernel: ata13.00: cmd 35/00:40:90:f8:2c/00:05:77:00:00/e0 tag 24 dma 688128 out Dec 29 01:13:00 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 01:13:00 Tower kernel: ata13.00: status: { DRDY } Dec 29 01:13:00 Tower kernel: ata13: hard resetting link Dec 29 01:13:01 Tower kernel: ata13: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 01:13:01 Tower kernel: ata13.00: configured for UDMA/33 Dec 29 01:13:01 Tower kernel: ata13.00: device reported invalid CHS sector 0 Dec 29 01:13:01 Tower kernel: ata13: EH complete Dec 29 01:13:36 Tower kernel: ata13.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 01:13:36 Tower kernel: ata13.00: failed command: READ DMA EXT Dec 29 01:13:36 Tower kernel: ata13.00: cmd 25/00:40:a8:b9:32/00:05:77:00:00/e0 tag 7 dma 688128 in Dec 29 01:13:36 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 01:13:36 Tower kernel: ata13.00: status: { DRDY } Dec 29 01:13:36 Tower kernel: ata13: hard resetting link Dec 29 01:13:37 Tower kernel: ata13: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 01:13:37 Tower kernel: ata13.00: configured for UDMA/33 Dec 29 01:13:37 Tower kernel: ata13.00: device reported invalid CHS sector 0 Dec 29 01:13:37 Tower kernel: ata13: EH complete Dec 29 01:14:14 Tower kernel: ata13.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 01:14:14 Tower kernel: ata13.00: failed command: WRITE DMA EXT Dec 29 01:14:14 Tower kernel: ata13.00: cmd 35/00:40:c8:72:39/00:05:77:00:00/e0 tag 28 dma 688128 out Dec 29 01:14:14 Tower kernel: res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 01:14:14 Tower kernel: ata13.00: status: { DRDY } Dec 29 01:14:14 Tower kernel: ata13: hard resetting link Dec 29 01:14:15 Tower kernel: ata13: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 01:14:15 Tower kernel: ata13.00: configured for UDMA/33 Dec 29 01:14:15 Tower kernel: ata13: EH complete Dec 29 01:14:59 Tower kernel: ata13.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Dec 29 01:14:59 Tower kernel: ata13.00: failed command: READ DMA EXT Dec 29 01:14:59 Tower kernel: ata13.00: cmd 25/00:00:80:99:0d/00:05:77:00:00/e0 tag 7 dma 655360 in Dec 29 01:14:59 Tower kernel: res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Dec 29 01:14:59 Tower kernel: ata13.00: status: { DRDY } Dec 29 01:14:59 Tower kernel: ata13: hard resetting link Dec 29 01:15:00 Tower kernel: ata13: SATA link up 1.5 Gbps (SStatus 113 SControl 310) Dec 29 01:15:00 Tower kernel: ata13.00: configured for UDMA/33 Dec 29 01:15:00 Tower kernel: ata13.00: device reported invalid CHS sector 0 Dec 29 01:15:00 Tower kernel: ata13: EH complete Any help? Thank you all in advance.

I am slightly disappointed to see that the bug about the unclean shutdown when pressing the power button is still there... You promised it would be fixed on the next release but, apparently not. This seriously affects my usage right now - I run it headless and sometimes I am simply streaming to a XBMC machine on my living room where there is no web browser. Having to startup my desktop just to come and shutdown UnRaid via the web interface is far from good usage. So, when is then the fix coming for this "known" error? Given the current average release schedule, I hope it is not 2 months... --- Edit: Reviewed the original reply and I correct that it was not promised for next release. Nevertheless, this was working fine on the 5.x branches, so why not just transport the same shutdown method when pressing the power button? Mind you, I just tested on the 6.0 b7 and I updated, started the system, did NOT access any files and simply shutdown via power button. It still started a parity check on the next boot. I have absolutely no mods or plugins on my system - it is a totally default install that has been working well for a long time.

Well, I can safely say that in v5 this behaviour worked just fine - short press the power button and it would initiate a safe shutdown cycle. Actually, now it seems to still attempt to do so - it will spin the disks up and then spin them down one by one before shutting down, but it is not a clean shutdown. And no, I have not installed anything via UnMenu neither did I ever use it. And saying that you are only meant to shutdown via GUI is ridiculous - worked just fine before and hopefully will work again in the future.

Unfortunately I have to report some regression - as already happened in the past, I cannot get a clean shutdown when turning system off via box power button - it always will do a parity check on the first boot after that. Am I missing something or is this a bug?

Yes, I did and this is an old bug - it has happened before and it is doing it again. Was borked like that not so long ago. Reverting back to RC5 immediately solved it.

As per the title, when booting/rebooting the array is offline - this is a regression of an old bug.

Do you have any add-ons installed? If you log in and type ls -l /usr/local/sbin what do you see? if you type mount what do you see? (trying to learn if the flash drive is mounted read-only) Joe L. Hi Joe, Thank you for the help - since Tom says it will be fixed in RC5 I think my replies might be irrelevant. Either way, no addons whatsoever, the reply to your command is here: http://pastebin.ubuntu.com/1029435/ ...and the flash drive is NOT read only (I just confirmed) Cheers, J

Hi Tom, Sorry to report that my shutdown still is not clean - I (short) press the power button of my box and it does the whole shutdown routine (i.e. Powers up HDDs, etc.) but on the boot after that it starts a parity check. Shutdown via web interface works fine. These are taken from my previous report for RC3, but since the issue is still the same, they should also still be valid: ---------------------------------------------------------------------------- If I have my XBMC machine accessing UnRaid, even after I shutdown XBMC box it still seems to have some "locks" in UnRaid. On previous UnRaid builds it would just take longer to shutdown before it realized the files were not locked anymore. Currently it shuts down normally but something along triggers this Parity check after booting. Steps to reproduce: - Play a video from a share in UnRaid - Stop the video - Press the power button in UnRaid (yes, short press...) - Wait for UnRaid to go through the whole shutdown process (this means, wake the sleeping HDDs and one by one turn them off, etc.) - After UnRaid shuts down, wait 10 seconds and power it up again Expected results: - UnRaid shuts down clean - Upon bootup it is in normal state Actual results - (I am guessing) the Shutdown process is not clean - Upon bootup (repro 100% of times) it is in Parity check mode This is a log after booting with stopping the array in WebUI and choosing the shutdown option: http://pastebin.ubuntu.com/992303/ ...and this is a log after playing a video, stopping the video and shutting down via shutdown button: http://pastebin.ubuntu.com/992308/ Cheers, J

Hi Tom, Sorry to report that my shutdown still is not clean - I (short) press the power button of my box and it does the whole shutdown routine (i.e. Powers up HDDs, etc.) but on the boot after that it starts a parity check. Shutdown via web interface works fine. Do you want me to report this as an issue in the other forum? Cheers, J

And I realize the HW config must be relevant but... I built this machine with so many leftovers that I am not sure what is in there Let me check... This is a log after booting with stopping the array in WebUI and choosing the shutdown option: http://pastebin.ubuntu.com/992303/ ...and this is a log after playing a video, stopping the video and shutting down via shutdown button: http://pastebin.ubuntu.com/992308/

I am fairly certain PeterB did not mean what he posted to sound harsh. Yes, Tom said it was a bug, but it would still be nice to know what might cause it to happen so that people running RC3 can at least try to avoid making it happen. I am going on a limb here and say that it is not gracefully unmounting the shares if something is accessing them. If I have my XBMC machine accessing UnRaid, even after I shutdown XBMC box it still seems to have some "locks" in UnRaid. On previous UnRaid builds it would just take longer to shutdown before it realized the files were not locked anymore. Currently it shuts down normally but something along triggers this Parity check after booting. Steps to reproduce: - Play a video from a share in UnRaid - Stop the video - Press the power button in UnRaid (yes, short press...) - Wait for UnRaid to go through the whole shutdown process (this means, wake the sleeping HDDs and one by one turn them off, etc.) - After UnRaid shuts down, wait 10 seconds and power it up again Expected results: - UnRaid shuts down clean - Upon bootup it is in normal state Actual results - (I am guessing) the Shutdown process is not clean - Upon bootup (repro 100% of times) it is in Parity check mode

I re-iterate ... I'm running RC3 and get a clean shutdown when I press the power button. If this is a bug, what are the circumstances required to reproduce it? And because it works for you it has to work for everyone else? It was confirmed already it is a bug.

This is a bug. Thanks for the reply - do you know when it was introduced so that I can revert to a working one until it gets sorted?