Fireball3

I also flashed one more Dell Perc H310 to IT (P19) last night without any problems! Updated the toolset.

Quoting myself: Alternatively: Search the forum for "9211-8i" to find users that own the card and then PM them.

Once the google robot has been here, this "news" will lead many people to the unRAID forums! Nice marketing trick Seagate!

If it is genuine LSI and is obviously defective (port A not working) why not RMA? You did nothing illegal when trying to flash LSI supported firmware. At least they (LSI) should be able to send you a stock rom to solve your problem - although I doubt you will be able to solve potential hardware issues like that.

Thanks for sharing this! Seagate is once more ruining their reputation. - shorten warranty periods for consumer drives --> negative - deliver drives with useless APM settings (ST1000DM003) --> negative - poor drive quality (personal opinion) --> negative - now this bull*$&% --> negative - more to come... Unfortunately they're one of the very few players left in this business.

I remember having read similar issues somewhere in this forum - keep searching. It is not caused by the script - it's a general issue with S3 on your configuration.

Here is the version 1.1 of the auto_s3_sleep script. Thanks to Superorb who helped to get rid of some bugs. In the process I also made the logging more detailed. If the script runs for your satisfaction you may want to set the debug variable to 0 (no logging) to keep writes to the log (flash drive) as low as possible. Some answers to questions that arose: This script is only checking certain conditions and either shuts down the server or sends it to S3 sleep. Powerdown is done by invoking the /sbin/powerdown You should ensure that the clean powerdown script is installed, it is not part of this script! S3 sleep is done by echo -n mem > /sys/power/state It seems that sending the server to S3 sleep is not trivial though. unRAID will return many errors when waking up again. The whole extent is not clear since I don't use it. There should probably be some kind of routine to, at least, unmount the array before sleeping. More work and testing is needed so watch out when using S3! Possible settings/checks: # check for TCP activity # check for SSH connections # check for TELNET connections # check for locally logged in sessions # check for tmp/nos3sleep.lock (if this file exists, no sleep will be performed) # do not sleep if dedicated clients are pingable # only countdown outside specified hours # call smarthistory script to log SMART values before powerdown (not tested & not confirmed working) # choose between s3 sleep or powerdown (make sure you have installed the clean powerdown script) Rename the file to .sh Edit with a unix-like editor (e.g. notepad++) and configure to your needs. Update: Version 1.2 of this script is here It adds the possibility to exclude drives. Thanks go 2 maspiter.

OK, with extensive help from WeeboTech I finally managed to get the auto_s3_sleep script working. Possible settings/checks: # check for TCP activity # check for any SSH connections # check for any TELNET connections # check for any locally logged in sessions (if "no" allows console debugging) # check for tmp/nos3sleep.lock (if this file exists, no sleep will be performed) # do not sleep if dedicated clients are pingable # only countdown outside specified hours # call smarthistory script to log SMART values before powerdown (not tested & not confirmed working) # choose between s3 sleep or powerdown (make sure you have installed the clean powerdown script) Rename the file to .sh Edit: attachment temporarily removed due to a reported minor bug (bug has been found, removed but remains to be confirmed)

And here is the issue. UNRAID AUTOMATICALLY STARTS A CORRECTING PARITY CHECK AFTER A CRASH. It doesn't give you the option to evaluate the situation before it starts writing data to the parity disk. I agree! If unRAID detects an error, it should not start the array and it should not automatically conduct a parity check!

Look for settings like "passthrough, or disable RAID" if available.

Well, if you have it for free, then why don't you test it?

That card would be a waste for the use with unRAID since it's a real hardware RAID card (ROC). Despite that, I can't say though if it will work with unRAID - tend to say it won't. You need a simple HBA (host bus adapter) that passes the drives through to the OS. LSI is pricey! Check the reference builds from IBM or SuperMicro. Dell might also work but it seems that not every Dell card can be crossflashed.

You won't have the preclear_finish_xxxxxxxx -file and the preclear_rpt. Only the preclear_start_xxxxxxxxxx is in the log directory. If the first preclear cycles ran without changes in the SMART values, then the drive is probably fine. I would trust it. The only thing is, that the signature for "successful preclear" is probably not set and unRAID won't recognize the drive as precleared. preclear_disk.sh -t /dev/sdX to test if a disk has a current/correct preclear signature. I don't know, if there is an option in the preclear that let's you set the signature? But I think there is a way to skip the read test and shorten the procedure.

You mentioned, that you had problems with smart errors before you started "works" on the controller! Nevertheless, should be clear to everyone.

Strange problem. You mentioned that you also had the CRC errors when your drives were connected to the mainboard. When switching to the LSI controller you already changed the cabling - then it got worse. You say you have those CRC errors on multiple drives... There may be one or two defective cables but not multiple and after switching to a completely different cable (set) it is highly unprobable to have the same issue on multiple cables/drives again. Is there an electromagnetic emitter in the vicinity of your server? Maybe your PSU is the source? I would test another PSU next and after that, given the result is negative, test another mainboard.

Without knowing your array, this throughput seems OK for parity check! Check this.

OK guys, here are my flashlogs that I recorded when I flashed the last 3 H310 controllers. Sice I don't have your logs, I leave it up to you to evaluate them. Perhaps you can find a significant detail that prevents your cards from being flashed? @master.h So you were successful in flashing the P7 firmware? Have you tried the newer P17 with the according sas2flash? Flashlogs.zip

The flash utility that was used is called lsiutil. Here is what he wrote: Then he did this: Unfortunately the 9240-8i is not IT firmware and most certain won't work with unraid! But you could at least flash something else on the card... Another thread to flash something else on that card.

This is not good! I heard this issue from another guy I have been in touch with. But he flashed with another tool - not the sasflash or megarec. Don't remember at the moment... What about jimpa? Jimpa, you flashed the D2607 also. Are your both ports working with the IT firmware?

The linked file in this post contains all necessary tools to flash the Perc H310. For each step use the sas2flsh.exe out of the corresponding directory! Follow each step and you should be fine. If not, post the full Flashlog.txt!

LOL Just received word from seagate. Claudia (that's her name) tells me that she couldn't open the file attached to the ticket. As she doesn't know what tool I used she makes clear that only results from seatools are valid to her (seagate). If seatools don't indicate any problem, the drive is OK. Wow, that's the skill level that we're faced with... (FYI, I attached the preclear_finish...) Then she tells me if I refer to bad blocks, there would be no problem because they can be "replaced and repaired" in large quantities. Cool eh!? My drives CAN DO THAT! In my answer I copied the content of the preclear file into the mail but I guess there won't be an enlighting answer from seagate on this topic... A perfect start into weekend.

Hmm, I don't know what you guys are doing... What about the previous steps? As far as I rembember it was: 1. delete the card with the empty.sbr (optionally with the h200.sbr) 2. flash the p7 firmware 3. flash the p16 firmware (wich will only work after p7) Please post the output for the P7 flash. I will look for and check the logs of my flashings. Perhaps we can see a difference then?

Thank you for your feedback. Of course I will keep the logs, they are saved on the unRAID website. In fact, the bad blocks don't give me headaches. I'm more worried about this log entries: Error 418 occurred at disk power-on lifetime: 55 hours (2 days + 7 hours) When the command that caused the error occurred, the device was active or idle. After command completion occurred, registers were: ER ST SC SN CL CH DH -- -- -- -- -- -- -- 40 51 00 ff ff ff 0f Error: UNC at LBA = 0x0fffffff = 268435455 Commands leading to the command that caused the error were: CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name -- -- -- -- -- -- -- -- ---------------- -------------------- 60 00 08 ff ff ff 4f 00 1d+02:05:45.236 READ FPDMA QUEUED 27 00 00 00 00 00 e0 00 1d+02:05:45.209 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3] ec 00 00 00 00 00 a0 00 1d+02:05:45.207 IDENTIFY DEVICE ef 03 46 00 00 00 a0 00 1d+02:05:45.194 SET FEATURES [set transfer mode] 27 00 00 00 00 00 e0 00 1d+02:05:45.166 READ NATIVE MAX ADDRESS EXT [OBS-ACS-3] Meanwhile I tested a second drive - the same model - and it logs the same errors as this one. I've opened a ticket with the seagate support. I'm curious about their answers.

RMA'd a Seagate ES2 drive and got back a repaired one. Ran preclear 3 times and ... see the results. What about those failures in the SMART log? preclear_reports.zip

Nice write-up gary. If i remember correctly, you are storing your backups on single drives. How often do you check your backup drives to ensure that you don't have errors on them? Prior to using unRAID I also had my data stored all over the place on different drives. After having the server ready I found that some files were not readable when I moved them to the array. The monthly parity check ensures that the data on the array is readable but if you store the backups on single drives and don't verify them regularly you may be lulled into a false sense of security.