Joe L.

Telling me the MB and RAM does not really help. I can tell you I drive a Toyota, and I use regular gas... That tells you nothing about the air-pressure in the tires, or the amount of tread on them, or if they have a slow leak. You cannot just rely on the BIOS. Too often the BIOS will set the speed, voltage or timing wrong, especially if you use premium RAM which needs special timing, clock speed or voltage. Normally, DDR3 ram uses 1.5 volts. Your strips need 1.6. It might be as simple as that, or your timing could be off too. According to newegg, your ram needs: Speed DDR3 1333 (PC3 10666) Cas Latency 9 Timing 9-9-9-24 Voltage 1.6V

Looks to me like you are either running out of memory, or, have faulty memory, or memory where the voltage, timing, or clock speed is not set properly in the BIOS. (Some BIOS get it right automatically, some do not) I suggest a memory test first. Jul 11 10:59:51 Tower kernel: preclear_disk.s[2005]: segfault at 0 ip 0804e595 sp bf9e20d0 error 6 in bash[8048000+a0000] Jul 11 11:28:14 Tower kernel: preclear_disk.s[9047]: segfault at 7e5f810 ip 07e5f810 sp bf8a8dfc error 14 in bash[8048000+a0000] Jul 11 11:28:14 Tower kernel: preclear_disk.s[9046]: segfault at 7e5f810 ip 07e5f810 sp bf8a8dcc error 14 in bash[8048000+a0000] Jul 11 11:28:14 Tower kernel: preclear_disk.s[9052]: segfault at 7e5f810 ip 07e5f810 sp bf8a8fdc error 14 in bash[8048000+a0000] Jul 11 11:44:40 Tower kernel: preclear_disk.s[11567]: segfault at 7e5f810 ip 07e5f810 sp bf8a8dfc error 14 in bash[8048000+a0000] Jul 11 11:44:40 Tower kernel: preclear_disk.s[11566]: segfault at 7e5f810 ip 07e5f810 sp bf8a8dcc error 14 in bash[8048000+a0000] Jul 11 11:44:40 Tower kernel: preclear_disk.s[11572]: segfault at 7e5f810 ip 07e5f810 sp bf8a8fdc error 14 in bash[8048000+a0000] Jul 11 11:46:16 Tower kernel: swap_free: Bad swap file entry 00002000 Jul 11 11:46:16 Tower kernel: BUG: Bad page map in process preclear_disk.s pte:4000000000000 pmd:126bc9067 Jul 11 11:46:16 Tower kernel: addr:b78a1000 vm_flags:08000075 anon_vma:(null) mapping:f7086f78 index:144 Jul 11 11:46:16 Tower kernel: vma->vm_ops->fault: filemap_fault+0x0/0x305 Jul 11 11:46:16 Tower kernel: vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x3f Jul 11 11:46:16 Tower kernel: Pid: 11805, comm: preclear_disk.s Not tainted 2.6.32.9-unRAID #8 Jul 11 11:46:16 Tower kernel: Call Trace: Jul 11 11:46:16 Tower kernel: [<c1057e18>] print_bad_pte+0x182/0x194 Jul 11 11:46:16 Tower kernel: [<c1058cb5>] unmap_vmas+0x42f/0x64c Jul 11 11:46:16 Tower kernel: [<c105c802>] exit_mmap+0x8a/0x102 Jul 11 11:46:16 Tower kernel: [<c10227ac>] mmput+0x28/0x96 Jul 11 11:46:16 Tower kernel: [<c1025b53>] exit_mm+0xd3/0xdb Jul 11 11:46:16 Tower kernel: [<c1026bbf>] do_exit+0x152/0x508 Jul 11 11:46:16 Tower kernel: [<c106d659>] ? fput+0x17/0x19 Jul 11 11:46:16 Tower kernel: [<c1026fdc>] do_group_exit+0x67/0x8d Jul 11 11:46:16 Tower kernel: [<c1027011>] sys_exit_group+0xf/0x13 Jul 11 11:46:16 Tower kernel: [<c1002935>] syscall_call+0x7/0xb Jul 11 11:46:16 Tower kernel: Disabling lock debugging due to kernel taint Jul 11 12:04:33 Tower kernel: preclear_disk.s[14549]: segfault at 29e5dd8e ip 0808a400 sp bf8a6180 error 4 in bash[8048000+a0000] Jul 11 12:08:56 Tower kernel: preclear_disk.s[15210]: segfault at 803db25 ip 0803db25 sp bf8a9040 error 14 in bash[8048000+a0000]

thanks for help. to be honest i'm not sure how to read smart report or what it means. attached here. 5 Reallocated_Sector_Ct 0x0033 170 170 140 Pre-fail Always - 236 197 Current_Pending_Sector 0x0032 197 196 000 Old_age Always - 1029 There are 1029 sectors pending re-allocation and 236 that have already been re-allocated. (Those pending are waiting for a subsequent "write" so the disk can know what should be in the sector it re-locates.) That disk has failed. Do not trust it with your data. RMA it. Joe L.

you probably already saw this, but there are tons of un-readable sectors on that disk. Get a smart report to see the full statistics. smartctl -a /dev/sda look for sectors pending re-allocation. Jan 2 16:33:13 Tower kernel: res 51/40:00:f0:c1:9a/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:13 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:13 Tower kernel: ata3.00: error: { UNC } Jan 2 16:33:18 Tower kernel: ata3.00: configured for UDMA/133 Jan 2 16:33:18 Tower kernel: ata3: EH complete Jan 2 16:33:20 Tower kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jan 2 16:33:20 Tower kernel: ata3.00: BMDMA stat 0x4 Jan 2 16:33:20 Tower kernel: ata3.00: failed command: READ DMA EXT Jan 2 16:33:20 Tower kernel: ata3.00: cmd 25/00:08:f0:c1:9a/00:00:ad:00:00/e0 tag 0 dma 4096 in Jan 2 16:33:20 Tower kernel: res 51/40:00:f0:c1:9a/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:20 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:20 Tower kernel: ata3.00: error: { UNC } Jan 2 16:33:23 Tower kernel: ata3.00: configured for UDMA/133 Jan 2 16:33:23 Tower kernel: sd 4:0:0:0: [sda] Unhandled sense code Jan 2 16:33:23 Tower kernel: sd 4:0:0:0: [sda] Result: hostbyte=0x00 driverbyte=0x08 Jan 2 16:33:23 Tower kernel: sd 4:0:0:0: [sda] Sense Key : 0x3 [current] [descriptor] Jan 2 16:33:23 Tower kernel: Descriptor sense data with sense descriptors (in hex): Jan 2 16:33:23 Tower kernel: 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 Jan 2 16:33:23 Tower kernel: ad 9a c1 f0 Jan 2 16:33:23 Tower kernel: sd 4:0:0:0: [sda] ASC=0x11 ASCQ=0x4 Jan 2 16:33:23 Tower kernel: sd 4:0:0:0: [sda] CDB: cdb[0]=0x28: 28 00 ad 9a c1 f0 00 00 08 00 Jan 2 16:33:23 Tower kernel: end_request: I/O error, dev sda, sector 2912600560 Jan 2 16:33:23 Tower kernel: Buffer I/O error on device sda, logical block 364075070 Jan 2 16:33:23 Tower kernel: ata3: EH complete Jan 2 16:33:36 Tower kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jan 2 16:33:36 Tower kernel: ata3.00: BMDMA stat 0x5 Jan 2 16:33:36 Tower kernel: ata3.00: failed command: READ DMA Jan 2 16:33:36 Tower kernel: ata3.00: cmd c8/00:00:c8:56:41/00:00:00:00:00/e0 tag 0 dma 131072 in Jan 2 16:33:36 Tower kernel: res 51/40:4f:77:57:41/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:36 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:36 Tower kernel: ata3.00: error: { UNC } Jan 2 16:33:40 Tower kernel: ata3.00: configured for UDMA/133 Jan 2 16:33:40 Tower kernel: ata3: EH complete Jan 2 16:33:43 Tower kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jan 2 16:33:43 Tower kernel: ata3.00: BMDMA stat 0x5 Jan 2 16:33:43 Tower kernel: ata3.00: failed command: READ DMA Jan 2 16:33:43 Tower kernel: ata3.00: cmd c8/00:00:c8:56:41/00:00:00:00:00/e0 tag 0 dma 131072 in Jan 2 16:33:43 Tower kernel: res 51/40:4f:77:57:41/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:43 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:43 Tower kernel: ata3.00: error: { UNC } Jan 2 16:33:47 Tower kernel: ata3.00: configured for UDMA/133 Jan 2 16:33:47 Tower kernel: ata3: EH complete Jan 2 16:33:49 Tower kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jan 2 16:33:49 Tower kernel: ata3.00: BMDMA stat 0x5 Jan 2 16:33:49 Tower kernel: ata3.00: failed command: READ DMA Jan 2 16:33:49 Tower kernel: ata3.00: cmd c8/00:00:c8:56:41/00:00:00:00:00/e0 tag 0 dma 131072 in Jan 2 16:33:49 Tower kernel: res 51/40:4f:77:57:41/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:49 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:49 Tower kernel: ata3.00: error: { UNC } Jan 2 16:33:52 Tower kernel: ata3.00: configured for UDMA/133 Jan 2 16:33:52 Tower kernel: ata3: EH complete Jan 2 16:33:55 Tower kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0 Jan 2 16:33:55 Tower kernel: ata3.00: BMDMA stat 0x5 Jan 2 16:33:55 Tower kernel: ata3.00: failed command: READ DMA Jan 2 16:33:55 Tower kernel: ata3.00: cmd c8/00:00:c8:56:41/00:00:00:00:00/e0 tag 0 dma 131072 in Jan 2 16:33:55 Tower kernel: res 51/40:4f:77:57:41/40:00:ad:00:00/e0 Emask 0x9 (media error) Jan 2 16:33:55 Tower kernel: ata3.00: status: { DRDY ERR } Jan 2 16:33:55 Tower kernel: ata3.00: error: { UNC }

we don't know, you did not attach a system log.

All I can say is I'm happy it helped, but adding the "sleep 5" where you did should have had no effect of the subsequent smartctl exit status, yet you say it does. The only way that could happen is it smartctl is not properly initializing one of the variables used internally and somehow inheriting some memory contents from a prior command that is not zero. Perhaps it is some side effect of running the hdparm command on the disk, just a few lines above, to get its size, and the disk too some time to recover from that operation... I really don't know. It certainly does no harm to add the sleep where you did. Initially, I thought you were adding it between the invocation of smartctl and the evaluation of its exit status. Joe L.

I've no idea... Best I can offer is to suggest you invoke it as sh -xv preclear_disk.sh /dev/sdX and see what it is doing. I certainly cannot fix your exit status if your smart command is exiting abnormally. Joe L. Thanks Joe L. Just thought I asked since it only occurs within the script, not from the command line or from within my test script which is practically identical to the offending lines in the pre-clear script. Anyhow I'll do some more test and run the command as you suggested. Edit: Did more tests, I added a 5 second sleep at line 1450 and that seem to resolve the issue. yes, but it sounds like the logic is now looking at the exit status of the added "sleep" command, and it (sleep) always is successful at sleeping. Happy it works for you, but it does not solve the issue. It will not affect the preclear regardless, as it is just used to get the disk temperature.

I've no idea... Best I can offer is to suggest you invoke it as sh -xv preclear_disk.sh /dev/sdX and see what it is doing. I certainly cannot fix your exit status if your smart command is exiting abnormally. Joe L.

When you run the command, are you checking its exit status? the preclear script is, and your smartctl is exiting with a non-zero exit status. Try the 1.12 version of the preclear_disk.sh script attached to this post: http://lime-technology.com/forum/index.php?topic=4068.msg128289#msg128289 It is version 1.12... I had originally posted it there to allow those with 3TB drives to give it a try, but it also should fix your issue too. (as long as your disk will report with just smartctl -a /dev/sdX ) I would really appreciate some help because I am still receiving the error with version 12. Now the disk that is being tested is connected to SASLP card. Yet I receive a normal output when I run the command smartctl -a /dev/sdb. Furthermore I wrote a small bash script that looks like follows: http://pastebin.com/42nSRWXZ And it exits with a code of 0. Yet when I modified the your preclear script and inserted an echo line between lines 1456 and 1457 that said "echo $smartstat" I got an exit code 4. Can you please advise me as to what exactly is occurring and how I may resolve the issue. have you tried the "-D" option to preclear_disk.sh ??

A few pieces of cardboard/wood/plastic on the sides and front of the rack, and it would keep the kids, animals, and wife from accidentally touching the drives, etc. Would be very easy to make wife/pet/kid-proof and still look very presentable. Much tougher to keep you out... Got to admire the air-flow across the drives. ;D Joe L.

I'm happy it might be as simple as that. As I said, in the past those with similar drives that "randomly" returned inconsistent values (other than zeros) when subsequently read would drive their array owners insane, as once the disk is in the array the only symptom would be random parity errors when parity is checked, and there would be absolutely no way, other than by process of elimination, to figure out the hardware that was faulty. Joe L.

It says that the post-read detected the disk did not have all zeros when read. This could be caused by almost anything from Bad memory, a bad disk, a bad disk controller, a bad motherboard chipset (early Nforce had this), or a bad power supply. These types of errors are exactly why the test for zeros was added to the preclear-post-read. They cause hair-loss. (because you will pull your hair out trying to find elusive parity errors if the drive is added to the array) About the only hardware you can eliminate is the "mouse" It is unlikely to be the cause of the errors. I see another preclear_disk.sh run in your future. Joe L.

That is the final SMART report. It still shows no error. Where is the preclear report itself. (I have no idea what the myMain does, so can offer no help with the screen-shot) What version of the preclear_disk.sh did you use? Type: preclear_disk.sh -v to find out. So far, you've shown me nothing that says the disk failed the pre-clear. A SMART report does not indicate anything about the pre-clear process. The preclear_reports folder should have had three files. The initial SMART report, the final SMART report, and the preclear results. Post the contents of the results file, not the SMART reports. Joe L.

where does it say it failed? I don't see it. Please attach the preclear report. Without it I'm unable to interpret what you are seeing. It should be in the preclear_reports directory on your flash drive.

While I understand the logic to using a single 12V rail supply (no need for load balancing etc) is there any reason you can't use a quad rail supply? (as I have a spare lying around with I think about 18 amps on each rail) http://www.shoppingsquare.com.au/p_2960_GreatWall_GW700SEL_700_WATT_TRUE_POWER_SUPPLY Yes, typically only 1 of the rails is available for the hard disks. The others are reserved for the CPU power, the PCIe connectors. That would then give you basically 16 to 18 Amps of capacity to run the disks, fans, and in some cases, the motherboard too. See here for an example of a supply I purchased, but knowing it suited my needs, since I intend to re-wire it: http://lime-technology.com/forum/index.php?topic=6879.msg66778#msg66778 It is a 4 rail supply, with 1 rail used for all the disk connectors, but that same rail is shared with the motherboard connector too. The problem is, with most multi-rail power supplies, YOU CANNOT LOAD BALANCE without internally re-wiring the supply and voiding your warranty. If you are looking to power more than 5 or 6 disks, get a single rail power supply. The supply you linked to is a two rail supply, odds are very high you have about 15 Amps capacity for disks. (and likely not even that) If both rails are actually 18 Amps in capacity, then even the 700 Watt rating is highly suspect. 2 * 18Amps * 12Volts = 432 watts. That would indicate the 5 volt rail would need to have the remaining capacity? But I highly doubt it has a 53 Amp rating... Joe L.

Instead of pleading to others, and complaining about how their attempt to help you does not work with your brain-damaged media player, I strongly suggest you look at the existing suggestions, learn a tiny bit about linux shell, enough to put a program in the background, and make it work yourself. The formula for success seems to be a way to not go to sleep while your external device is waiting for a response, but at a time soon thereafter. Use the "at" comand Create your own user-script. (should take about 4 lines of script) It should basically say echo "echo 3 >/proc/acpi/sleep" | at now + 1 minute Or as an alternative: putting commands in the background echo "going to sleep" ( shell commands go here to put server to sleep and subsequently restore it when woken ) >/dev/null 2>&1 & Then, invoke YOUR new user-script, which puts the server to sleep.

perfectly normal, BUT your version of the preclear script is probably at least 10 versions old. Please always download and use the newest one. Dang, I didn't know. I am going to look for the newest version right now. Thx Joe Actually, very newest is here: http://lime-technology.com/forum/index.php?topic=4068.msg128289#msg128289 It still is in need of a few wording changes when used with a 3TB drive, as it still refers to the resulting partition starting on sector 64 on a >2.2TB drive, but it is entirely functional even if it "fibs" when you use it with a 3TB drive.

perfectly normal, BUT your version of the preclear script is probably at least 10 versions old. Please always download and use the newest one.

When you run the command, are you checking its exit status? the preclear script is, and your smartctl is exiting with a non-zero exit status. Try the 1.12 version of the preclear_disk.sh script attached to this post: http://lime-technology.com/forum/index.php?topic=4068.msg128289#msg128289 It is version 1.12... I had originally posted it there to allow those with 3TB drives to give it a try, but it also should fix your issue too. (as long as your disk will report with just smartctl -a /dev/sdX )

It never cared about hda vs. sda disks. It was always using the "-d ata" option to the smartctl command it uses. That was necessary on much of the hardware over the past 5 years. In other words, the drive behind the SATA or IDE controller was an ATA command set. Now, with a newer smartctl version it autodetects the disk better and the "-d ata" is no longer needed and in fact gets in the way with some chipsets. The 1.12beta version of the preclear script first tries the smartctl command without the "-d ata" and if it works without it, it does not use it. If it does not work, it tries with "-d ata". Joe L.

Actually, even 7 hours is a short time compared to many other RAID implementations when you have to break the raid array and rebuild it. For an array of 3TB drives, it would be a LONG time. At one point, Tom sold pre-cleared/burned in drives. My original pair of Hitachi 500Gig drives were supplied by him when I purchased my server from him 5+years ago. The drives were $300+ each. We've come a long way now that a 2TB on sale is > $70. Add the drive, see what happens. Two reports of the software not recognizing the pre-clear signature will help to convince him. But need to point him to this thread, or, better yet, post in the announcement thread for 5.0beta7.

Do you think or can you confirm with Tom, maybe as the code is right now when unRAID see's a drive >2TB (or 2.2) it expects to see not only the GPT (table) but a GUID in that GPT and if it does not see a GUID in that GPT, then it believes it needs to be cleared...? I am assuming this based on reading the wiki "GPT retains the MBR entry as the first sector on the disk followed by a primary partition table header, the actual beginning of a GPT." OR Maybe Also per wiki "GPT also provides redundancy, writing the GPT header and partition table both at the beginning and at the end of the disk.". Could Tom have forgotten to mention the second GPT to you, maybe? No, he did not forget the second GPT. Both copies of the GPT are created when the GPT partition is created. He specifically said only the MBR is to be populated when pre-cleared, exactly as I am,and the remainder of the disk all zeros. I have no way to contact Tom that you do not have. PM or email to [email protected]. The actual logic to when to use a GPT partition is when the disk size in blocks is greater than or equal to 0xFFFFFFFF You can still have an MBR based partition if the disk is < 2.2TB, or if the disk reports its size in 4k blocks you can have a 16TB disk with an MBR only partition. (problem is, no disk reports its blocks as 4k. They all revert to reporting their size in 512 byte blocks. Too much embedded logic around that 512 byte size in the bios and disk drivers I suppose.) all you can do at this point is send Tom an e-mail, point him to this thread and see if he responds, or try adding the 3TB precleared disk without waiting. If it does not get recognized, it will just mean you array will be offline for 7 hours or so while it writes zeros to it again..

Those are both exactly as expected. The first is not a valid pre-clear signature, but then you did not perform the full-pre-clear. It is exactly as expected with the short test. The second is a valid pre-clear signature as described by Tom @ lime-technologies. The GPT protective MBR (first 512 bytes you dumped) was written by the pre-clear script. The actual GPT will be written when you assign the drive to the array. I suspect you'll find the same as bjp999, that unRAID will not respect the preclear signature but proceed to clear the drive again. You array will be off-line for 7 or so hours while this is occurring, so do not add the drive when the family is expecting to watch a movie. Do it before retiring for bed. That way, if it does clear the drive, the array will be ready again the next morning. Joe L.

That is as Tom @ lime-tech described it needs to be in his communication to me about the GPT protective MBR pre-clear signature.

After it is done, and before assigning the drive to the unRAID array, you can post the results of this command to assist me in knowing if it worked as expected on your 3 TB drive: dd if=/dev/sda count=1 2>/dev/null | od -x -A x (substituting your disk for /dev/sda )