when I am executing SET MAX ADDRESS(0xF9) of ATA command, it is Aborting...For Aborting there are 2 reasons specified in "IBM HD Spec.pdf"
> when Volatility bit -1 for permanent removing of HPA is specified and in Address offset mode, command is aborted...
> READ_NATIVE_MAX_ADDRESS should be immediately called before SET MAX ADDRESS, otherwise command is aborted...

I wish to remove HPA temperorily and take care of the above 2 precautions, still SET_MAX command is aborting... IDENTIFY_DEVICE, READ_NATIVE_MAX_ADDRESS cmds are executing perfectly...

Before executing READ_NATIVE_MAX_ADDRESS, IDENTIFY_DEVICE cmd is executed...When IDENTIFY DEVICE cmd is issued 10th bit of word 82 is 0 returned by device i.e, HPA feature set is not supported...If that is the case, I'm able to execute READ_NATIVE_MAX_ADDRESS CMD and with one tool I'm able to create & remove HPA...All the SET MAX cmds are aborted....

Please send me suggestions or solution if possible for not aborting SET MAX ADDRESS cmd....

Regards,
mohan.

Please let me know that under which platform you are working ?


regards

PS : Where to find "IBM HD Spec.pdf" .

I'm thankful to u for ur prompt response...I'm working under Windows....

Please refer " hitachigst.com/tech/techlib.nsf/techdocs/85256AB80..." and " Protected Area –Locking Proposal 1 Background 2 Principles of .." in Google, so that u can get more info regarding SET MAX cmds...

I'm eagerly waiting for ur precious suggestions....

Best Regards,
Mohan.

Hehehe, so I will go to google to look docs about ATA commands ?
Ok, and in return I will give you this:
just go to T13 org and you will find some answers for your question.
If you was there in first moment you did not had to waste your time writting post in places whre noone possible have answer to your question.
Bah

Already I have read t13.org...Based on this and other docs, I observed the following are the causes for aborting...

1.) READ_NATIVE_MAX_ADDRESS should be immediately called before SET MAX ADDRESS, otherwise command is aborted...
2.) DRDY set equal to one before executing cmd otherwise cmd is aborted
3.) if the cmd is not supported or maximum value requested exceeds the device capacity, cmd is aborted.
4.)If device is in Set Max Locked mode, cmd is aborted

Everything I checked, but I'm unable to check 2nd cond...It can be checked if it is written in device driver by getting status from port but it is not supposed... It should be written through windows API calls...

Hm, take DOS and write simple programm sending ATA commands, after you having working source for DOS you will be know what you send commands correctly, and can port it to the Windows...

_________________
best regards, vi http://www.scspb.ru/pchdd/ http://pchdd.narod.ru

Already we have written in dos ( directly accessing the ports) ie, but the calls are different from window API calls...In windows, I should test status of Devce controller whether it is ready i.e, DRDY...Is there any Ioctl for knowing the status...

Any suggestions will be appreciated and thanks in advance...

Windows version? What API you use? etc.

May be this API don't provide such low level stuf as DRDY etc?

_________________
best regards, vi http://www.scspb.ru/pchdd/ http://pchdd.narod.ru

DeviceIoControl(hDevice, IOCTL_IDE_PASS_THROUGH, pAPT, Size, pAPT, Size, &BytesReturned, (LPOVERLAPPED)NULL);

pAPT is structure obj filled with
/* IDE/ATA command request structure in windows*/
//0 - IDE_FEATURE_OFFSET
//1 - IDE_NSECTOR_OFFSET
//2 - IDE_SECTOR_OFFSET
//3 - IDE_LCYL_OFFSET
//4 - IDE_HCYL_OFFSET
//5 - IDE_SELECT_OFFSET
//6 - Command

Any suggestions will be appreciated and thanks in advance...

Hi,

In the windows environment it is not so easy tracking the drive's behaviour than in DOS. So I would suggest writing a working code in DOS as U've already tried.
I would try a known good drive that supports HPA (test it with MHDD), then write code in DOS to work with that.
If it works, I would try the drive in the subject.

regards,
pepe

Hi,
Writing in Dos and Windows is entirely different...In Dos, we directly interact with ports through inp & outp calls...In Windows we interact with Device Controller that's what we use DeviceIoControl API call for sending ATA cmds...So we don't think writing in DOS...It should not be written through Device Driver...

Ofcourse, I use Maxtor 6L020L1 hard disk...It supports HPA...READ_NATIVE_MAX_ADDRESS & IDENTIFY_DEVICE are successfully executed

In os_win32.c file, I observed "ATA data-out cmd are unable to execute if smart ioctl doesn't support" but SET_MAX is not data-out cmd, still it is aborting...

Any suggestions will be appreciated and thanks in advance...

Regards,
mohan.

I encounterd the same problem when I use DeviceIoControl to send ATA command SET MAX ADDRESS. The status of DeviceIoControl is success, but the status register of IDE controller is 0x51 which means an error occured. After check the error register, I found the error bit 3 is set to one (ABORT).
Any suggestions will be appreciated.

DeviceIoControl is not good, even with PASS_THROUGH. The fact is that you are still working with Windows, not with the drive directly and Windows decides what commands to let through and what not.
In fact, it lets through only non-destructive commands like SMART, IDENTIFY_DEVICE, SLEEP, STANDBY, READ_SECTOR etc.
SET_MAX_ADDRESS works, but still there are problems with it. For example, I have 200GB drive with HPA set to 100GB. Windows sees that it's under 128GB and thinks that drive works only with 28bit commands and when I send a valid 48bit command to reset HPA it just aborts it.
So, ABORT error that you see was sent to you not by the drive, but by the Windows. For some reason, Windows didn't like your command (try to play with Device register - most likely because of it).

To sum up, DeviceIoControl sucks
The best way to work directly with the drive on the register level is to use GiveIO. You will have to disable Secondary port and work with the registers as in DOS, without any interference from Windows drivers.