I've got a new 120GB Maxtor Drive.

I used it to upgrade one of my TiVos with a larger disk.

Now it worked fine in the Tivo [booted and ran],
but I forgot to enable to BAsh prompt so yanked it out to mount the disk on a PC and run it up under MFSTools 2.0 boot CD.

Now, the drive refuses to unlock - I've tried "qunlock" and once it appeared to work [showed up as 120GB drive in my Bios], but not since.

My Bios shows its stuck at 9MB in size and no matter what I've tried it won't unlock.
Even put it back in the Tivo, thinking that might fix it, but no such Luck, Tivo boot prom reports "Err4" when it tries to unlock it and of course can't boot off it.
The disk that was in the Tivo before works fine.

I suspect the unlock command has accidentally locked the drive with some unknown key and thats that.

So, is there anyway to "unlock" such a locked drive? I don't care if it erases the contents or whatever as right now the Disk has nothing on it I can't put back.

Its more a nuisance as otherwise I have to return the drive to the local supplier and get them to understand whats wrong with it, and hope they'll give me a replacement unit without too much hassle/cost. If not I've got a useless 120GB drive.

I've checked the drive out in PowerMax software, but it stays stuck a 9MB in size but PowerMax says its all ok.

Any ideas anyone?

The drive is a Maxtor Diamondplus9 120GB disk made in Dec2002 according to the label on it.

A follow up post.
I found out that all IDE drives that implement locking must also implement a security erase option/command which will overwrite the contents of the drive with zeroes and unlock the drive, so it can be used again. This is exactly what I want.

I haven't found any utilities around that will let me do this - must be some for Linux somewhere, most of the DOS/PC ones I find are part of forensics type data recovery programs thatcost $$ and I don't need that sort of tool. That will cost more than the drive.

I would gather it must be a real simple utility - all it does is send a "seceurity erase" command to the IDE drive and sit back and wait.

Any IDE kernel hackers out there? Mark any comments?

I can write a very small program to trigger it for you.

The only uncertainty I have is that the stock Linux IDE driver may "time out" on the operation (it generally takes around an hour on most drives)..

-ml

If you can put the drive into a regular Linux box, then grab hdparm-5.3 (stock with new distros, or download it from ibiblio.org

And run "hdparm -I" on the drive (uppercase 'I'), and post the output here.

This should tell us more about the situation.

Cheers

and for that matter, I'd *love* to also have a copy of /proc/ide/hd?/identify from that drive, just as reference for the library of drive info I keep here.

Thanks

Mmm.. from reading the spec on SECURITY ERASE UNIT, it appears that one cannot even reformat the drive to recover unless the correct password is supplied..

-ml

This could be something simpler than the SECURITY feature set.. the output of "hdparm -I" and /proc/ide/hd?/identify should tell the story.

-ml

Yup. I've got a dud 120GB Maxtor as well
I think it's actually something to do with Maxtor drives as people don't have the same problems with other brands like Quantum or IBM. In my case, it decided to lock permanently after me yanking it out and unlocking it a few times.

It's a very flashy looking paperweight for me at the moment. Does a great job though

- Trevor

Heres the output from hdparm v5.2 [couldn't find a binary of 5.3 for Redhat].
I ran hdparm -I /dev/hda

/dev/hda:



ATA device, with non-removable media

	Model Number:       Maxtor 6Y120L0                          

	Serial Number:      Y40QEKSE            

	Firmware Revision:  YAR41VW0

Standards:

	Supported: 7 6 5 4 

	Likely used: 7

Configuration:

	Logical		max	current

	cylinders	19	19

	heads		16	16

	sectors/track	63	63

	--

	CHS current addressable sectors:      19152

	LBA    user addressable sectors:      20000

	device size with M = 1024*1024:           9 MBytes

	device size with M = 1000*1000:          10 MBytes 

Capabilities:

	LBA, IORDY(can be disabled)

	Queue depth: 1

	Standby timer values: spec'd by Standard, no device specific minimum

	R/W multiple sector transfer: Max = 16	Current = 16

	Advanced power management level: unknown setting (0x0000)

	Recommended acoustic management value: 192, current value: 192

	DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 udma5 udma6 

	     Cycle time: min=120ns recommended=120ns

	PIO: pio0 pio1 pio2 pio3 pio4 

	     Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

	Enabled	Supported:

	   *	NOP cmd

	   *	READ BUFFER cmd

	   *	WRITE BUFFER cmd

	   *	Host Protected Area feature set

	   *	Look-ahead

	   *	Write cache

	   *	Power Management feature set

		Security Mode feature set

	   *	SMART feature set

	   *	FLUSH CACHE EXT command

	   *	Mandatory FLUSH CACHE command 

	   *	Device Configuration Overlay feature set 

	   *	Automatic Acoustic Management feature set 

		SET MAX security extension

		Advanced Power Management feature set

	   *	DOWNLOAD MICROCODE cmd

	   *	SMART self-test 

	   *	SMART error logging 

Security: 

	Master password revision code = 65534

		supported

	not	enabled

	not	locked

	not	frozen

	not	expired: security count

	not	supported: enhanced erase

HW reset results:

	CBLID- above Vih

	Device num = 0 determined by the jumper

Checksum: correct

Attached is the output from /proc/ide/hda/identify

Now looking at the output from hdparm -I [above] can't see if the problem is the unlock - doesn't look like the drive is locked to me.
Still the info will be in the relevant parts of the attached identify output.

Okay, good. There's good hope for a full recovery here.

There are two feature sets that could be hiding the real capacity of the drive:

* Host Protected Area feature set <--- most likely candidate

and/or

* Device Configuration Overlay feature set

The second one is particularly nasty, as what it does is cause the drive to LIE about supported features/capacities.. the existing hdparm cannot get around it, either. But I've been contemplating a new release that knows about such LIEs, and can bypass them when need be.

But here, it's probably just the "SET MAX ADDRESS" thing from the HPA feature set that's nigging things. This can be undone with a small program, running under a RECENT (2.4.21 recommended) Linux kernel.

I haven't written this program yet, but it's not terribly hard .. just takes an hour or two with the right kind of drive on hand to test it with. No, you don't need to send me your drive . I just need to get back home where my IDE lab is at (out of town right now).

Nag me.

Not sure if it's significant but those two features are present and enabled on my unlocked Maxtor drive as well. It's never been in the TiVo however as it's in one of my PCs.

- Trevor doesn't have much of an idea about IDE and ATA standards so is probably wrong

That's normal (both things, plus the postnote.. )

This probably ties with the evidence.

See when I first put the drive in my PC [a Dell L733r model], it came up as a 9MB so I qunlocked it using the "normal" utility for this and rebooted as per the instructions, and then the drive showed up as a 120GB unit in the BIOS settings.

Then when I exited the BIOS setup [which rebooted the PC], the drive went back to 9MB and has stayed there ever since.

I suspect that maybe the Dell's BIOS is writing stuff like SET MAX ADDRESS into the HPA or overlay features and this is being used forevermore.

So, the real problem could be the shonky Dell BIOS.
I have tried another machine, which is a different Dell PC and it reports the same problem [9MB].

The Dell BIOS is a little weird as it lets you switch the mode of the BIOS setting for the drive from "Auto" [the default] to "User" or some other settings, like ATAPI CDROM etc.
But the disk "size" field in the BIOS setting stays fixed at 9MB.
Previously (when drive was unlocked) it showed up correctly as 120GB [but still not changeable], so I suspect the BIOS has told the drive you're now 9MB in size and it believes it.

The Dells I am using are about 2.5 years old, so the BIOS'es are probably hopelessly out of date for these modern drives and OVerlay/HPA implementations.

I don't have a newer PC to try fiddling with this on. [or maybe an even older non-DELL might be worth a crack as it might unjam things].

Worst case, your utility program sounds like it will be useful to have around.
If I know the drive can probably be recovered ok, I will go buy another drive so I can get my Tivo on the air again, until you get some time to do the utility you mentioned if we still have the problem.

I can't believe that this is unique to Dell BIOSes though and I am wondering if there is not a flaw in the Firmware in the drive itself.

Tman - is your drive firmware the same as mine [see the above hdparm output info]

I may call the local Maxtor reseller I bought my drive from tomorrow to see if they know of this problem and if there is a fix for it.
The Maxtor website is not very useful for this sort of thing.

Hi Mark, just prodding this thread to keep it in your view.
Do you have a likely ETA for this 'fix'?

Also, when it comes time to deploy this, any chance of a Bootable floppy [or CD - whatever is simplest] image with the right stuff [program] in it to save me having to locate the right kernel to run it on?