optiman

Server is running great and no issues with performance, or anything else. However I did notice a few log entries that I don't recall seeing the past. They may have nothing to do with 6.5.3. Server has been up for about 2 days and 9 hours, and I see 3 entries in my syslog: Jun 29 03:41:13 Tower nginx: 2018/06/29 03:41:13 [error] 10391#10391: *296946 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main" Jun 29 03:41:13 Tower php-fpm[10365]: [WARNING] [pool www] child 21260 exited on signal 7 (SIGBUS) after 264.591907 seconds from start Jun 29 20:40:49 Tower nginx: 2018/06/29 20:40:49 [error] 10391#10391: *457950 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main" Jun 29 20:40:49 Tower php-fpm[10365]: [WARNING] [pool www] child 9358 exited on signal 7 (SIGBUS) after 337.768022 seconds from start Jun 30 16:16:14 Tower nginx: 2018/06/30 16:16:14 [error] 10391#10391: *618350 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main" Jun 30 16:16:14 Tower php-fpm[10365]: [WARNING] [pool www] child 17068 exited on signal 7 (SIGBUS) after 289.569545 seconds from start I also see the following warnings in my log: Jun 28 07:46:17 Tower kernel: ACPI: Early table checksum verification disabled Jun 28 07:46:17 Tower kernel: spurious 8259A interrupt: IRQ7. Jun 28 07:46:17 Tower kernel: random: 7 urandom warning(s) missed due to ratelimiting Jun 28 07:46:18 Tower rpc.statd[1769]: Failed to read /var/lib/nfs/state: Success Jun 28 07:46:18 Tower rpc.statd[1769]: Initializing NSM state Jun 28 07:46:18 Tower sshd[1787]: Server listening on 0.0.0.0 port 22. Jun 28 07:46:18 Tower sshd[1787]: Server listening on :: port 22. Jun 28 07:46:39 Tower sshd[1787]: Received signal 15; terminating. Jun 28 07:46:39 Tower acpid: client connected from 10225[0:0] Jun 28 07:46:39 Tower acpid: 1 client rule loaded Jun 28 07:46:40 Tower sshd[10242]: Server listening on 0.0.0.0 port 22. Jun 28 07:46:40 Tower sshd[10242]: Server listening on :: port 22. Jun 28 07:46:41 Tower avahi-daemon[10335]: WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Other than these few warnings / errors, my log is clean. Do any of these look serious or important? Thanks! Update: Given nobody responded, I will assume these errors are not related to the new release. I'll post in the General Support area.

upgraded from 6.5.1 and no issues so far.

Great trick, thank you! I upgraded my cache drive and got the error saying I needed to recreate the image file. I was worried that I would have to reconfigure everything, but not the case. It was a quick and easy fix and all of my template settings were saved and the app settings were all saved too, so I didn't do anything but install the docker apps from Previous tab. Thanks Squid!

Thank you! Good to know. it looks like it had about a page full of those log entries, and now they have stopped.

I'm running 6.5.1 One of my cache drives died and I don't have a spare right now. Therefore I stopped the array, set the cache device count back to 1 and then started the array. Everything looks good with 1 cache drive and my files are intact on the cache drive. Everything seems to be running good, except my syslog is filling up with the following entries (sdm is my cache drive): Jun 17 11:41:59 Tower kernel: BTRFS info (device sdm1): found 4 extents Jun 17 11:42:00 Tower kernel: BTRFS info (device sdm1): relocating block group 6366538235904 flags data Here is what I have done so far: -ran Balance, found no issues -ran scrub, zero errors -in Maintenance Mode, ran BTRFS filecheck - zero errors -Ran FixCommonErrors, all good there - no warnings found -Ran both Short and Extended SMART tests on the cache drive - no errors and SMART error log is empty -I have backed up the contents of my cache drive, which is less than 50gb fo stuff. When searching, the only good hit I got was for Resolving Extent Backrefs - https://btrfs.wiki.kernel.org/index.php/Resolving_Extent_Backrefs That says to do a "Perform a lookup in the EXTENT_TREE for:", and lists several other things to do. I'm new to BTRFS and I do not know how to perform a lookup. Isn't there a script or cool button I can just click on to resolve this issue? Just curious, what happens if I didn't see these log entries and did nothing? Will it harm anything?

Good points and I understand that. I didn't get much feedback when posting questions here about the 16i card so I went the safer route and got the LSI 9305-24i

Thanks I agree, that is the safe strategy and normally what I do. That said, when they say there are 12 defects, means you should at least assess if they impact unraid setup. This is a minor dot lease and after reviewing what this fw update fixes, they are very minor. I didn't see anything in the change log that would impact performance in unraid. For those that want to see what the 12 fixes changed, see below. I'm sorry this is a long post, but this way these items will be easy to search on this forum. ReleaseOrder ID: SCGCQ01748201 Headline: Point Release: SASFW_Intruder_Phase_16.0 - 16.00.01.00 IT Release Release Version: 16.00.01.00 UCM Project: SAS3.5FW_MASTER_DEV Sub UCM Project: SASFW_Intruder_Phase_16.0 UCM Stream: SASFW_Intruder_Phase_16.0_Rel Release Type: Point State: Open Release Baseline: SASFW_Intruder_Phase_16.0-2018-05-01-16.00.01.00_REL_1525219757@ \SAS_CTRL_FW Release Date: Date Generated: May 02, 2018 Defects Fixed (12): ID: SCGCQ01720974 (Port Of Defect SCGCQ01681441) Headline: (SATA only) Self-test offline immediate status received from drive is not populated to SCSI log sense command. Description Of Change: In certain firmware condition self-test in progress was reported without parsing read log ext data. Change is done to parse self-test status from read log ext self-test log output and populate SCSI log sense data Issue Description: Self-test status queried via SCSI log sense command always reported as self-test in progress even after self-test completed at drive end. Steps To Reproduce: Trigger Offline Self-test on SATA drive using SCSI send diagnostic command. Poll Offline Self-test status using SCSI log sense command. ID: SCGCQ01732726 (Port Of Defect SCGCQ01571933) Headline: (SATA Only) ATA Request Sense Ext command sometimes not send when the drive responds with 'Sense Data Available' bit set. Description Of Change: Added check to see if 'Sense Data Available' bit is set in the response handler function for ATA Identify command. Removed some checks that were preventing sending ATA request sense command from some completion handler functions. Issue Description: Whenever a SATA drive responds with 'Sense Data Available' and 'Error' bits set in its reply Device to Host FIS firmware is required to send ATA request sense ext command to retrieve the sense data. It is observed that in some cases the command is not sent. 1. When the SCSI command is translated to ATA Identify command (but changed to some other command using Jammer), since SATA drives are not supposed to fail the Identify command a check to see if the 'Sense Data Available' bit is set was not added. 2. When a command requires drive to send the PIO setup FIS to initiate data transfer after the translated ATA command is sent by the firmware but instead drive responds with device to host FIS with Sense Data Available bit set, some checks in firmware was preventing it from sending ATA request sense ext command. Steps To Reproduce: To a SATA drive that supports sense data reporting feature send a SCSI command that results in failure by the drive (or change the Host to Device FIS using Jammer that the drive fails) with 'Sense Data Available' bit set. Observe that for sometimes ATA request sense command is not send by the firmware to get the sense data. ID: SCGCQ01732727 (Port Of Defect SCGCQ01577907) Headline: (SATA Only) SCSI Write Long command send with out of range block address does not fail. Description Of Change: Before sending ATA Request sense EXT command check if drive is in automated mode if so change it to non automated. Issue Description: SCSI to ATA Write long translation changes the drive to automated mode for data transfer but when the drive fails the command with Sense Data Available bit set in Status field, firmware will send the ATA Request Sense Ext command to the drive to get the sense information, but it needs to change the mode of drive to 'non automated' other wise the successful response of Request sense command will result in responding to original Write Long command. Steps To Reproduce: To a SATA drive that supports sense data reporting feature send a Write long command and through a jammer in translated ATA FIS change the LBA value to a out of range value. The command will complete successfully instead of failing with check condition as expected. ID: SCGCQ01732728 (Port Of Defect SCGCQ01593844) Headline: (SATA Only) ATA Request Sense Ext command not sent for failed SCSI Unmap command sent to a SATA drive. Description Of Change: Added code to check the 'Sense Data Available' bit in the function handling response for Data Set Management command send to the SATA drive while translating SCSI Unmap command. Issue Description: SCSI Unmap command sent to a SATA SSD gets translated to Data Set Management (TRIM) command, if this command is modified such that the drive fails the command with 'Sense Data Available' bit is set. Firmware is required to send a ATA Request Sense Ext command to get the sense data, which is not being sent. Steps To Reproduce: 1) Send a SCSI Unmap command to a sense data supported/enabled drive 2) Modify the sector count (In ATA FIS) to a huge value 3) sense data available bit is set in the drive 4) ATA Req sense Data Ext command is not sent to drive by SATL ID: SCGCQ01732730 (Port Of Defect SCGCQ01598756) Headline: (SATA Only) Incorrect Additional sense code when SCSI Format to a SATA drive fails Description Of Change: Changed the additional sense code to PERIPHERAL DEVICE WRITE FAULT. Issue Description: As per Scsi to ATA Translation spec when write operation during Format handling fails then firmware should respond with sense key set to MEDIUM ERROR and the additional sense code is set to PERIPHERAL DEVICE WRITE FAULT. Currently firmware is responding with sense key set to MEDIUM ERROR and the additional sense code is set to FORMAT Command Failed. Steps To Reproduce: Send SCSI Format Unit command to a SATA drive with IMMED bit not set in parameter list and when the LBA field (In ATA FIS) modified to a huge value to force a failure during the write operation , Additional Sense Code is set to "Format command failed" whereas it should be set to "PERIPHERAL DEVICE WRITE FAULT" ID: SCGCQ01732731 (Port Of Defect SCGCQ01599542) Headline: (SATA Only) ATA Request Sense Ext command being sent after ATA command translated for SCSI Start Stop Unit command fails with Sense Data Available. Description Of Change: Removed sending ATA request sense ext command in completion handler function for start stop unit command. Issue Description: For any non - NCQ ATA command sent to SATA drive as part of translation from SCSI to ATA, that fails with Sense Data Available bit set in Status field Firmware sends ATA Request Sense Ext command to get the sense data. However in case of SCSI Start Stop Unit command the Scsi to ATA Translation specification describes what sense data should be used if any translated command fails. So there is no need to send the ATA Request Sense command. Steps To Reproduce: Send SCSI Start Stop Unit command to a SATA drive that supports sense data reporting feature and force it to fail with sense data available bit set. ID: SCGCQ01732734 (Port Of Defect SCGCQ01605100) Headline: (SATA Only) ATA Request Sense Data Ext command not send to device when it fails translated SCSi Security Protocol Out. Description Of Change: Set the error status correctly when the error response is received before calling the completion handler function. Issue Description: On receiving an error response for a non NCQ ATA command with sense data available bit set firmware should send the ATA Request sense data ext command to get the sense data but this is not happening for Security Protocol Out command because the completion handler function was not being called with correct status in case of error. Steps To Reproduce: To a SATA drive that supports sense data reporting feature send a SCSI Security Protocol Out command such that the translated command is failed by the drive with sense data available bit set. Observe that firmware is not sending the ATA Request Sense Data Ext command to get the sense data after the failure. ID: SCGCQ01732736 (Port Of Defect SCGCQ01628346) Headline: (SATA Only) Incorrect Sense Key and Additional Sense Code set for failed Start Stop Unit command. Description Of Change: Removed a check that was preventing f/w from processing the error response in completion handler of one of the translated ATA command for SCSI Start Stop Unit command. Issue Description: During translation of SCSI Start Stop Unit command if any error is reported by the drive the command should be failed with check condition as mentioned in SAT spec. This was not happening in some cases. Steps To Reproduce: Send SCSI Start Stop Unit Command to SATA drive with power condition set to standby and force it to reply with error. The command is not failed back to host with check condition. ID: SCGCQ01732738 (Port Of Defect SCGCQ01631836) Headline: (SATA Only) SCSI Log Select command not failed with check condition when translated ATA command is failed by SATA drive. Description Of Change: Added check for error response from drive in PIO setup handler function of SCSI Log Select translation. Issue Description: The callback function handling the PIO setup FIS received when translating the SCSI Log Select command was not checking the error response from drive resulting into failure of the SCSI command but without check condition as expected. Steps To Reproduce: 1) Send a Log select command to a SATA Drive 2) Ensure that the drive is kept busy (may be using sanitize command with polling disabled) 3) Observe that SATA drive fails the ATA command but SCSI command to host is not failed with check condition. ID: SCGCQ01742589 (Port Of Defect SCGCQ01715509) Headline: PL: Chassis Slot Valid Flag is Incorrectly Cleared in Enclosure Page 0 Description Of Change: Set the ChassisSlotValid flag in PL enclosure flags when processing SMP Report General response. Issue Description: Because SCGCQ01323680 was not fully ported, the ChassisSlotValid flag in enclosure flags was not being set. This resulted in chassis slot valid not being set with Enclosure Page 0 was read. Steps To Reproduce: Use customer system. Zone in a slot in the enclosure. The slot ID will be wrong. ID: SCGCQ01745857 (Port Of Defect SCGCQ01510418) Headline: Requested capacity field translations are incorrect for remove element & truncate command Description Of Change: check added for following 1. If requested capacity upper two bytes are not zero then fail command with invalid field in CDB 2. If requested capacity is 1 then fail command with invalid CDB 3. For values of requested capacity other than 0 and 1, set MaxLBA to requested capacity -1 Issue Description: Based on SAT5r00a remove and truncate command with requested capacity set to 1 should be failed. However current firmware implementation ignored this field and sent command to drive. This was completing successfully as compared to expected behavior of command failing with illegal request. Steps To Reproduce: Send remove and truncate command with requested capacity set to 1. This command gets sent to drive and completes successfully. ID: SCGCQ01745933 (Port Of Defect SCGCQ01715677) Headline: PL: Avoid Duplicate Mid Workaround Does Not Start a TM If Device is Removed and Re-Added Description Of Change: Fixed a bug where the ResetNeeded flag in firmware is incorrectly cleared when a device is removed in firmware. Issue Description: If a drive is completely removed in firmware (DMD expires and the driver removes the device), and then the device is re-discovered, the avoid duplicate mid feature will not start a TM like it's supposed to. Steps To Reproduce: Pull a drive. Wait for DMD to expire. Re-insert the drive. View the firmware log and see that the avoid duplicate mid feature did not start a TM.

By the way, there is a new firmware available, came out May 20, 2018. See my other post, https://lime-technology.com/forums/topic/11753-sata-controller-cards/?page=24 Did you update yet?

I went with LSI cables for two of the ports and Supermicro cables for the other two. I hope they are more relieable than the crappy Trip Lite ones that get errors if you just look at them. LSI 9305-24i arrived and will install soon. After checking the website, I see there is a new firmware release. While the hw capatibility list says works Out Of the Box, has anyone updated their firmware to this latest version, 16.00.01.00 - released May 20, 2018? https://www.broadcom.com/products/storage/host-bus-adapters/sas-9305-24i#downloads Trying to decide if I leave the firmware as is, or update to the latest before connecting my drives.

cool - thank you for sharing. The hw compatibility list shows the 9305 24 working out of the box so I hope that is correct for my Supermicro X11SSM-F mb. Which breakout cables did you go with? I have tried a few different brands and found the Trip Lite ones are very sensitive and even a little pressure from the case door pressing on them will cause errors. I'm now trying LSI cables and SuperMircro brand. I'm also trying to use right angle drive connectors so the case side door doesn't even touch them.

Thank you! My 9305-24i was delivered today. Did you install it in a 8x slot or a 16x slot? I know it's a 8x card and the 16x slot won't help with anything, but I was curious if it worked ok in a 16x slot. Very cool that we don't have do update firmware or mess with drivers. ?

Will the new LSI SAS 9400-16i sata card work with this new version of unraid? Drivers included or I would have to manually install them? update: nevermind, that card is not on the compatibility list. Will the LSI 9305-16i be supported soon? otherwise I will have to go with the LSI 9305-24i

I'm looking to buy the LSI SAS 9400-16i. Anyone using this card?

Anyone using the LSI SAS 9400-16i card in your unraid server? This card can drive 16 sata drives and I need more ports. update: After reading more, this card is way overkill and plus it is NOT on the hardware compatibility list. I also noticed that the LSI 9305-16i is not on the list. I guess I will have to go with the LSI 9305-24i because it is on the list and recommended. For LSI cables, I see LSI LSI00410 0.6m Internal Cable SFF8643 to x4 SATA. I'm looking for a recommendation on cables. I'm looking for the 90 degree facing down sata connections, so the cables drop downwards. The ones that go straight in make it tight for my side door, they rub against the door. I have tried 90 degree up cables, but those just make a big mess and the cables are in the way. The only LSI cables I can find are straight, so I need to look at other brands. Any recommendations?

Thanks Squid!

hum..ok will do. Weird how I can all the sudden have a cable issue, as I have not touched the cables in months. Thanks much for your help!

Diag attached. The Main screen shows no errors with the drives, so that is good. Thanks! tower-diagnostics-20180503-1614.zip

Today I have more errors. Perhaps something to do with the sata drivers or some other change in 6.5.1. I did not have any of these errors prior and I have not touched anything else. May 3 06:13:32 Tower kernel: ata8.00: exception Emask 0x50 SAct 0x0 SErr 0x4890800 action 0xe frozen May 3 06:13:32 Tower kernel: ata8.00: irq_stat 0x0c400040, interface fatal error, connection status changed May 3 06:13:32 Tower kernel: ata8: SError: { HostInt PHYRdyChg 10B8B LinkSeq DevExch } May 3 06:13:32 Tower kernel: ata8.00: failed command: READ DMA EXT May 3 06:13:32 Tower kernel: ata8.00: cmd 25/00:40:88:2e:73/00:05:a6:00:00/e0 tag 25 dma 688128 in May 3 06:13:32 Tower kernel: res 50/00:00:87:2e:73/00:00:a6:00:00/e0 Emask 0x50 (ATA bus error) May 3 06:13:32 Tower kernel: ata8.00: status: { DRDY } May 3 06:13:32 Tower kernel: ata8: hard resetting link May 3 06:13:38 Tower kernel: ata8: link is slow to respond, please be patient (ready=0) May 3 06:13:42 Tower kernel: ata8: COMRESET failed (errno=-16) May 3 06:13:42 Tower kernel: ata8: hard resetting link May 3 06:13:48 Tower kernel: ata8: link is slow to respond, please be patient (ready=0) May 3 06:13:49 Tower kernel: ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 310) May 3 06:13:49 Tower kernel: ata8.00: configured for UDMA/33 May 3 06:13:49 Tower kernel: ata8: EH complete May 3 06:13:56 Tower kernel: ata8.00: exception Emask 0x10 SAct 0x0 SErr 0x4890000 action 0xe frozen May 3 06:13:56 Tower kernel: ata8.00: irq_stat 0x0c400040, interface fatal error, connection status changed May 3 06:13:56 Tower kernel: ata8: SError: { PHYRdyChg 10B8B LinkSeq DevExch } May 3 06:13:56 Tower kernel: ata8.00: failed command: READ DMA EXT May 3 06:13:56 Tower kernel: ata8.00: cmd 25/00:40:88:ce:94/00:05:a6:00:00/e0 tag 18 dma 688128 in May 3 06:13:56 Tower kernel: res 50/00:00:87:ce:94/00:00:a6:00:00/e0 Emask 0x10 (ATA bus error) May 3 06:13:56 Tower kernel: ata8.00: status: { DRDY } May 3 06:13:56 Tower kernel: ata8: hard resetting link May 3 06:14:02 Tower kernel: ata8: link is slow to respond, please be patient (ready=0) May 3 06:14:06 Tower kernel: ata8: COMRESET failed (errno=-16) May 3 06:14:06 Tower kernel: ata8: hard resetting link May 3 06:14:12 Tower kernel: ata8: link is slow to respond, please be patient (ready=0) May 3 06:14:13 Tower kernel: ata8: SATA link up 1.5 Gbps (SStatus 113 SControl 310) May 3 06:14:13 Tower kernel: ata8.00: configured for UDMA/33 May 3 06:14:13 Tower kernel: ata8: EH complete Any ideas?

I saw these errors in my log today, which I have never seen before. Since upgrading to 6.5.1, these are the only errors so far. Anything to worry about? May 2 05:28:30 Tower nginx: 2018/05/02 05:28:30 [error] 10265#10265: *761604 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 127.0.0.1, server: , request: "POST /webGui/include/DeviceList.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "localhost", referrer: "http://localhost/Main" May 2 05:28:30 Tower php-fpm[10239]: [WARNING] [pool www] child 1600 exited on signal 7 (SIGBUS) after 328.611253 seconds from start

After running the Fix Common Problems tool. I have this error: **** Template URL for docker application binhex-sickrage is missing. **** **** Template URL for docker application couchpotato is missing. **** The Docker containers are running fine, so I'm not clear on how a template goes missing and how do I correct this?

After running the Fix Common Problems tool. I have this error: **** Template URL for docker application binhex-sickrage is missing. **** **** Template URL for docker application couchpotato is missing. **** The Docker containers are running fine, so I'm not clear on how a template goes missing and how do I correct this? I went to post this question in the Docker Container thread, but it's locked and you have to beg to get access. wtf.

Time for some Go file clean up. I installed the Update Assistant app and the report complained about some old entries in my Go file. Taking a closer look, we have added some lines over the past few years to add a custom temp sensor (I don't need this anymore), to fix a samba issue a few versions back, and a couple of other fixes . My guess is most if not all of those Go file entries are no longer needed. Here is a copy of my Go file. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # Update Sensors Config cp /boot/custom/sensors.d/sensors.conf /etc/sensors.d/sensors.conf modprobe coretemp modprobe it87 /usr/bin/sensors -s # Unmenu Start # /boot/unmenu/uu # This adjusts the PID for UNRAID server and Shares process may never be killed in a low memory condition. # Uses the new oom_score_adj # Set UNRAID webserver is never killed off. pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done # Set SAMBA so shares are never killed off. pgrep -f "/usr/sbin/smbd" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done # # Set UNRAID Telnet is never killed off. pgrep -f "in.telnetd" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done I took a look at the default Go file in the 6.5.1 and it only has one entry. #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & I plan to replace my existing Go file with the default file. Is there anything in the old Go file that is still needed or have all of those issues now been resolved? Thanks!

Maybe confirm network drivers are loading with 6.5. Check log and look at the Network Settings page in the gui and confirm all settings.

Thanks! I didn't see that link. The Update Notes are exactly what I was looking for. Awesome indeed!

+1 I too check the log before updating items and now the Mover is no longer telling me when it has finished. The Mover log is Enabled. Is there a list of recommendations for 6.5, other than this thread? After reading here, I learned that Advanced Buttons should be removed, as example. I don't use Advanced Buttons but it would be good to know what items should be removed when upgrading to 6.5. Another example is that Preclear plugin does not work anymore. There is a work around, but I had to f ind that in the preclear thread. It would be cool if in the first post of this thread, they include a list of things we should do, like remove some plugins, remove preclear, remove advanced buttons, etc.