Fireball3

As there was an update for the s3sleep plugin lately, I did it. Then I noticed, that my server didn't shut down last night and when checking the plugin status it was inactive. Is it possible to keep/restore the pre-update status of a plugin when the update is complete?

Read here, how to get the diagnostics: https://lime-technology.com/forum/index.php?topic=39257.0 What is disk cleaner? A plugin? Yes, that is possible. You need to know exactly which is the parity drive and assign it accordingly. The order of the data drives can be random. But it is not normal to have the drives show up like that! Let's check the diagnostics first!

Did you flash the card or was it working out of the box?

Please share what you did to get it working so far. And post a diagnostics file. IIRC there is a similar issue with the Areca controllers in JBOD mode. It looks like the cards BIOS is interfering in the passthrough. You can check what settings are available in the cards BIOS. Make sure the drives are simply passed through.

What version of unRAID are you running? Can you log into console to retrieve a syslog? Or even better call a diagnostic check (on v6): The 'diagnostics' command from a console/telnet session. diangnostics file will be placed in the 'logs' folder on the flash drive. Come back and post it here.

Interesting thing Dextros I did some research on that Pike 2308. From the spec it is a LSI 2308 Chipset. This means, the equivalent LSI adaptor would be an LSI 9207 HBA. The task is trying to crossflash the IT firmware of the LSI HBA to the Pike 2308. I found a post on freenas explaining how to flash a Pike 2008 (although I have some doubts, that the sequence of the info posted there is correct). It sounds like the usual procedure that we use to flash the 9240 based cards. That proves that crossflashing of those Pike cards is possible in principle. I can support you, but it is highly experimental what you are trying to do! It is possible that the card gets bricked in the process <-- you have been warned! Do yo want to proceed, drop me a pm.

That depends on how the card is sold. In any case, it should have IT firmware flashed for unRAID. You might also want to skip flashing the BIOS for faster boot times. Next open point is driver support in unRAID itself, but you should see pretty soon how things go. Keep us updated please!

Where does it show you this kind of info? Which unRAID version?

The machine won't POST. Bootloop or beeping, depends. All fine. Yes, the Dell firmware (6GBPSAS.FW) is mandatory as the tool will not let you flash a software from a different vendor. (I didn't test it myself - will do next time) The P7 firmware is also mandatory as intermediate step, as only this specific version of the sas2flsh.exe will let you override the vendor ID mismatch so you can flash the LSI firmware on the "DELL" hardware. Once on LSI P7, you can go to whatever LSI firmware version you like (P16, P19, P20). Yes, it will end up as an LSI 9211-8i IT HBA. You can choose to flash the BIOS (guess you refer to that). Just remove the "REM" in the batch-file in the last firmware folder (P20). If you boot to unRAID it is not necessary to have a BIOS flashed. unRAID will also show all your connected drives. The BIOS will significantly increase boot time because it will scan all drives at boot. I don't know if the que depth matters. You can use both but obviously Avago (LSI) is still improving their firmware. I can't say if DELL does also.

Release notes: Firmware: \firmware\HBA_9211_8i_IT\2118it.bin Version no: 20.00.07.00 Release date: 11-FEB-16 ID: SCGCQ01026819 (Port Of Defect SCGCQ00927500) Headline: IOP: False Reply Parity Error Firmware Workaround Description Of Change: When the false reply parity error occurs, clear out the interrupt and return. If it was a real parity error, then the error would either be seen upstream or downstream as well, and another parity error wouldbe generated. Issue Description: In the IOP a false reply parity error is being generated, which results in a 0x1500 fault. Steps To Reproduce: Run in hostboot with specialized drivers and run IOs. Some controllers never see the issue, while others see the issue in a highly consistent manner. Component: \sasctrlfw\common \sasctrlfw\controllerfw\iop\sched I must admit, I can't say if it is relevant for unRAID or not, but probably it won't hurt to have it. (only some controllers affected, hostboot, specialized drivers) Edit: Updated the toolset.

When I said I had seen similar, I meant similar reports on the forum. I have personally never had this with any drive of any kind. And my ideas about the cause is speculation. It's just that another interpretation of that number you reported is -1. That is the way -1 is represented in 32bit. Sure, got your point! There was no specific/additional reason for my second post. :-)

Precleared another drive of the same build some time ago, with a different firmware on a different rig. ========================================================================1.15b == invoked as: ./preclear_bjp.sh -f -A /dev/sdd == ST3500630AS 9QG4RFZ9 == Disk /dev/sdd has been successfully precleared == with a starting sector of 64 == Ran 1 cycle == == Using :Read block size = 1000448 Bytes == Last Cycle's Pre Read Time : 3:26:18 (40 MB/s) == Last Cycle's Zeroing time : 2:15:42 (61 MB/s) == Last Cycle's Post Read Time : 2:40:48 (51 MB/s) == Last Cycle's Total Time : 8:23:50 == == Total Elapsed Time 8:23:50 == == Disk Start Temperature: 44C == == Current Disk Temperature: -->47<--C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdd /tmp/smart_finish_sdd ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 Airflow_Temperature_Cel = 53 56 45 In_the_past 47 Temperature_Celsius = 47 44 0 ok 47 No SMART attributes are FAILING_NOW 0 sectors were pending re-allocation before the start of the preclear. 0 sectors were pending re-allocation after pre-read in cycle 1 of 1. 0 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 0 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. ============================================================================ ST3500630AS_9QG4RFZ9.ZIP

Check this one... == invoked as: /boot/config/plugins/preclear.disk/preclear_disk.sh -c 1 /dev/sdb == ST3500630AS 9QG2G37S == Disk /dev/sdb has been successfully precleared == with a starting sector of 64 == Ran 1 cycle == == Using :Read block size = 1000448 Bytes == Last Cycle's Pre Read Time : 2:30:11 (55 MB/s) == Last Cycle's Zeroing time : 2:09:40 (64 MB/s) == Last Cycle's Post Read Time : 4:44:04 (29 MB/s) == Last Cycle's Total Time : 9:24:56 == == Total Elapsed Time 9:24:56 == == Disk Start Temperature: 30C == == Current Disk Temperature: -->43<--C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdb /tmp/smart_finish_sdb ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Spin_Retry_Count = 100 100 97 near_thresh 0 Airflow_Temperature_Cel = 57 70 45 In_the_past 43 Temperature_Celsius = 43 30 0 ok 43 Hardware_ECC_Recovered = 66 84 0 ok 30005550 Current_Pending_Sector = 1 1 0 near_thresh 4294967295 Offline_Uncorrectable = 1 1 0 near_thresh 4294967295 No SMART attributes are FAILING_NOW 4294967295 sectors were pending re-allocation before the start of the preclear. 4294967295 sectors were pending re-allocation after pre-read in cycle 1 of 1. 4294967295 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 4294967295 sectors are pending re-allocation at the end of the preclear, the number of sectors pending re-allocation did not change. 0 sectors had been re-allocated before the start of the preclear. 0 sectors are re-allocated at the end of the preclear, the number of sectors re-allocated did not change. "No SMART attributes are FAILING_NOW" but I guess, I won't trust this drive... Preclear_ST3500630AS.zip

Testing the older firmware would clearly show if it is an issue of the P20.00.07.00 firmware.

22°C ?? It's getting summer now and I expect the ambient temps to be around 25°C in our homes. Sometimes it will even hit the 30°C if we don't keep doors closed during the day. I would have to place the PC in the refrigerator... My best guess is, that the 33°C you see are not accurate. Can't even remember if it is possible to set the CPU alarm to such a low value. My CPU alarms are set to 70°C - Xeons and i5's and i7's

Feel free to use the wiki for reference cards. http://www.lime-technology.com/wiki/index.php/Hardware_Compatibility#PCI_SATA_Controllers Hopefully you can restore the Fujitsu firmware on that card.

Fujitsu has these cards you could pick for configuration: RAID-Controller - SAS 6 Gb/s RAID 5/6 512 MB (D2616) LSISAS2108 6 Gb/s RAID-on-Chip D2607 SAS/SATA RAID-Controller LSISAS2008 6 Gb/s RAID-Controller SAS 6 Gbit/s 1 GB (D3116C) LSISAS2208 6 Gbit/s RAID-on-Chip The D2607 is a rebranded LSI9240-8i like the DELL Perc H310/H200 or the IBM M1015 Those cards can be flashed with the HBA firmware from an LSI9211-8i (which is a plain HBA) Although it is a rebrand, crossflashing is only partially successful, while the other ones mentioned are working fine. In case of the D2607 only one SAS port will work if crossflashed. My guess is, that a Raid on Chip is not flashable to IT mode. Check the LSI/Avago RoC adapters for IT/IR firmware... it's not that simple

As far as i can see from the links you have, it is always about SAS2008 cards! The problem is that Fujitsu is not LSI. Although the card may be "just rebranded", probably there are checks in place to prevent crossflashing with LSI or other firmware. For example, when talking about SAS2008 cards there is a key firmware (P07) that will allow you to override the "Vendor mismatch". The newer versions will not offer this opportunity and instead just quit with an error! Do you have an original Fujitsu Firmware that you can flash? Is there an HBA firmware from Fujitsu? And be careful to pick the right one! I used a tool from Fujitsu in a similar situation on a D2607 and successfully bricked the card. The computer won't post any more with the card plugged. Edit: The spec sheet for D2616 says SAS2108. Edit2: The equivalent 6 GB/s HBA from LSI/Avago is named SAS2308 and the card itself is called SAS-9217-8i http://www.avagotech.com/products/server-storage/host-bus-adapters/sas-9217-8i#specifications For this specific card, there is a IT/IR firmware set. Nevertheless, this is NO guarantee that a crossflash will work, even if you have a rebranded SAS-9217 card (I don't speak of the D2616!).

Fujitsu D2616 has a SAS2108 chip! I wouldn't assume that the SAS2008 firmwares are working with those cards. You should check if there is a HBA firmware for SAS2108 chips. I have no time to do so at the moment.

Quite comprehensible Frank! This should go to the wiki and the "?" in the unRAID GUI should link to that wiki entry! ty

Be careful!!! Search the net for info specially related to that card or chipset! You are putting your card at risk if you "just try" with a wrong/unknown firmware. Sometimes you can set the controller to JBOD and pass each drive through if you don't have a dedicated IT mode. Last thing you can do is sell your incompatible card and get one with a known working IT mode. Always better than having an expensive paperweight!

If that behavior is still persistent, then something is wrong. Can you "stop" and "start" once the server is up? If you remove the auto-start setting again, is the "start" working or not? I will cross-check this with my server.

But this should work, indifferent what is set for startup!

I started with v5.0.? in August 2013 - don't know if the file structure has been changed since. I know, it's good to have all that kind of stuff, but when looking particularly for the upgrade instruction it's distracting. No, the plugin is pretty welcome! And it does make things easier, it just doesn't perfect. Especially if you have the server somewhere in the basement or locked up with the thumb drive inside the case it is very handy! No need to crack the case open and remove the stick to format it. At least not, if the plugin would perform all steps, including the final makebootable instruction. LT mentioned, they will have a look into it... http://lime-technology.com/forum/index.php?topic=41061.msg389099#msg389099

Yes, the upgrade via the plugin failed in 3 out of 3 times. In any of my cases I had to issue the "makebootable" once again. If i remember correctly it is an issue that the syslinux is in a directory now, but the makebootable will resolve this. The instruction length is really repelling! It would have been nice, if there was a final update to v5 that would introduce a link or a qualified update procedure from within the GUI.