ATA IDENTIFY

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

I don't know Loonix, but I think BOTH mean: 0xEC and 0xA1.
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).
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.
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

>>    both IDENTIFYs aborted

...
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.
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.
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

> ....
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

On 15.03.2020 14:01, James Harris wrote:
...
You don't need a whole OS...
a few lines inserted into any old DOS debug can use INT13/42 for a test.
couldn't get this (page error)
copied, may need some time to read and correct interpret its meaning.

[...] thanks for warning, I always suspected GOGGLE to behave weird.
Yes, a main reason to write your own.
__
wolfgang

> ....
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?
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.
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.
Mm, an interesting topic.


--
James Harris

On 16.03.2020 10:41, James Harris wrote:
...
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

...
Here's an update on this old thread.

The problem turned out to be that the actuator arm had frozen such that
the heads were not retracted but were over the disk surfaces. I don't
know why it had not retracted the heads but this is apparently a known
problem which some call 'stiction'.

I found out that while it will harm a drive and render it unsafe to use
for future storage it is possible to open a drive to try to fix the
problem even without a cleanroom - as in videos such as

https://youtu.be/F5Y7BniaRXg

After I opened the drive I found it surprisingly easy to turn the
platters and retract the heads. I guess mine had not stuck as badly as
some others. I saw one video where carrying out this procedure led to a
loud and alarming scraping noise. But I seem to have been fortunate.

When I used ddrescue to get back what I could from the drive I'm glad to
say it reported 99.99% success. Despite that, there were still lots of
errors reported by an fsck on the NTFS partition.

In the end I decided not to let fsck repair the partition but to copy
the rescued image to a new drive and let the Windows driver see what it
made of it on boot. Windows reported that it had not been shut down
properly and then took some time chuntering but booted to a normal desktop.

I don't know, as yet, which of the files on the disk, if any, still have
uncorrected errors but the end result is a working system on which most
of the data should have been recovered. :-)

I suspect it's going to take a long time to reorganise the data files,
find any important ones which have damage, and replace them with older
backups, where necessary.

...
I don't think that that laptop has SMART in the BIOS but, in this case,
I am not sure it would have helped if it had since the heads sticking to
the disk could possibly have occurred suddenly and without warning.

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. :-(


--
James Harris

On 05.03.2021 10:20, James Harris wrote:
...
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