Discussion:
ATA IDENTIFY
(too old to reply)
James Harris
2020-02-27 11:49:04 UTC
Permalink
A few comments and queries on the ATA IDENTIFY command.

This issue came up because my PC locked up and wouldn't reboot. On
putting the PC's (SATA) disk in a server the Linux kernel said, among
other things,

both IDENTIFYs aborted

That raises a few questions. I see that there is an IDENTIFY DEVICE
command 0xEC and I know it returns 512 bytes of data about the disk. But
what's the other IDENTIFY?

Could it be that:

* Linux tried the command twice
* Linux tried the IDENTIFY PACKET DEVICE command 0xA1
* there's some way to tell the disk to look for a backup IDENTIFY sector

or something else?

Interestingly, from what I have read I gather that the disk is likely to
have stored the IDENTIFY data in hidden sectors - indicating that
there's a part of the disk that I presume is completely inaccessible to
an OS by any other mechanism.

Do you think there's any way I could read the disk - even just as a
block device - if it does not even know its own IDENTIFY data? Could I,
for example, substitute the IDENTIFY data for an identical or similar disk?

Much as I'd like to get the data back perhaps the most interesting
question is what an OS ought to do when it cannot read IDENTIFY data
from a disk but maybe can read normal sectors. (The OS may not be able
to use the disk normally but rather than giving up altogether I am
thinking that perhaps the OS could make it easier for someone to do data
recovery.) What do you think?
--
James Harris
wolfgang kern
2020-03-02 09:40:39 UTC
Permalink
Post by James Harris
A few comments and queries on the ATA IDENTIFY command.
This issue came up because my PC locked up and wouldn't reboot. On
putting the PC's (SATA) disk in a server the Linux kernel said, among
other things,
  both IDENTIFYs aborted
That raises a few questions. I see that there is an IDENTIFY DEVICE
command 0xEC and I know it returns 512 bytes of data about the disk. But
what's the other IDENTIFY?
* Linux tried the command twice
* Linux tried the IDENTIFY PACKET DEVICE command 0xA1
* there's some way to tell the disk to look for a backup IDENTIFY sector
or something else?
I don't know Loonix, but I think BOTH mean: 0xEC and 0xA1.
Post by James Harris
Interestingly, from what I have read I gather that the disk is likely to
have stored the IDENTIFY data in hidden sectors - indicating that
there's a part of the disk that I presume is completely inaccessible to
an OS by any other mechanism.
Identify may not be on hidden sectors, some drives report this 512 bytes
even when the drive doesn't spin or it felt asleep (seems it's a ROM).
Post by James Harris
Do you think there's any way I could read the disk - even just as a
block device - if it does not even know its own IDENTIFY data? Could I,
for example, substitute the IDENTIFY data for an identical or similar disk?
You can try to read LBA-0 in native SATA mode (acts like IDE).
And if this worked you can read other LBAs as well.
Post by James Harris
Much as I'd like to get the data back perhaps the most interesting
question is what an OS ought to do when it cannot read IDENTIFY data
from a disk but maybe can read normal sectors. (The OS may not be able
to use the disk normally but rather than giving up altogether I am
thinking that perhaps the OS could make it easier for someone to do data
recovery.) What do you think?
Wouldn't your BIOS warn with a S.M.A.R.T-alert ?
Or does it just ignore the drive?

My OS tells "disk error", I then can try to read LBA_0 with my debugger.

I encountered such error once when a drive had no supply voltage. It
could also be that your BIOS set SATA-mode to 'raid' or more worse UFI.
__
wolfgang
James Harris
2020-03-15 12:03:36 UTC
Permalink
Post by wolfgang kern
   both IDENTIFYs aborted
...
Post by wolfgang kern
Do you think there's any way I could read the disk - even just as a
block device - if it does not even know its own IDENTIFY data? Could
I, for example, substitute the IDENTIFY data for an identical or
similar disk?
You can try to read LBA-0 in native SATA mode (acts like IDE).
And if this worked you can read other LBAs as well.
As I don't have a working OS I've been looking into how I could do this.
In case it's of any use to someone else the most promising seems to be
the sg interface under recent versions of Linux.

For IO the idea is that the user sets up the parameters in a header,
makes the call, and gets the results back. You can see the idea in the
header fields which are documented at

https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io_hdr_t.html

I gather the sg layer translates between SCSI and ATA and effectively
issues the corresponding ATA calls.
Post by wolfgang kern
Much as I'd like to get the data back perhaps the most interesting
question is what an OS ought to do when it cannot read IDENTIFY data
from a disk but maybe can read normal sectors. (The OS may not be able
to use the disk normally but rather than giving up altogether I am
thinking that perhaps the OS could make it easier for someone to do
data recovery.) What do you think?
Wouldn't your BIOS warn with a  S.M.A.R.T-alert ?
Or does it just ignore the drive?
I can't see anything relevant in the laptop's BIOS setup screens which
is a bit odd given that it's a relatively recent machine - at least for
me(!). For the record it's a Dell Precision M6600 with Core i7 CPU. It
shows some BIOS logs but they have nothing about impending disk failure
in them.

One thing which may be relevant is that the disk which failed is an SSHD
type

https://en.wikipedia.org/wiki/Hybrid_drive

which has a mix of hard drive and flash. For all I know just now it may
have had an electronics failure rather than a physical one.
Post by wolfgang kern
My OS tells "disk error", I then can try to read LBA_0 with my debugger.
I encountered such error once when a drive had no supply voltage. It
could also be that your BIOS set SATA-mode to 'raid' or more worse UFI.
I presume you mean EFI/UEFI. The laptop does have two related boot options:

1. Legacy

This lets the user choose the boot sources: floppy, HDD, CD, etc and
their order.

2. UEFI

This apparently looks for \EFI\Microsoft\Boot\bootmgfw.efi. Or, at least
that's what it says at the moment (without the original disk in the
machine).
--
James Harris
James Harris
2020-03-15 13:01:19 UTC
Permalink
Post by James Harris
Post by wolfgang kern
   both IDENTIFYs aborted
....
Post by wolfgang kern
Do you think there's any way I could read the disk - even just as a
block device - if it does not even know its own IDENTIFY data? Could
I, for example, substitute the IDENTIFY data for an identical or
similar disk?
You can try to read LBA-0 in native SATA mode (acts like IDE).
And if this worked you can read other LBAs as well.
As I don't have a working OS I've been looking into how I could do this.
In case it's of any use to someone else the most promising seems to be
the sg interface under recent versions of Linux.
For IO the idea is that the user sets up the parameters in a header,
makes the call, and gets the results back. You can see the idea in the
header fields which are documented at
  https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io_hdr_t.html
I gather the sg layer translates between SCSI and ATA and effectively
issues the corresponding ATA calls.
There's a good prose writeup of sg at

http://sg.danny.cz/sg/p/scsi-generic_long.txt




As an aside to all this can I add that working with file replication
software can be very, very stressful...!

My backup strategy on the machine which failed was basically to have to
reinstall apps but to have data replicated to the cloud. So when I
pulled out an old laptop all I should have had to do to get my data back
was install the cloud-sync software on it and I would be able to carry on.

That worked very will indeed for Dropbox. I installed and configured
Dropbox and it downloaded from the cloud the latest versions of all the
files which I had protected in that way. It worked perfectly. I have all
my project files and other documents back and was able to carry on as
normal. Yay!

But I had other files - mainly media such as photos and videos - on
Google Drive rather than Dropbox. And they were, AIUI, synchronised by
me having Google Backup and Sync installed and running.

Why did I choose Google Backup and Sync? Because while mirroring
services have space limits, Google has a special provision for media
files. If one lets Google store the cloud versions of media in a
compressed form it doesn't count their sizes against one's allocation
limit! That's brilliant for most of my photos. The compression is plenty
good enough and the photos look the same to me. As a result, although in
reality I probably have many gigabytes of media files which Google is
storing it says I am using only 37 megabytes of my allocation!

However, the Google documentation is not the best. And setting Google
Backup and Sync up on this old PC is scary. When I installed it the
first thing it started to do was to delete files! To make things worse,
while I could see the names of the files it had deleted I couldn't find
out from anything in the program where it had been deleting the files
from. That meant I didn't know if they were just old copies which should
have been deleted or current ones in the cloud which it was deleting
because they didn't exist on the PC.

To cut the story short I called Google Support and they helped by
showing where the files had gone from and how to get them back. Given
that, I decided to uninstall Backup and Sync, get the files back to
where they had been deleted from (my PC), make some changes to the file
layout and start again. But that ran into another problem: Backup and
Sync would not uninstall while I had a window open to the copies in the
cloud.

To be clear, that was a browser window. Why would Backup and Sync
require such a window to be closed down before it would uninstall? AISI
any cloud copies should be completely irrelevant to whether I have
Backup and Sync on this PC. I can't think of any reason for Google
wanting that window to be closed. The fear is that Google thinks I am
closing my cloud account and so it would delete everything therein!!!

Surely they wouldn't do that...?! I know this may sound paranoid. But
without clear documentation on what it will do and without another
backup copy elsewhere I can't think of why they would require that
window be closed, and I just can't take the chance.

I'm going to have to do some more research and possibly contact Google
Support again. But, as I say, this stuff can be rather stressful!

Perhaps the whole issue of backup and restore should be better handled
by an OS.
--
James Harris
wolfgang kern
2020-03-16 07:39:05 UTC
Permalink
On 15.03.2020 14:01, James Harris wrote:
...
Post by James Harris
Post by James Harris
Post by wolfgang kern
You can try to read LBA-0 in native SATA mode (acts like IDE).
And if this worked you can read other LBAs as well.
As I don't have a working OS I've been looking into how I could do
this. In case it's of any use to someone else the most promising seems
to be the sg interface under recent versions of Linux.
You don't need a whole OS...
a few lines inserted into any old DOS debug can use INT13/42 for a test.
Post by James Harris
Post by James Harris
For IO the idea is that the user sets up the parameters in a header,
makes the call, and gets the results back. You can see the idea in the
header fields which are documented at
   https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io_hdr_t.html
couldn't get this (page error)
Post by James Harris
Post by James Harris
I gather the sg layer translates between SCSI and ATA and effectively
issues the corresponding ATA calls.
There's a good prose writeup of sg at
  http://sg.danny.cz/sg/p/scsi-generic_long.txt
copied, may need some time to read and correct interpret its meaning.

[...] thanks for warning, I always suspected GOGGLE to behave weird.
Post by James Harris
Perhaps the whole issue of backup and restore should be better handled
by an OS.
Yes, a main reason to write your own.
__
wolfgang
James Harris
2020-03-16 09:41:24 UTC
Permalink
Post by wolfgang kern
....
Post by James Harris
Post by James Harris
Post by wolfgang kern
You can try to read LBA-0 in native SATA mode (acts like IDE).
And if this worked you can read other LBAs as well.
As I don't have a working OS I've been looking into how I could do
this. In case it's of any use to someone else the most promising
seems to be the sg interface under recent versions of Linux.
You don't need a whole OS...
a few lines inserted into any old DOS debug can use INT13/42 for a test.
Well, I could tell /Linux/ to read disk blocks, at least by byte offset
such as

from 0 for 512

to get LBA 0. But even if it did that I am not sure it would handle many
more such reads sensibly given that it has been unable to read the
identify data. I have similar if not lower expectations about the BIOS.
I can't remember what the BIOS reported but if identify failed I would
expect the BIOS to say there was no disk attached and refuse even to try
to read it. Do you think I am wrong?
Post by wolfgang kern
Post by James Harris
Post by James Harris
For IO the idea is that the user sets up the parameters in a header,
makes the call, and gets the results back. You can see the idea in
the header fields which are documented at
   https://www.tldp.org/HOWTO/SCSI-Generic-HOWTO/sg_io_hdr_t.html
couldn't get this (page error)
That's odd. The link works for me.

I really left the note about sg for anyone who happened to be reading
this thread later. I didn't think you personally would be interested in
sg as it's a high-level interface to features that you already have
low-level access to. The only potentially interesting thing about it to
you may be that it's lower level than many such high-level interfaces!
In practical terms it gives the programmer access to a lot of detail,
including things like returning the full SCSI sense buffer. (On which,
here's another link you may not have access to!)

https://www.tldp.org/HOWTO/archived/SCSI-Programming-HOWTO/SCSI-Programming-HOWTO-10.html

But sg is still a kludge and not as clean as the level you, having your
own OS, can work at.
Post by wolfgang kern
Post by James Harris
Post by James Harris
I gather the sg layer translates between SCSI and ATA and effectively
issues the corresponding ATA calls.
There's a good prose writeup of sg at
   http://sg.danny.cz/sg/p/scsi-generic_long.txt
copied, may need some time to read and correct interpret its meaning.
[...] thanks for warning, I always suspected GOGGLE to behave weird.
I should say that I think that Google's Backup and Sync probably would
not delete my online files **but** with the lack of good documentation
(at least that I have found) and lack of good information from within
the software itself, and with it apparently not giving the chance to
configure it before it starts doing things with my files ... entrusting
it with years' worth of data can be just a little bit too scary.

Re. OS design, all I can say is that by 'good documentation' I don't
mean a whole list of micro-step how-tos but a conceptual model as to how
the system works so that people understand how to interact with it.
Post by wolfgang kern
Post by James Harris
Perhaps the whole issue of backup and restore should be better handled
by an OS.
Yes, a main reason to write your own.
Mm, an interesting topic.
--
James Harris
wolfgang kern
2020-03-17 20:28:08 UTC
Permalink
On 16.03.2020 10:41, James Harris wrote:
...
Post by James Harris
Post by wolfgang kern
You don't need a whole OS...
a few lines inserted into any old DOS debug can use INT13/42 for a test.
Well, I could tell /Linux/ to read disk blocks, at least by byte offset
such as
  from 0 for 512
to get LBA 0. But even if it did that I am not sure it would handle many
more such reads sensibly given that it has been unable to read the
identify data. I have similar if not lower expectations about the BIOS.
I can't remember what the BIOS reported but if identify failed I would
expect the BIOS to say there was no disk attached and refuse even to try
to read it. Do you think I am wrong?
If the BIOS wont detect it because of missing Identify then INT13 fails.
Some older BIOS may detect disks different (ie: IRQ repond on reset).

But if your mobo has 6 SATA connectors then the 5th and the 6th are on
port 01F0.. resp. 0170.. and can be read as if they were IDE-drives.
(SATA ports 1..4 are found in PCI-config only).

I once expanded my old ATA-IDE and read/write SATA with IDE-styled
ports. So this were only a few bytes of code to add.
__
wolfgang
James Harris
2021-03-05 09:20:31 UTC
Permalink
This post might be inappropriate. Click to display it.
wolfgang kern
2021-03-06 07:05:21 UTC
Permalink
On 05.03.2021 10:20, James Harris wrote:
...
Post by James Harris
I don't know why the heads stuck to the disk but there they were. Nasty!
What with one thing and another - mainly that this was of low priority,
but some other things as well - it's taken me about a year to get the
original data back. :-(
now at least you had much more luck than me, I couldn't recover a single
byte on three defective (lost head contact) HDs after I opened them.
The only recoverable HDs were the ones with a stuck spindle and burned
motor drive electonics.
__
wolfgang

Continue reading on narkive:
Loading...