🚀 go-pugleaf

Richard RUDEK <x@invalid.zeta.org.au> wrote in
message news:3979a943.642282@news.zeta.org.au...
> Tpsa <root@fbatut.com.pl> wrote
>> User AWP <nomail@thanks.com.au> wrote

>>>>>> An Award BIOS with MODE set to AUTO will attempt
>>>>>> to determine the translation from the partition table.

>>> How does it detect a drive with no partitions and no formatting?

>> Yeah, I'm currently working on a custom OS, and it uses a diffrent
>> filesysem - and the bios (AWARD 4.51 PG) detects the disk correctly!

> Hmmm, I didn't say, rather didn't mean to say that the partition table
> was used *solely* in the determination of the Translation method used, but
> rather, a partition table *effected* how this translation was determined.

You actually said that the use of an AUTO drive type could explain
the symptoms Ian saw, the drive going bad, and coming good after
various attempts at data recovery. THAT claim doesnt hold up logically.
Particularly when the drive was audibly protesting at bad sectors.

> A simple example of this is if you create a partition, say the first
> partition table entry, manually choosing CHS mode in the BIOS. Once
> created, change the BIOS to "Auto". Now what does the BIOS report ?

Sure, no one has ever disputed that you can get a change in mapping
between CHS and logical blocks if you partion and format a drive with
a particular drive type and then change that drive type and reboot.

Thats an entirely separate issue to the drive just going bad in use
when an AUTO drive type is used and producing massive numbers
of bad sectors with the drive audibly protesting at the bad sectors.

A change in the mapping between CHS and logical blocks can certainly
make partitions vanish, the directory structure get all buggered up,
particularly with other than the first primary partition, but it doesnt
produce massive numbers of bad sectors at the drive hardware level.

> Second senario. Continuing on from above, Change the BIOS
> to use "Large", now create a second partition table entry (might
> have to use a third party util to do this), then change the BIOS
> to "Auto" once again. What does it report this time ?

Again, you can certainly deliberately demonstrate a change
to the mapping between CHS and logical blocks etc, but
thats not what was being discussed with Ian's problem.

> Wether or not the BIOS then contains a bug from either of these points
> on, would be dependant upon the brand and version of the BIOS.

Its not so much a bug as different ways of working
around the basic limitations of the original CHS use by
DOS and Win at the 512MB, 2GB, 4GB and 8GB levels.

> The effect that I was suggesting, was when *a* "bug"
> confused simple programs like the DOS mode FDISK
> and FORMAT programs, which use BIOS 13h services.

You actually claimed that the result Ian got can be seen with
the AUTO drive type. It cant with the drive just going bad.
Because those different approaches to mapping between
CHS and logical blocks just dont arise when the drive is
partitioned and formatted with an AUTO setting and the
drive continues to be used with an AUTO drive type.

Even if the cmos settings are lost, the drive type will still revert
to AUTO and thats the main advantage in using the AUTO drive
type, even if you lose the cmos values, it STILL wont bite you.

Ditto with moving the drive on the IDE controllers etc, with all
the drive types set to AUTO, the same mapping will be used
regardless of what you do with moving the drive around physically.

> As for "recalibrations", if I make request for a sector beyond
> a certain range, some drives will indeed perform a "Recal".

Yes, but that cant happen with an AUTO drive type
which auto enables LBA because of the size of the drive.
The drive only ever gets requests in terms of logical blocks
and the dont recalibrate when the request is outside the
range of logical block numbers that the drive knows its got.

And you cant explain the very slow copying of
what data could be seen. That was clearly doing
repeated retrys on the data and getting it eventually.

> So, if you trigger and bug in the BIOS 13h service(s), and this bug
> in turn incorrectly creates a large or negative LBA request, when
> that command finally makes it to the hard disk, some drive will "recal".

Nope. You cant get negative LBA requests, its just an unsigned block
number. And it cant have been block numbers outside what the drive has,
otherwise that very slow copying of what data was visible wouldnt happen.
Repeated retrys cant get data from blocks that dont exist.