ogi

Hey Joe, not sure if you missed my post, but given the weird results of this preclear, I could use your input Thanks! Sorry, I did miss it. This line is weird... 65535 sectors were pending re-allocation after zero of disk in cycle 1 of 1. I would not expect for sectors to be pending re-allocation after being written. (and it is the highest count I've ever seen) Makes me want to RMA the disk for buggy firmware. (did you perhaps run two pre-clears on it at the same time, with one writing, while another was reading?) In any case, there were still 47 sectors that it could not re-allocate, and on that I'd RMA the drive. You should, if you decide to keep the drive put it through at least one more preclear cycle, and if cannot come through with all the sectors re-allocated, and no new ones detected as unreadable, RMA it. Well, instantly that number calls out to me, 65535 being the maximum number a two byte integer (short) can be, that alone (being exactly 2^16-1) sounds dodgy. Yeah, I saw this comment somewhere else on this forum, but regardless of that number not being a coincidence, is there anything that can be done in terms of identifying the cause, or is it a potentially an issue with the preclear script?

Hey Joe, not sure if you missed my post, but given the weird results of this preclear, I could use your input Thanks! Sorry, I did miss it. This line is weird... 65535 sectors were pending re-allocation after zero of disk in cycle 1 of 1. I would not expect for sectors to be pending re-allocation after being written. (and it is the highest count I've ever seen) Makes me want to RMA the disk for buggy firmware. (did you perhaps run two pre-clears on it at the same time, with one writing, while another was reading?) In any case, there were still 47 sectors that it could not re-allocate, and on that I'd RMA the drive. You should, if you decide to keep the drive put it through at least one more preclear cycle, and if cannot come through with all the sectors re-allocated, and no new ones detected as unreadable, RMA it. Didn't run 2 preclears at the same time... I decided to RMA the drive, as I already had a different drive ready to RMA, just needed to drop it off. I like a column of 0's on the preclear report and when I see large numbers like this, I figured RMA was the likely suggestion. Thanks again!

Hey Joe, not sure if you missed my post, but given the weird results of this preclear, I could use your input Thanks!

I could also use some help with some preclear result interpretations ========================================================================1.13 == invoked as: ./preclear_disk.sh -A /dev/sdr == WDC WD20EARS-00MVWB0 WD-WCAZA0358422 == Disk /dev/sdr has been successfully precleared == with a starting sector of 64 == Ran 1 cycle == == Using :Read block size = 8225280 Bytes == Last Cycle's Pre Read Time : 7:06:00 (78 MB/s) == Last Cycle's Zeroing time : 5:57:45 (93 MB/s) == Last Cycle's Post Read Time : 13:49:47 (40 MB/s) == Last Cycle's Total Time : 26:54:32 == == Total Elapsed Time 26:54:32 == == Disk Start Temperature: 22C == == Current Disk Temperature: 33C, == ============================================================================ ** Changed attributes in files: /tmp/smart_start_sdr /tmp/smart_finish_sdr ATTRIBUTE NEW_VAL OLD_VAL FAILURE_THRESHOLD STATUS RAW_VALUE Temperature_Celsius = 117 128 0 ok 33 No SMART attributes are FAILING_NOW 1 sector was pending re-allocation before the start of the preclear. 1 sector was pending re-allocation after pre-read in cycle 1 of 1. 65535 sectors were pending re-allocation after zero of disk in cycle 1 of 1. 48 sectors are pending re-allocation at the end of the preclear, a change of 47 in the number of sectors pending re-allocation. 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. ============================================================================ I've attached the other relevant preclear files to this post. preclear_finish__WD-WCAZA0358422_2013-02-26.txt preclear_rpt__WD-WCAZA0358422_2013-02-26.txt preclear_start__WD-WCAZA0358422_2013-02-26.txt

When booting, enter The BIOS and select the UEFI shell as a boot device. From there, you can flash the M1015. Ogi

I found a utility for dos, but now I got this errot Failed to initialize PAL Any clue what that means ?? //Peter That sounds similar to flashing a M1015 on an incompatible MB. Yup, However it's simple enough to get around. That portion of the flashing procedure should be done in a UEFI shell.