Mountain View, CA
reply to Gem
Re: [WIN8] windows 8 adversely affects XP hard drivesYup, that's what I wanted to see (barring some formatting mistakes but it's good enough).
Your drive has no LBA or sector-level issues. LBA 0 is perfectly readable/writeable from my perspective. That's good!
"So then what was that error in SeaTools, talking about sector 0?"
The error, in actuality, was self-induced by the software itself (i.e. a bug or a design mistake).
The error you saw was actually a direct result of what you see in your SMART error log. You can see clearly that roughly 10 hours ago (at power-on hours count 11246) a piece of software attempted to issue ATA command 0x37 (SET MAX ADDRESS EXT) to the drive, which the drive rejected (and a proper error status was returned). That particular command is usually used to modify the HPA region of a hard disk, which contains the advertised maximum LBA count of the drive (i.e. it's maximum capacity).
I'm going to skip all the low-level technical details of the ATA CDB decoding and so on -- yes, I really can read all of that stuff (it takes me some time along with reference materials, but I do understand it!), and yes really the below is the short/terse version! -- and instead try to summarise what happened:
1. SeaTools attempted to issue SET MAX ADDRESS EXT, specifically telling the drive *not* to change the advertised maximum LBA count/capacity if a hardware bus reset occurs or a power-on reset was encountered. (This is a safety net to ensure that if an I/O error is later encountered while, say, testing the drive during an extended/long test or surface scan, that the drive not actually retain that capacity change):
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name
-- -- -- -- -- -- -- -- ---------------- --------------------
37 00 01 af 9e a1 f0 00 00:09:13.238 SET MAX ADDRESS EXT
2. In the same command, attempted to set the maximum LBA count to a value which I cannot determine due to limitations of the SMART error log; the SMART error log only saves the least-significant byte of each CDB field, and some of those fields are actually much longer than 8-bits (some are 48-bit for example). So I can't see what it was truly trying to set the limit to, but it tried it. However, the error status (keep reading) indicates the software tried to set the capacity to something smaller than the native maximum LBA count.
3. The drive received the CDB successfully, but rejected it:
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
10 51 01 af 9e a1 f0
These registers decoded -- specifically ER -- indicates the drive returned 0x10 (bit 4 set). Bit 4 = IDNF (ID Not Found). This behaviour is fully 100% defined per T13/2015-D rev 3 specification:
If the Maximum LBA ... is less than the native max address, then the ID Not Found bit ... shall be set to one if a previous non-volatile SET MAX ADDRESS EXT command has been processed since the last power-on or hardware reset. ...ST was 0x51, which means bits 0, 4, and 6 were set. Bits 4 and 6 are irrelevant to the situation, and bit 0 being set means an error condition occurred.
4. The same software that submit this CDB did not expect an error condition, and therefore erroneously reported a failure for LBA 0. Naughty naughty -- bug in SeaTools. :-)
So as I said further up -- your drive is perfectly healthy.
I should note, however, that you did not run an actual SMART-level long (sometimes called "extended") scan, which at the firmware level attempts a read of all LBAs and reports back any failures in the SMART self-test log along with an LBA number. You did, though, state that you "ran a surface scan test", which if I remember right, inside SeaTools, simply issues LBA reads from the OS (DOS) itself for every LBA and reports back any failures. That's perfectly fine to do and a good indication that every LBA is readable (and most certainly writeable).
So your issue with MBR problems, partition tables, etc. is something software-level and not disk-level.
Hope this sheds some light on things -- welcome to what engineers do. :-)
P.S. -- Consider yourself extra proud: this thread has given me an idea for a utility to write that would greatly benefit most of the Internet, when/if I have the time.
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.
Re: [WIN8] windows 8 wasn't to blame... Thank you, Koitsu, Norwegian, Ozo, Aurgathor, Plencnerb, Kilroy, and everyone else who helped with this problem...
...especially Koistu and Norwegian who so patiently walked me through everything there was to do.
Let me guess, you have resolved your problem?
What was the solution in this case?
Keep it simple, it'll become complex by itself...
Drive checked out as A-Okay. To get it to boot in XP it requires changes to be made to make the drive appear to XP to be less than its full 160GB in size.
That's interesting. I vaguely remember there used to be a 128G limit a while ago, but I'd think an Abit AG8 i915 motherboard should not suffer from that. But you've got it working, and that's what counts.
Wacky Races 2012!
reply to koitsu
Re: [WIN8] windows 8 adversely affects XP hard drives
said by koitsu: Hmmm, one would expect a manufacturer's own tool to work error free with their own drives....
4. The same software that submit this CDB did not expect an error condition, and therefore erroneously reported a failure for LBA 0. Naughty naughty -- bug in SeaTools.
Wacky Races 2012!
reply to aurgathor
Re: [WIN8] windows 8 wasn't to blame... This drive has always been problematic. It would boot fine on some boards, but not when formatted as a 160GB drive on other older boards. Seagate Barracuda 7200.6 Firmware 3.06.
Perhaps it was a problem because this 160GB was produced around 2004-2006 if I remember correctly. Maybe drive manufacturers have different firmware on later drives that help newer motherboards get around the 128GB barrier more easily than this one can.
Once again, thank to everyone.