🚀 go-pugleaf

Ian Lowery wrote:
 
> I had a very mysterious hard drive crash and resurrection recently,
> and it has me rather mystified.

Quantum has a free download diagnostic program. Use it. If it doesn't
pass, use the warranty.
-- 
Understanding is a fountain of life to those who have it . . . .	
Proverbs 16:22 NKJV

 Team OS/2

Felix Miata  ***  http://mrmazda.members.atlantic.net

Hi,

Rather that the drive itself, maybe the controler on drive stuffed up
somewhat - possibly a hot joint somewhere. Or it may have been something
wrong with the drive cable connection. Pulling out and putting back may
of fixed it.

Joe

Ian Lowery wrote:
> 
> I had a very mysterious hard drive crash and resurrection recently,
> and it has me rather mystified.
> 
> The drive is a Quantum KA, 13 Gb, and only 8 months old. It has
> multiple logical drives in the extended partition (FAT16) and a small
> primary partition to allow booting into multiple operating systems.
> 
snip snip - since Netscape complains
> Anybody got any clues as to what happened?
> 
> Cheers
> 
> Ian
> 
> ------------------------------------------------
> To reply, remove "nospam" from my e-mail address.

Ian Lowery <ianl@nospam.curie.dialix.com.au> wrote in
message news:oor9nscq5ldltuk16h9il5atrgfrhqtusi@4ax.com...

> I had a very mysterious hard drive crash and
> resurrection recently, and it has me rather mystified.

> The drive is a Quantum KA, 13 Gb, and only 8 months old. It has
> multiple logical drives in the extended partition (FAT16) and a small
> primary partition to allow booting into multiple operating systems.

> The problem started when no OSs became bootable, major corruption
> was found on the primary partition, and all logical drives in the extended
> partition had disappeared. I booted a vanilla WIn 98 version of DOS
> from floppy and ran a surface scan from Norton Disk Doctor which
> found oodles of bad sectors in the primary partition.

> I resurrected all but the first of the logical drives in the extended
> partition and then tried copying essential stuff from these drives
> to a second physical drive. At this point it seemed as though there
> was a serious problem with the corrupted drive, for although it is
> a fast drive normally, it took 4 hours to copy 500 MB, apparently
> doing multiple seeks and retries on dodgey sectors.

> In the FAT on the primary partition I marked all sectors as unused
> (hence good) and ran Norton Disk Doctor again. Even in normal
> mode the surface scan was taking ages and was finding bad sectors
> everywhere. Thinking it may be Disk Doctor I aborted, remarked
> the sectors as unused, and ran ScanDisk with the same results.

> I decided to FDISK the drive and create one FAT 32 partition which
> I would surface test and find all the bad sectors. FDISK reported that
> the drive had integrity problems but created the drive anyway, and I
> set about formatting it. No go, FORMAT.COM (with no switches) reported
> that the system area of the drive was stuffed and the drive was unuseable.

> I booted into Windows 98 on the other hard drive and tried formatting
> from within My Computer. Low and behold, after about 10 minutes the
> program reported that the drive had been formatted. I then ran
> ScanDisk from within Windows and it reported that there were no
> errors. Not believing it, I went to DOS and ran Norton Disc Doctor's
> surface scan, and it found no errors, nor did the DOS based ScanDisk.

> I repartitioned to FAT16 and reinstalled the system as was,
> and it has had no problem since. I have rerun comprehensive
> surface scans and there have been no bad sectors.

> So what happened?

Most likely the classic intermittent fault. You did have
a hardware problem, then it went away. Thats possible
on the connection between the heads and the logic
card on the drive, or even just in the IDE cable.

> The bad sectors were real, they weren't an artefact from
> a corrupted FAT, I had marked all sectors in the FAT as
> unused (and hence good), and the surface scan programs
> then marked them as bad. Every surface scan I ran took
> ages to run, with constant (and noisy) retries over the
> same areas. Both FDISK and FORMAT reported problems.

Yes, you did have a real fault.

> Then there was the dreadfully slow transfer of data from the
> logical drives. These had no logical problems and they would have
> been unaffected by the missing logical drive and the corrupt primary
> partition. I had also let the drive return to room temperature a
> number of times, and tried it in another machine with identical results.

> To all appearances there were serious problems with the drive, but
> somehow things magically fixed themselves, so what happened?

There are plenty of intermittent faults. Complete pain in the arse.

> All that I can think of is that perhaps the drive has
> a self healing facility and excluded sectors as being
> bad and then hid them (rewriting its internal bad
> track list) when Windows attempted to format it.

You'd expect to lose lots of capacity and you'd be sure to get more
developing over time too. Sectors dont just go bad for no reason.
Either you've got a poor electrical joint in the connection to the
heads etc or the magnetic material is getting ploughed up.

> The drive does use Smart technology although the BIOS does not support it.

SMART is more about reporting things going bad than fixing them.

> Anybody got any clues as to what happened?

Bet its an intermittent fault. Keep backing up religiously.

Ian Lowery <ianl@nospam.curie.dialix.com.au> wrote:

[snip]

>Anybody got any clues as to what happened? 

I'd say, you probably ran into a side effect of using the "Auto" detect
feature(s) of your BIOS. If the partition table gets corrupted, it can cause
the BIOS to decide to use a different type drive translation, other than
LBA. This can then lead to BIOS not being able to access certain sectors,
and perhaps trigger a bug somewhere.

I'd doubt that the drives' sector relocation played as huge a role as might
be suggested by your description, but it may well have with the MBR and/or
parts of the primary partition.

Download the Quantum Data Protection System utility (QDPSATA.EXE) from
Quantum, and see what it has to say about the drive. Run it with the /L
switch (the bloody license is ~ 5 pages long). eg QDPSATA /L

If you tell it to "Print the results", it will create a file called
TEMP.TXT.

  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

random faults are a big pain in butt.  the last time i had random faults
(hard drive would just lock up), i replaced the drive and everything was
fine.  unfortunately, it could be anything, including your hard drive
controller, cables, etc.

In comp.sys.ibm.pc.hardware.storage Ian Lowery <ianl@nospam.curie.dialix.com.au> wrote:
> I had a very mysterious hard drive crash and resurrection recently,
> and it has me rather mystified.

> The drive is a Quantum KA, 13 Gb, and only 8 months old. It has
> multiple logical drives in the extended partition (FAT16) and a small
> primary partition to allow booting into multiple operating systems.

> The problem started when no OSs became bootable, major corruption was
> found on the primary partition, and all logical drives in the extended
> partition had disappeared. I booted a vanilla WIn 98 version of DOS
> from floppy and ran a surface scan from Norton Disk Doctor which found
> oodles of bad sectors in the primary partition. 

> I resurrected all but the first of the logical drives in the extended
> partition and then tried copying essential stuff from these drives to
> a second physical drive. At this point it seemed as though there was a
> serious problem with the corrupted drive, for although it is a fast
> drive normally, it took 4 hours to copy 500 MB, apparently doing
> multiple seeks and retries on dodgey sectors.

> In the FAT on the primary partition I marked all sectors as unused
> (hence good) and ran Norton Disk Doctor again. Even in normal mode the
> surface scan was taking ages and was finding bad sectors everywhere.
> Thinking it may be Disk Doctor I aborted, remarked the sectors as
> unused, and ran ScanDisk with the same results. 

> I decided to FDISK the drive and create one FAT 32 partition which I
> would surface test and find all the bad sectors. FDISK reported that
> the drive had integrity problems but created the drive anyway, and I
> set about formatting it. No go, FORMAT.COM (with no switches) reported
> that the system area of the drive was stuffed and the drive was
> unuseable.

> I booted into Windows 98 on the other hard drive and tried formatting
> from within My Computer. Low and behold, after about 10 minutes the
> program reported that the drive had been formatted. I then ran
> ScanDisk from within Windows and it reported that there were no
> errors. Not believing it, I went to DOS and ran Norton Disc Doctor's
> surface scan, and it found no errors, nor did the DOS based ScanDisk.

> I repartitioned to FAT16 and reinstalled the system as was, and it has
> had no problem since. I have rerun comprehensive surface scans and
> there have been no bad sectors.

> So what happened? The bad sectors were real, they weren't an artefact
> from a corrupted FAT, I had marked all sectors in the FAT as unused
> (and hence good), and the surface scan programs then marked them as
> bad. Every surface scan I ran took ages to run, with constant (and
> noisy) retries over the same areas. Both FDISK and FORMAT reported
> problems. 

> Then there was the dreadfully slow transfer of data from the logical
> drives. These had no logical problems and they would have been
> unaffected by the missing logical drive and the corrupt primary
> partition. I had also let the drive return to room temperature a
> number of times, and tried it in another machine with identical
> results.

> To all appearances there were serious problems with the drive, but
> somehow things magically fixed themselves, so what happened?

> All that I can think of is that perhaps the drive has a self healing
> facility and excluded sectors as being bad and then hid them
> (rewriting its internal bad track list) when Windows attempted to
> format it. The drive does use Smart technology although the BIOS does
> not support it.

> Anybody got any clues as to what happened? 

> Cheers

> Ian

> ------------------------------------------------
> To reply, remove "nospam" from my e-mail address.

-- 
_________________________
Remove ".invalid" to reply

"Rod Speed" <rod_speed@yahoo.com> wrote:

>Richard RUDEK <x@invalid.zeta.org.au> wrote

>> If the partition table gets corrupted, it can cause the BIOS to
>> decide to use a different type drive translation, other than LBA.
>
>The bios AUTO setting doesnt use the partition
>table. It just asks the drive about its parameters,
>and the drive doesnt use the partition table either.

This is definitely wrong. An Award BIOS with MODE set to AUTO will
attempt to determine the translation from the partition table.

Award also will look at the partition table, if MODE is set to NORMAL,
LARGE and maybe LBA. If the partition table does not match the
setting, the BIOS will then return a disk geometry that looks as
expected for the partition table, but the disk will be read and
written at completely wrong locations.

This is a really nasty bug.
-- 
Svend Olaf

I would suspect a virus which you didn't get rid of until
you did a complete wipe, or a serious problem in the
partition table.  

Ian Lowery wrote:
> 
> I had a very mysterious hard drive crash and resurrection recently,
> and it has me rather mystified.
> 
> The drive is a Quantum KA, 13 Gb, and only 8 months old. It has
> multiple logical drives in the extended partition (FAT16) and a small
> primary partition to allow booting into multiple operating systems.
> 
> The problem started when no OSs became bootable, major corruption was
> found on the primary partition, and all logical drives in the extended
> partition had disappeared. I booted a vanilla WIn 98 version of DOS
> from floppy and ran a surface scan from Norton Disk Doctor which found
> oodles of bad sectors in the primary partition.
> 
> I resurrected all but the first of the logical drives in the extended
> partition and then tried copying essential stuff from these drives to
> a second physical drive. At this point it seemed as though there was a
> serious problem with the corrupted drive, for although it is a fast
> drive normally, it took 4 hours to copy 500 MB, apparently doing
> multiple seeks and retries on dodgey sectors.
> 
> In the FAT on the primary partition I marked all sectors as unused
> (hence good) and ran Norton Disk Doctor again. Even in normal mode the
> surface scan was taking ages and was finding bad sectors everywhere.
> Thinking it may be Disk Doctor I aborted, remarked the sectors as
> unused, and ran ScanDisk with the same results.
> 
> I decided to FDISK the drive and create one FAT 32 partition which I
> would surface test and find all the bad sectors. FDISK reported that
> the drive had integrity problems but created the drive anyway, and I
> set about formatting it. No go, FORMAT.COM (with no switches) reported
> that the system area of the drive was stuffed and the drive was
> unuseable.
> 
> I booted into Windows 98 on the other hard drive and tried formatting
> from within My Computer. Low and behold, after about 10 minutes the
> program reported that the drive had been formatted. I then ran
> ScanDisk from within Windows and it reported that there were no
> errors. Not believing it, I went to DOS and ran Norton Disc Doctor's
> surface scan, and it found no errors, nor did the DOS based ScanDisk.
> 
> I repartitioned to FAT16 and reinstalled the system as was, and it has
> had no problem since. I have rerun comprehensive surface scans and
> there have been no bad sectors.
> 
> So what happened? The bad sectors were real, they weren't an artefact
> from a corrupted FAT, I had marked all sectors in the FAT as unused
> (and hence good), and the surface scan programs then marked them as
> bad. Every surface scan I ran took ages to run, with constant (and
> noisy) retries over the same areas. Both FDISK and FORMAT reported
> problems.
> 
> Then there was the dreadfully slow transfer of data from the logical
> drives. These had no logical problems and they would have been
> unaffected by the missing logical drive and the corrupt primary
> partition. I had also let the drive return to room temperature a
> number of times, and tried it in another machine with identical
> results.
> 
> To all appearances there were serious problems with the drive, but
> somehow things magically fixed themselves, so what happened?
> 
> All that I can think of is that perhaps the drive has a self healing
> facility and excluded sectors as being bad and then hid them
> (rewriting its internal bad track list) when Windows attempted to
> format it. The drive does use Smart technology although the BIOS does
> not support it.
> 
> Anybody got any clues as to what happened?
> 
> Cheers
> 
> Ian
> 
> ------------------------------------------------
> To reply, remove "nospam" from my e-mail address.

-- 
Mike Powers
I was very lonely until I became part of the problem.

Richard RUDEK <x@invalid.zeta.org.au> wrote in message news:3976fa9e.41626850@news.zeta.org.au...
> Ian Lowery <ianl@nospam.curie.dialix.com.au> wrote:

>> Anybody got any clues as to what happened?

> I'd say, you probably ran into a side effect of
> using the "Auto" detect feature(s) of your BIOS.

I doubt it.

> If the partition table gets corrupted, it can cause the BIOS to
> decide to use a different type drive translation, other than LBA.

The bios AUTO setting doesnt use the partition
table. It just asks the drive about its parameters,
and the drive doesnt use the partition table either.

> This can then lead to BIOS not being able to access
> certain sectors, and perhaps trigger a bug somewhere.

Cant see that either. The mapping from CHS to logical block
numbers can certainly be affected by the geometry detail in the
master boot record, but thats an OS level problem, not a physical
drive level problem. And that just gets the mapping wrong, so the
drive contents make no sense, doesnt produce a very high level
of unreadable sectors with the drive obviously recalibrating when
attempting to read a particular sector. It just gets the wrong
sector when the wrong logical block number is arrived at.

> I'd doubt that the drives' sector relocation played as huge
> a role as might be suggested by your description, but it may
> well have with the MBR and/or parts of the primary partition.

Yes, with the failure to format, but not with the very high error rate.

> Download the Quantum Data Protection System utility (QDPSATA.EXE)
> from Quantum, and see what it has to say about the drive. Run it with
> the /L switch (the bloody license is ~ 5 pages long). eg QDPSATA /L

> If you tell it to "Print the results", it will create a file called TEMP.TXT.

But that isnt likely to say much if its an intermittent
fault, particularly if it was a fault external to the drive.

Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote in
message news:39787361.3040784@news.inet.tele.dk...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Richard RUDEK <x@invalid.zeta.org.au> wrote

>>> I'd say, you probably ran into a side effect of
>>> using the "Auto" detect feature(s) of your BIOS.

>> I doubt it.

>>> If the partition table gets corrupted, it can cause the BIOS to
>>> decide to use a different type drive translation, other than LBA.

>> The bios AUTO setting doesnt use the partition
>> table. It just asks the drive about its parameters,
>> and the drive doesnt use the partition table either.

> This is definitely wrong.

We'll see.

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

What evidence do you have for that assertion ?

How can it when the format of the partition table varys with the OS ?

> Award also will look at the partition table, if MODE
> is set to NORMAL, LARGE and maybe LBA.

What was being discussed was AUTO, not any one of those.

> If the partition table does not match the setting,

Doesnt arise with AUTO mode. And if the master boot
record got corrupted, the bios doesnt have the geometry
data from the MBR anyway and has to use JUST the data
the drive returns when queried about its details, just like
it has to do with a drive with no MBR or partition table.

> the BIOS will then return a disk geometry that looks
> as expected for the partition table, but the disk will
> be read and written at completely wrong locations.

Yes, like I said, that can certainly happen, but that does
NOT produce massive numbers of bad sectors with the
drive audibly recalibrating because of the very high error rate.

> This is a really nasty bug.

You appear to be confusing the undoubted problem with changes
to the mapping between the CHS values and the LBA block numbers
that can certainly vary with the OS level mapping, and what the bios
does at boot time with an AUTO drive type, what was being discussed.

"Rod Speed" <rod_speed@yahoo.com> wrote:
>Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote in
>message news:39787361.3040784@news.inet.tele.dk...
>> Rod Speed <rod_speed@yahoo.com> wrote
>>> Richard RUDEK <x@invalid.zeta.org.au> wrote
>
>>>> I'd say, you probably ran into a side effect of
>>>> using the "Auto" detect feature(s) of your BIOS.
>
>>> I doubt it.
>
>>>> If the partition table gets corrupted, it can cause the BIOS to
>>>> decide to use a different type drive translation, other than LBA.
>
>>> The bios AUTO setting doesnt use the partition
>>> table. It just asks the drive about its parameters,
>>> and the drive doesnt use the partition table either.
>
>> This is definitely wrong.
>
>We'll see.
>
>> An Award BIOS with MODE set to AUTO will attempt
>> to determine the translation from the partition table.
>
>What evidence do you have for that assertion ?


Oh shit, here we go. 

Rod, I could ask you the same question. What evidence do you have that the
BIOS Auto setting *doesn't* use partition table data in the determination of
the correct translation to be used...

Quit simply, I noticed this behaviour a while back, and experimented. After
many hours, over a few days tinkering, I came to the conclusion that the
BIOS Hard disk "Auto" setting was indeed influenced by some/one of the
partition table entries. I honestly can't remember which brand BIOS it was,
but I'm prety sure it was a Pentium based system, thus most likely an AWARD.


I'm much too busy ATM, to play around with some test beds I have here, But
it is/was definately there. Try for your self...

As to wether this played a significant role in the "errors", I cannot
definately say, but I have had a few weird translation problems which
produced "bad clusters" when formatted - in the one case that I can
remember, the errors curiously occured after the ~508MB boundary, and was
continous from there on, so I wiped the partition table and started again. 

In fact Rod, you've suggested a number of times for people to use a Zeroing
utility of overcome some hard disk weirdities.

[snip]
  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

User Felix Miata <bogus.due2UCE@atlantic.net> wrote in message
397674BC.2425942@atlantic.net...
> Ian Lowery wrote:
>
> > I had a very mysterious hard drive crash and resurrection recently,
> > and it has me rather mystified.
>
> Quantum has a free download diagnostic program. Use it. If it doesn't
> pass, use the warranty.
> --
> Understanding is a fountain of life to those who have it . . . .
> Proverbs 16:22 NKJV
>
>  Team OS/2
>
> Felix Miata  ***  http://mrmazda.members.atlantic.net

I prefer the Seagate SeaTOOLS (it has a 'generic diagnostics', wich works
even on some old IBM 20MB drive)

User AWP <nomail@thanks.com.au> wrote in message
3978584a$0$11168$7f31c96c@news01.syd.optusnet.com.au...
> > >> 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!

Mike Powers <mpowers@inebraska.com> wrote:

>I would suspect a virus which you didn't get rid of until
>you did a complete wipe, or a serious problem in the
>partition table.  

No, virusses don't cause real bad sectors and force the drive to hunt
in its attempt to reread them. All testing was done off clean floppy
disks.

Ian Lowery

------------------------------------------------
To reply, remove "nospam" from my e-mail address.

x@invalid.zeta.org.au (Richard RUDEK) wrote:

>I'd say, you probably ran into a side effect of using the "Auto" detect
>feature(s) of your BIOS. 

No, it was in LBA mode, I never let a machine make those decisions for
me.

>Download the Quantum Data Protection System utility (QDPSATA.EXE) from
>Quantum, and see what it has to say about the drive. Run it with the /L
>switch (the bloody license is ~ 5 pages long). eg QDPSATA /L

It discovered a fault, the quick test wouldn't run. Thanks for the
info about this program.

Cheers

Ian

------------------------------------------------
To reply, remove "nospam" from my e-mail address.

svolaf@inet.uni2.dk (Svend Olaf Mikkelsen) wrote:

> "Rod Speed" <rod_speed@yahoo.com> wrote:
> 
> >> This is a really nasty bug.

> >You appear to be confusing the undoubted problem with changes
> >to the mapping between the CHS values and the LBA block numbers
> >that can certainly vary with the OS level mapping, and what the bios
> >does at boot time with an AUTO drive type, what was being discussed.
 
> The OS has nothing to do with this. Let me give you an example.
 
> Award BIOS with extended interrupt 13h (disk) support. A 9671 MB IDE
> harddisk. The disk is set to User/LBA, and the disk has a BIOS
> translation of 1232 cylinders, 255 heads, 63 sectors. With this
> translation 9664 MB are useable.
 
> A 9664 MB partition is created. The partition table is correct, and
> assumes a 255 heads translation.
 
> The disk has 19,807,200 sectors. We look at LBA sector 10,000,000
> (numbered from 0). This will be
 
> cylinder 622, head 120, sector 11
 
> Then we reboot, and enter BIOS setup. LBA mode is changed to NORMAL
> mode. A translation of 19650 cylinders, 16 heads, 63 sectors is
> displayed. We save the change and boot.
 
> Then we request the disk geometry by calling BIOS interrupt 13h. The
> answer is 1232 cylinders, 255 heads, 63 sectors.
 
> Then we call BIOS interrupt 13h, function 42h, and request LBA sector
> 10,000,000. A sector is returned.
 
> Everything looks OK, but it is definitely not sector 10,000,000 that
> is returned.
 
> Then we use interrupt 13h, function 02h, to request cylinder 622, head
> 120, sector 11.
 
> Again: Everything looks OK, but it is definitely not sector 10,000,000
> that is returned.
 
> Please note that this is only one of the Award bugs. The one that I
> called nasty.

This isn't a bug, it's a feature, incorporated in these BIOSes, for a
purpose.

Regards, Zvi
--------------------------------------------------------------------
NetZ Computing Ltd. ISRAEL  Tel. +972 3 9386868   Fax +972 3 9386869
InVircible AntiVirus Software, ResQ Disk and Data Recovery Utilities
Homepage: http://www.invircible.com   E-mail: Support@invircible.com
--------------------------------------------------------------------

"Tpsa" <root@fbatut.com.pl> wrote:

>
>User AWP <nomail@thanks.com.au> wrote in message
>3978584a$0$11168$7f31c96c@news01.syd.optusnet.com.au...
>> > >> 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.

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 ?

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 ?

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

As for "recalibrations", if I make request for a sector beyond a certain
range, some drives will indeed perform a "Recal". 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".

  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

Ian Lowery <ianl@nospam.curie.dialix.com.au> wrote:

>x@invalid.zeta.org.au (Richard RUDEK) wrote:
>
>>I'd say, you probably ran into a side effect of using the "Auto" detect
>>feature(s) of your BIOS. 
>
>No, it was in LBA mode, I never let a machine make those decisions for
>me.
>
>>Download the Quantum Data Protection System utility (QDPSATA.EXE) from
>>Quantum, and see what it has to say about the drive. Run it with the /L
>>switch (the bloody license is ~ 5 pages long). eg QDPSATA /L
>
>It discovered a fault, the quick test wouldn't run. Thanks for the
>info about this program.

Good to know, and I was glad to help. 

But it seems I've opened a can of worms... ;)
  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

"Rod Speed" <rod_speed@yahoo.com> wrote:

>Soorree, we were specifically discussing the
>use of the AUTO drive type, not that mode.

You do not seem to distinguish between "Type AUTO" and "Mode AUTO". My
comments on the NORMAL and LBA modes applies to both Type AUTO and
Type USER.

The reason I went to NORMAL mode, is that your previous statement:

>The bios AUTO setting doesnt use the partition
>table. It just asks the drive about its parameters,
>and the drive doesnt use the partition table either.

is so obviously wrong, that I would not comment further.

An Award BIOS looks at the partition table in both NORMAL, LARGE, LBA,
and AUTO mode, when determining the translation to use. And it does
this for both Type USER and Type AUTO. If the partition table contains
zeroes, it is not used.
-- 
Svend Olaf

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

Richard RUDEK <x@invalid.zeta.org.au> wrote in
message news:39784439.1930310@news.zeta.org.au...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote
>>> Rod Speed <rod_speed@yahoo.com> wrote
>>>> Richard RUDEK <x@invalid.zeta.org.au> wrote

>>>>> I'd say, you probably ran into a side effect of
>>>>> using the "Auto" detect feature(s) of your BIOS.

>>>> I doubt it.

>>>>> If the partition table gets corrupted, it can cause the BIOS to
>>>>> decide to use a different type drive translation, other than LBA.

>>>> The bios AUTO setting doesnt use the partition
>>>> table. It just asks the drive about its parameters,
>>>> and the drive doesnt use the partition table either.

>>> This is definitely wrong.

>> We'll see.

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

>> What evidence do you have for that assertion ?

> Oh shit, here we go.

> Rod, I could ask you the same question. What evidence do you
> have that the BIOS Auto setting *doesn't* use partition table data
> in the determination of the correct translation to be used...

I listed that. Most obviously with a drive which has zeros right
thru the first physical sector, there aint no geometry data to use.

And while its certainly possible for the bios to only use the geometry
data from that sector when its available, its awfully unlikely that in
Ian's case the contents of that sector got corrupted just enough to still
look like a valid partition table, but with the wrong geometry numbers.

And even if the mapping from CHS to LBA block numbers is wrong,
that does not see the drive audibly recalibrate on sector read errors,
because you still get a block number which is either within the range
the drive has or it isnt. Drives dont recalibrate when they get a
request for a block number outside the range the drive physically has.

> Quit simply, I noticed this behaviour a while back, and experimented.
> After many hours, over a few days tinkering, I came to the conclusion
> that the BIOS Hard disk "Auto" setting was indeed influenced by
> some/one of the partition table entries. I honestly can't remember
> which brand BIOS it was, but I'm prety sure it was a Pentium
> based system, thus most likely an AWARD.

That brings up the question of how adequate those experiments were.

No one disputes that the geometry data in the
MBR is indeed used for the CHS to LBA block
number mapping. Not necessarily by the bios tho.

What was being discussed was whether thats done by a bios AUTO
setting, and whether that corrupt data can result in the DRIVE seeing
read errors and audibly recalibrating when it does, and producing a
very slow copying of the data that is still visible on the drive.

Its MUCH more likely that it was actually an intermittent hardware
fault than anything to do with the AUTO setting in the bios.

> I'm much too busy ATM, to play around with some test beds
> I have here, But it is/was definately there. Try for your self...

> As to wether this played a significant role in the "errors", I cannot
> definately say, but I have had a few weird translation problems which
> produced "bad clusters" when formatted - in the one case that I can
> remember, the errors curiously occured after the ~508MB boundary, and
> was continous from there on, so I wiped the partition table and started again.

Sure, but again, thats at the OS level, not the physical drive level.

> In fact Rod, you've suggested a number of times for people
> to use a Zeroing utility of overcome some hard disk weirdities.

Yes, but thats because the OS undoubtedly uses
that data, not because the bios AUTO setting does.

"Rod Speed" <rod_speed@yahoo.com> wrote:

>> This is a really nasty bug.
>
>You appear to be confusing the undoubted problem with changes
>to the mapping between the CHS values and the LBA block numbers
>that can certainly vary with the OS level mapping, and what the bios
>does at boot time with an AUTO drive type, what was being discussed.

The OS has nothing to do with this. Let me give you an example.

Award BIOS with extended interrupt 13h (disk) support. A 9671 MB IDE
harddisk. The disk is set to User/LBA, and the disk has a BIOS
translation of 1232 cylinders, 255 heads, 63 sectors. With this
translation 9664 MB are useable.

A 9664 MB partition is created. The partition table is correct, and
assumes a 255 heads translation.

The disk has 19,807,200 sectors. We look at LBA sector 10,000,000
(numbered from 0). This will be

cylinder 622, head 120, sector 11

Then we reboot, and enter BIOS setup. LBA mode is changed to NORMAL
mode. A translation of 19650 cylinders, 16 heads, 63 sectors is
displayed. We save the change and boot.

Then we request the disk geometry by calling BIOS interrupt 13h. The
answer is 1232 cylinders, 255 heads, 63 sectors.

Then we call BIOS interrupt 13h, function 42h, and request LBA sector
10,000,000. A sector is returned.

Everything looks OK, but it is definitely not sector 10,000,000 that
is returned.

Then we use interrupt 13h, function 02h, to request cylinder 622, head
120, sector 11.

Again: Everything looks OK, but it is definitely not sector 10,000,000
that is returned.

Please note that this is only one of the Award bugs. The one that I
called nasty.
-- 
Svend Olaf

Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote in
message news:3979e6a0.798510@news.inet.tele.dk...
> Rod Speed <rod_speed@yahoo.com> wrote

>>> This is a really nasty bug.

>> You appear to be confusing the undoubted problem with changes
>> to the mapping between the CHS values and the LBA block numbers
>> that can certainly vary with the OS level mapping, and what the bios
>> does at boot time with an AUTO drive type, what was being discussed.

> The OS has nothing to do with this.

Wrong. Not all OSs even use CHS, let alone map them to
block numbers the same way. It cant just be the bios, most
obviously with drive overlays which get around bios limitations.

> Let me give you an example.

> Award BIOS with extended interrupt 13h (disk) support.

Thats just one way an OS can use a hard drive.

> A 9671 MB IDE harddisk. The disk is set to User/LBA,

Soorree, we were specifically discussing the
use of the AUTO drive type, not that mode.

> and the disk has a BIOS translation of
> 1232 cylinders, 255 heads, 63 sectors.

And thats not even getting the geometry details
out of the first physical sector on the hard drive
anyway, thats getting it from the drive type values.

> With this translation 9664 MB are useable.

> A 9664 MB partition is created. The partition table
> is correct, and assumes a 255 heads translation.

There aint even just one format of partition
table. That also varys with the OS.

And as Tpsa said, even if you choose to use a custom OS
with its own filesystem, the Award bios manages fine, so it
cant be getting that geometry data out of the first physical
sector on the drive when the drive type AUTO is used.

And the bios certainly cant be getting it out of the first physical
sector of the drive when that sector just contains zeros.

> The disk has 19,807,200 sectors. We look at LBA
> sector 10,000,000 (numbered from 0). This will be

> cylinder 622, head 120, sector 11

> Then we reboot, and enter BIOS setup. LBA mode is changed
> to NORMAL mode. A translation of 19650 cylinders, 16 heads,
> 63 sectors is displayed. We save the change and boot.

> Then we request the disk geometry by calling BIOS interrupt 13h.
> The answer is 1232 cylinders, 255 heads, 63 sectors.

> Then we call BIOS interrupt 13h, function 42h, and
> request LBA sector 10,000,000. A sector is returned.

> Everything looks OK, but it is definitely
> not sector 10,000,000 that is returned.

No one has ever disputed that that mapping does
vary with the  drive type for some drive type changes.

What was being discussed was whether a drive with
an AUTO drive type can suddenly start using a different
mapping, just due to a change in the contents of the first
physical sector of the drive, and that different mapping
result in the drive audibly recalibrating as if finds bad sectors
and is very slow to copy existing data for the same reason.

Yes, when the drive type is changed, the mapping between
CHS and logical block numbers can change, but that just
makes the data structure on the drive all wrong and you
can 'lose' partitions and data, but not get read errors.

> Then we use interrupt 13h, function 02h,
> to request cylinder 622, head 120, sector 11.

> Again: Everything looks OK, but it is definitely
> not sector 10,000,000 that is returned.

> Please note that this is only one of the
> Award bugs. The one that I called nasty.

Got absolutely NOTHING to do with what was being discussed,
whether the bios, with an AUTO drive type, gets the geometry
detail from the first physical sector on the drive and that data
going bad will produce bad sectors. You are just talking about the
mapping changing. No news to anyone who knows anything about it.

Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote in
message news:3979c07a.62476@news.inet.tele.dk...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Svend Olaf Mikkelsen <svolaf@inet.uni2.dk> wrote

>>> A 9671 MB IDE harddisk. The disk is set to User/LBA,

>> Soorree, we were specifically discussing the
>> use of the AUTO drive type, not that mode.

> You do not seem to distinguish between "Type AUTO" and "Mode AUTO".

That example of yours doesnt have auto for either, so
its irrelevant to what was being discussed, Richard's
claim that the 'auto detect feature(s)' for the drive type
in the bios can produce the symptoms that Ian saw.

Like I say, no one has ever disputed that you can and do get
different mapping between CHS and logical blocks when you
change the various parameters in the drive entry in the bios.

What was being discussed was whether that can change
spontaneously in use with AUTO settings tho. It cant.

> My comments on the NORMAL and LBA modes
> applies to both Type AUTO and Type USER.

And arent relevant to what was being discussed.

> The reason I went to NORMAL mode, is that your previous statement:

>> The bios AUTO setting doesnt use the partition
>> table. It just asks the drive about its parameters,
>> and the drive doesnt use the partition table either.

> is so obviously wrong, that I would not comment further.

You've gunna have to do a hell of a lot better than just proclaim
that thats 'just so obviously wrong' specially with a drive that
hasnt even been partitioned and formatted where that data
aint even in the partition table coz there aint no partition table.

Have fun explaining how the bios works that
stuff out fine with the custom OS tpsa uses too.

> An Award BIOS looks at the partition table in both NORMAL, LARGE,
> LBA, and AUTO mode, when determining the translation to use.

Easy to claim Svend, try doing more than just claiming it.

> And it does this for both Type USER and Type AUTO.

Easy to claim Svend, try doing more than just claiming it.

> If the partition table contains zeroes, it is not used.

And clearly it doesnt even when there is more than just zeros
too, otherwise tpsa wouldnt be seeing the result he is seeing.

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.

"Rod Speed" <rod_speed@yahoo.com> wrote:

[snip]

Rod, it's plain to me that there's nothing more I can say, that will convey
what I and Svend have attempted to explain to you. 

Now, you apparently are more than capable of testing whether a partition
table will effect the choice the BIOS chooses in regards to the translation
method used. So rather than waving your arms like a fledgling, try it.

Create a partition with the BIOS's Hard disk mode initially set to "Normal",
then set the mode back to "Auto". What does the BIOS report panel say (after
POST, but before the OS starts) ?

Now try again with the mode initially set to "Large", then change it back to
"Auto". What's reported now ? 

But don't stop there, try other permutations of this, move the hard disk to
another system, etc. Do you still say that a partition table does not effect
the choice of translation modes ?

If you now agree it does, then it's not a complete unlikelihood some
aberration could occur which mildly corrupts an otherwise normal LBA mode
created partition table, such that the BIOS now decides to use another type
translation - remember the "Auto" setting decides at some point during POST.


As for wether a drive will "recal" if there is a bug in the BIOS 13h
routines. Yes, I've had this occur, as I explained in my last message,
although, I've not tried to do this on any recent model drives. But then
again, you've already questioned the adequacy of my experiments, so short of
finding a drive that recals upon invalid LBA addresses and a BIOS with a bug
that produces these invalid LBA addresses, and then have you stand next to
me... well, fat chance. If you had Linux, I suppose you could try using the
"dd" command against various hard disks that you have, and see if reading
(or perhaps writing) beyond the capacity of the a drive causes a recal. Nock
yourself out...

Beyond all that, there's nothing more to say to you on this. Perhaps, try
re-reading what's been already posted, with more of an open mind...
  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

Richard RUDEK <x@invalid.zeta.org.au> wrote in
message news:397b000e.4817808@news.zeta.org.au...
> Rod Speed <rod_speed@yahoo.com> wrote

> Rod, it's plain to me that there's nothing more I can say, that
> will convey what I and Svend have attempted to explain to you.

You both keep rabitting on about what wasnt even being discussed.

No one has ever disputed that the mapping between CHS
and logical blocks does indeed change with the drive type
settings used in the bios, different bios and drive overlays
that get around bios limitations at particular drive sizes.

What was being discussed was your assertion that the symptoms
that Ian saw can be produced by the use of AUTO drive settings
in the bios. You havent actually provided a shred of evidence to
support that assertion. And with the AUTO settings being the default,
even say the resetting of the cmos settings due to something the
user is unaware of happening cant produce the effect Ian saw if
the AUTO settings had been used before the failure.

> Now, you apparently are more than capable of testing whether a partition
> table will effect the choice the BIOS chooses in regards to the translation
> method used. So rather than waving your arms like a fledgling, try it.

Doesnt have the slightest relevance to what was being discussed,
whether the use of AUTO settings in the bios and the user not
changing the drive settings can produce the symptoms Ian saw.

Thats just trying what has never been disputed, that the drive
settings can affect the mapping between CHS and logical blocks.
Thats no news to anyone who knows anything about it so there
is no need to try anything and it wasnt even in dispute.

> Create a partition with the BIOS's Hard disk mode initially
> set to "Normal", then set the mode back to "Auto". What does
> the BIOS report panel say (after POST, but before the OS starts) ?

> Now try again with the mode initially set to "Large",
> then change it back to "Auto". What's reported now ?

All completely and utterly irrelevant to what was being
discussed, whether the use of AUTO setting ALL THE
TIME can produce the symptoms that Ian saw.

You aint produced a shred of evidence on that.

> But don't stop there, try other permutations of this, move
> the hard disk to another system, etc. Do you still say that
> a partition table does not effect the choice of translation modes ?

All completely and utterly irrelevant to whether the use of
the AUTO settings and not doing any of that drive moving
between systems can produce the symptoms Ian saw.

> If you now agree it does,

I have said repeatedly that I know that occurs. Doesnt have the
slightest relevance to your assertion that the symptoms Ian saw
can be produced by the use of AUTO settings and the drive staying
in the one system and not being moved around even in that system.

And it turns out he doesnt even use AUTO settings anyway.

> then it's not a complete unlikelihood some aberration could occur
> which mildly corrupts an otherwise normal LBA mode created partition
> table, such that the BIOS now decides to use another type translation
> - remember the "Auto" setting decides at some point during POST.

Wota pity he doesnt even use AUTO settings at all.

> As for wether a drive will "recal" if there is a bug in the BIOS 13h routines.

That wasnt even being discussed either. What was being discussed
was whether the drive will recal if it gets a request for a logical block
which is outside the range of logical blocks that the drive physically has.

And it aint just about recals anyway, I keep rubbing your nose in
the FACT that Ian said more than once that when he was copying
off data that he could see, that was very slow, but did happen.
THAT is the evidence that the drive was RETRYING bad sectors and
mostly getting the data eventually. That cant happen if the mapping
is producing a logical block number thats outside the range the drive
physically has. You can retry till the cows come home, you'll never
get any data out of a logical block that doesnt exist, even if the
drive is so badly designed that it does recal in that situation.

> Yes, I've had this occur, as I explained in my last message,
> although, I've not tried to do this on any recent model drives.

Doesnt have any relevance to Ian's situation where
clearly retrys did mostly get the data eventually.

> But then again, you've already questioned the adequacy of my experiments,

I've rubbed your nose FAR more in the fact that you aint
even managing to work out what is being discussed.

> so short of finding a drive that recals upon invalid LBA addresses
> and a BIOS with a bug that produces these invalid LBA addresses,
> and then have you stand next to me... well, fat chance.

And even slimmer chance of you being able to demonstrate
that that can happen with the use of AUTO drive settings.

So your original is just that, an assertion
without a shred of evidence to substantiate it.

And cant be what Ian saw because he
doesnt even use the AUTO settings anyway.

> If you had Linux, I suppose you could try using the
> "dd" command against various hard disks that you
> have, and see if reading (or perhaps writing) beyond the
> capacity of the a drive causes a recal. Nock yourself out...

Pointless even going thru the trivial exercise of writing a bit of
code that deliberately makes requests for logical blocks outside
the range that the drive has physically because that wouldnt do
a damned thing about explaining how Ian was clearly getting
retrys on the bad sectors and getting the data eventually.

Cant happen with a non existent logical block.

> Beyond all that, there's nothing more to say to you on this. Perhaps,
> try re-reading what's been already posted, with more of an open mind...

Got nothing to do with 'an open mind', its all about YOU
managing to grasp what is actually being discussed.

I repeat, no one has ever disputed that the mapping between
CHS and logical blocks does indeed vary in some situations.

That has NOTHING to do with your assertion that the use
of AUTO setting in the drive type can produce the symptoms
that Ian saw. Its just your assertion without a shred of evidence
to support it, and quite a bit of evidence like the retrys that
did get the data eventually that it cant have been a mapping
problem and was in fact a hardware problem instead.

"Joe Spanicek" <Joe.Spanicek@alcatel.com.au> wrote in message news:3976832C.68CBB3DA@alcatel.com.au...
| Hi,
|
| Rather than the drive itself, maybe the controler on drive stuffed up
| somewhat - possibly a hot joint somewhere. Or it may have been something
| wrong with the drive cable connection. Pulling out and putting back may
| have fixed it.

Yes, although some combination with writing to every sector must have taken
place. A logically bad sector will stay bad until it is overwritten, so read
testing on another system will still show them bad.
Most diagnostic programs will not go far enough in that they will try to
read a sector ad infinitem and then decide it is bad instead of writing to
it first and then read (format, scandisk). 
There lies a dilemma because that test will be data destructive and user 
intervention is needed to query if that is acceptable.

--
Folkert Rienstra
(don't email me please, reply to the group)
visit Gary Field's SCSI Info Central at www.scsifaq.org

|
| Joe
|
| Ian Lowery wrote:
| >
| > I had a very mysterious hard drive crash and resurrection recently,
| > and it has me rather mystified.
| >
| > The drive is a Quantum KA, 13 Gb, and only 8 months old. It has
| > multiple logical drives in the extended partition (FAT16) and a small
| > primary partition to allow booting into multiple operating systems.
| >
| snip snip - since Netscape complains
| > Anybody got any clues as to what happened?
| >
| > Cheers
| >
| > Ian
| >
| > ------------------------------------------------
| > To reply, remove "nospam" from my e-mail address.

"Rod Speed" <rod_speed@yahoo.com> wrote:
>Richard RUDEK <x@invalid.zeta.org.au> wrote in
>message news:397b000e.4817808@news.zeta.org.au...
>> Rod Speed <rod_speed@yahoo.com> wrote


First of all, Ian has, apparently, already followed my suggestion about
testing the drive with the Quantum Data Protection System utility, which
found a fault, and any "discussion" since, has basically ceased to be about
Ian's specific problems.

You, instead, seem to be on some ego trip, trying your best to make a big
deal out of something which was suggested, with at best, 5mins worth of
composition, whilst surfing the net and between downloads. An analogy being
a group of people sitting on a beach, one asking what the time is, nobody
having a watch, and people taking a guess. Then you, carrying on about the
*flaws* of those suggestions which differed to yours - basically being a
wanker.

>> Rod, it's plain to me that there's nothing more I can say, that
>> will convey what I and Svend have attempted to explain to you.
>
>You both keep rabitting on about what wasnt even being discussed.
>
>No one has ever disputed that the mapping between CHS
>and logical blocks does indeed change with the drive type
>settings used in the bios, different bios and drive overlays
>that get around bios limitations at particular drive sizes.
>
>What was being discussed was your assertion that the symptoms
>that Ian saw can be produced by the use of AUTO drive settings
>in the bios. 

No, that was not being "discused", at least, not by me. 

What started this particular branch of this thread, which I and Svend have,
according to you, been "rabitting on about", was your claim on the 21 Jul @
6:16, that:

  The bios AUTO setting doesnt use the partition
  table. It just asks the drive about its parameters,
  and the drive doesnt use the partition table either.


Yes, I did earlier say that I have seen the symptoms which Ian described,
when I had a corruption of a partition table, along with a buggy BIOS, which
caused a weird translation problems, and resulted in a DOS mode format
reporting a large number of consecutive bad clusters, beyond a cetain point.


Later, when responding "AWP" and "Tpsa", I realised that when Ian said
"multiple seeks and retries on dodgey sectors", that this *could* in fact be
drive recalibrations (your suggestion, in a parallel branch), rather than
DOS retrying. I then related a situation (not as verbosely as follows) where
I had a drive/BIOS combination that would cause the hard disk to recalibrate
when I attempted to seek to certain CHS addresses. This could only be
explained by a bug in the BIOS, as flashing the BIOS removed the problem.
However, I then attempted to reproduce the problem using the new BIOS, and
found that if I attempted to access beyond the storage capacity of that
drive (invalid LBA addresses), it caused the hard disk to recalibrate. ie
The buggy BIOS was most likely producing invalid LBA addresses when
converting from CHS addresses. 

If such a bug where triggered in Ian's system's BIOS, then it's possible the
recalibrations *could* be explained by such.

As for your comment about the block address being unsigned, so it could
contain a negative block address, shows you know little about practical
programming and machine code (or chosen to be so).


But in addition to the initial suggestion, I also suggested Ian should test
the drive with a diagnostic utilitiy, to which you replied:
  But that isnt likely to say much if its an intermittent
  fault, particularly if it was a fault external to the drive.

Is that a dismisal, or did you want Ian to use the utility ?


>...You havent actually provided a shred of evidence to
>support that assertion. 

Evidence ? According to you, on the 27 Jul @ 6:22:
  That brings up the question of how adequate those experiments were.

you've already questioned the adequacy of my experimentation. So it follows
that you will likely question any experiments that I may make now, and
ultimately, it will all end up being hearsay. So why bother. 

At any rate, I didn't say "this is the cause", so I don't feel that I need
to, and neither was I going to. Hmmm, perhaps you might explain what you
consider "evidence", given that we are in an electronic forum ?  

On second thoughts, don't bother.

>... And with the AUTO settings being the default,
>even say the resetting of the cmos settings due to something the
>user is unaware of happening cant produce the effect Ian saw if
>the AUTO settings had been used before the failure.

Hey ?  Resetting of the BIOS ? 

The only changes to the BIOS/CMOS settings that I discussed, were in
descriptions about how you can test to see wether a partition table
effects/influences what translation method a BIOS may choose, when the Hard
disk mode option is set to "Auto".

Once again, this was directed at your claim (the start of this branch of the
thread) that: 
  The bios AUTO setting doesn't use the partition table. 


Perhaps there is genuine confusion about what I was trying to say, in
relation to the Hard disk "Auto" *MODE* setting, and the Hard disk "Auto"
*TYPE* setting, as suggested by Svend's message on 23 Jul @ 1:44. But I
really dislike the way you try to resolve this confusion, and you did in
fact recognise that I was talking about translations, quite early in the
piece.

At any rate, I've lost interest in the rest of your comments, as before, it
all appears to be silly attempts of goating me, and I really dislike your
attitude. After 5.5 days (10-12hr days) of solid programming, weekend an
all, who needs this shit.

If you want to argue about technical inconsistencies (about a suggestion of
all things), then start with your comments which started this branch of the
thread on 21 Jul, and look at what was being responded too, and not what you
would have liked me (or Svend) to respond too. In fact, I deliberatley
didn't respond to your response on 22 Jul 6:22, because, you were basically
avoiding what I and Svend were trying to "discuss" with you. Maybe you
realised you got that wrong... try it.

I've spent much too much time on this with you, as you have demonstrated
that you are not worth it. I think the groups that your series of diatribe
has been distributed to, will also agree. I appologise for any part that
I've played in it.

[snip]

  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

[snip]


Ha ha ha. What else can I do but laugh.

OK, lets assume that you genuinely didn't understand what I said on 27 Jul @
0:16 when I said:

  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.

  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 ?

  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 ?

Better still, lets ignore you, Rod, and pretend that someone less
adversarial than you, asked me to explain how to test this, but didn't quite
understand the terse description above.

The only drive I have free at this time is a 1.2GB Seagate ST31270A, but
this should suffice for our purposes of testing wether a partition table
effects the translation mode chosen by BIOS, when the Hard disk mode setting
is set to "Auto". The system uses a Soltek SL-52B2 motherboard based on an
Intel 430VX chipset and has an Award 4.51PG BIOS. Rev S3, for those who may
also have this motherboard. Not a current system, but that's all that I have
available, and shouldn't matter too much.

First off, enter the BIOS setup, Standard CMOS setup, cursor to Primary
Master, set the TYPE to "Auto", cursor to the MODE column, set that to
"Auto" as well :

    HARD DISKS         TYPE   SIZE     CYLS HEAD PRECOMP LANDZ SECTOR  MODE 
    ------------------------------------------------------------------------
    Primary Master   : Auto      0        0    0       0     0      0  AUTO

Save exit. Boot up on a floppy disk, mine being created from a Win95B
system, containing FDISK, FORMAT, etc. Same thing using Win9x Rescue disk.
See here for more details on my disk:
http://microdek.homepage.com/info/OSR2bootDiskette.htm#mydisk

Now pause on the BIOS report screen, the Boxed information that is displayed
upon completion of POST (Power On Self Tests), and before an OS begins to
load. It looks something like: 

+------------------------------------------------------------------------
| CPU Type          : IDT WinChip C6       Base Memory       :     640KB 
| Co-Processor      : Installed            Extended Memory   :   64512KB 
| CPU Clock         : 200MHz               Cache Memory      :     256KB 
+------------------------------------------------------------------------
| Diskette Drive  A : 1.44M, 3.5 in.       Display Type      : EGA/VGA 
| Diskette Drive  B : 1.44M, 3.5 in.       Serial Port(s)    : 3F8 2E8
| Pri. Master  Disk : LBA ,Mode 4, 1282MB  Parallel Port(s)  : 378

          blah, blah.... 

Booting from a floppy, you should have plenty of time to press the
Shift-Pause keystroke to Pause the system Bootstrap, and view this report.
Press a key to continue, afterwards.

Now wipe all entries from the partition table (using FDISK or a zeroing
util), then reboot. Do I really need to go into this detail ?  Perhaps, if
you don't know how to do this, then you shouldn't be proceeding. 

Anyway, without a partition table, the BIOS should choose LBA translation,
as shown in the above BIOS report. This much has never been disputed (by
me). 

Now, reboot, and change the Primary Master MODE to "Normal":

    HARD DISKS         TYPE   SIZE     CYLS HEAD PRECOMP LANDZ SECTOR  MODE 
    ------------------------------------------------------------------------
    Primary Master   : Auto      0        0    0       0     0      0 NORMAL

Save exit. The BIOS now reports CHS addressing:

 Pri. Master  Disk : CHS ,Mode 4, 1282MB 

Boot up on the floppy, and create a Primary DOS Partition. Choose defaults.
If you chose to use large disk support at the start of FDISK, then a FAT32x
(ID 0xC) partition is created, else a FAT16x (ID 0xE) partition is created.
If you were booting an earlier version of DOS, say DOS 6.22, then you won't
have access to the FAT16x, FAT32 or FAT32x, thus will be limited to creating
a maximum of ~500MB FAT16 (ID 0x6) partition. Reboot.

You can FORMAT it now, but it's not necessary for this experiment.

Change the Primary Master MODE to back to "Auto", Save and exit. The BIOS
still reports CHS mode. Why ?

Delete the partition, reboot, the BIOS now reports LBA. Hmm, so if the Auto
Hard disk mode setting was not influenced by a partition table, why did this
happen ?


Now try this. Change back to "Normal" mode, and then create a primary, but
at a capacity such that it will have more than 1024 Cyls, in my case, half
capacity 611MB looks fine, set the active partition to 1, change the Mode to
"LBA" or "Large", now try and create an extended partition.

Whoops, FDISK is saying that we have a 611MB partition, but the Total Disk
space if 504MB. Strange. OK, so delete and recreate the primary partition.
Reboot. Oh, look, the BIOS is reporting LRG, 1053MB. What happened to the
other 229MB ?

OK, lets see if I can create the extended partition now. Oh good, you can.
But, we are still missing 229MB. Something seriously screwy here. Change the
mode back to "Auto". It comes up as LBA, but still only 1053MB. 

Delete all partitions, reboot, now try. All is fine again.

In summary, a partition table with signature and reasonably accurate
entries, however they got there, will influence both the translation used
(LBA, Normal, Large), and in some cases, the capacity of a drive. Sure, what
I've described above shouldn't happen as an every day occurance, but that is
not the point.

Would someone like to try this with other BIOSes such as AMI, Phoenix, or
MrBIOS, and later versions of Award ?

If you want to investigate further, then you can use utilities like WDTBLCHK
(ftp://ftp.wdc.com/drivers/hdutil/tablechk.exe), from which you can extract
this type of info:

MODEL:                 ST31270A
CYLINDERS:                 2485
HEADS:                       16
SPT:                         63
PHY. SECTORS:           2505528
PHY. SIZE (MB):            1283

HD mode  INT 13h, 8         INT 13h, 41/48                     Xlat Info 
------- -----------------  --------------------------------- ------------
Large 	 621 64 63 1281MB    621 64 63 2503872 sect (1282MB) CHS to CHS 
LBA 	 621 64 63 1281MB    621 64 63 2503872 sect (1282MB) LBA 
Normal 	1024 16 63  528MB   2485 16 63 2504880 sect (1282MB) No Xlat 
		 	


I leave it as an exercise for the reader, to examine the differences between
the various partition table entries, so as to be able to manually edit it
with a disk editor like Nortons DISKEDIT. Tinker away, and you tell me...  

:)

  __   __  ________________________________________________________
 //)) //))| Richard RUDEK. MicroDek. Chatswood, Sydney. Australia. |
//\\ //\\ |http://microdek.homepage.com/                           |
          |________________________________________________________|

Richard RUDEK <x@invalid.zeta.org.au> wrote in message news:397da796.35367520@news.zeta.org.au...
> Rod Speed <rod_speed@yahoo.com> wrote
>> Richard RUDEK <x@invalid.zeta.org.au> wrote
>>> Rod Speed <rod_speed@yahoo.com> wrote

> First of all, Ian has, apparently, already followed my
> suggestion about testing the drive with the Quantum
> Data Protection System utility, which found a fault,

So it turns out that there was indeed a hardware
fault and the result he got wasnt due to the use
of the AUTO settings, which he didnt use anyway.

> and any "discussion" since, has basically
> ceased to be about Ian's specific problems.

Yes, they had moved on to a discussion of your claim that the specific
symptoms he saw was 'probably' the result of using the AUTO settings.

In fact when the detail of the symptoms he saw are considered,
specifically the fact that he could recover quite a bit of what at first
sight appeared to be lost, but very slowly, the evidence in the original
post made it much more likely that he had seen a hardware fault.

And you still havent been able to show how the use of
the AUTO settings could produce the symptoms he saw.

And you dont appear to be able to grasp that no one has
ever disputed that the mapping between CHS and logical
blocks does change with a variety of changes to drive
settings, different bios, use of a drive overlay etc.

What was disputed was that the use of AUTO settings can do that.
And you havent managed to show that thats actually possible with
a system that just spontaneously shows the symptoms he saw.

> You, instead, seem to be on some ego trip, trying your best to make
> a big deal out of something which was suggested, with at best, 5mins
> worth of composition, whilst surfing the net and between downloads.

I wouldnt have even bothered to comment if you had had
the balls to admit that on more thought, that the symptoms
he saw cant be produced by the use of AUTO drive settings.

When you continued to rabbit on about what was never disputed,
that the mapping between CHS and logical blocks does indeed
change with a variety of changes to drive settings, bios used,
drive overlays etc, I just pointed out that that does nothing to
substantiate your claim about the use of AUTO settings.

> An analogy being a group of people sitting on a beach, one asking
> what the time is, nobody having a watch, and people taking a guess.
> Then you, carrying on about the *flaws* of those suggestions which
> differed to yours - basically being a wanker.

You're gunna have to do a hell of a lot better than this
to bullshit your way out of your predicament now Rudek.

There is the tiny matter of your 'what I and Svend
have attempted to explain to you' just below.

You 'think' you're actually fooling anyone at all ?  Fraid not.


>>> Rod, it's plain to me that there's nothing more I can say, that
>>> will convey what I and Svend have attempted to explain to you.

>> You both keep rabitting on about what wasnt even being discussed.

>> No one has ever disputed that the mapping between CHS
>> and logical blocks does indeed change with the drive type
>> settings used in the bios, different bios and drive overlays
>> that get around bios limitations at particular drive sizes.

>> What was being discussed was your assertion
>> that the symptoms that Ian saw can be produced
>> by the use of AUTO drive settings in the bios.

> No, that was not being "discused", at least, not by me.

Wrong. You were the one that made that original claim about AUTO
settings 'probably' being what produced the symptoms Ian saw.

> What started this particular branch of this thread, which I
> and Svend have, according to you, been "rabitting on about",
> was your claim on the 21 Jul @ 6:16, that:

>   The bios AUTO setting doesnt use the partition
>   table. It just asks the drive about its parameters,
>   and the drive doesnt use the partition table either.

And you aint done any more than proclaim that it does use the
partition table and havent been able to do more than proclaim.

> Yes, I did earlier say that I have seen the symptoms which Ian described,
> when I had a corruption of a partition table, along with a buggy BIOS, which
> caused a weird translation problems, and resulted in a DOS mode format
> reporting a large number of consecutive bad clusters, beyond a cetain point.

> Later, when responding "AWP" and "Tpsa", I realised that when Ian
> said "multiple seeks and retries on dodgey sectors", that this *could*
> in fact be drive recalibrations (your suggestion, in a parallel branch),
> rather than DOS retrying. I then related a situation (not as verbosely
> as follows) where I had a drive/BIOS combination that would cause
> the hard disk to recalibrate when I attempted to seek to certain CHS
> addresses. This could only be explained by a bug in the BIOS, as
> flashing the BIOS removed the problem. However, I then attempted
> to reproduce the problem using the new BIOS, and found that if I
> attempted to access beyond the storage capacity of that drive
> (invalid LBA addresses), it caused the hard disk to recalibrate.
> ie The buggy BIOS was most likely producing invalid
> LBA addresses when converting from CHS addresses.

Still irrelevant to Ian's situation where the recals do eventually
return useful data. That is the evidence that the recals cant have
been due to requests for blocks outside what the drive actually has.

> If such a bug where triggered in Ian's system's BIOS, then
> it's possible the recalibrations *could* be explained by such.

Nope, not when the recals do eventually get the data.

> As for your comment about the block address being unsigned,
> so it could contain a negative block address, shows you know little
> about practical programming and machine code (or chosen to be so).

Know a damned sight more about it than you do
boy, and was doing it before you were even born.

> But in addition to the initial suggestion, I also suggested Ian should
> test the drive with a diagnostic utilitiy, to which you replied:

>   But that isnt likely to say much if its an intermittent
>   fault, particularly if it was a fault external to the drive.

> Is that a dismisal, or did you want Ian to use the utility ?

Its just pointing out that when the drive appears to now be
working fine, particularly if the hardware problem is external
to the drive, that particular diagnostic, if it said the drive was
fine, isnt saying anything definitive about whether a hardware
problem was what caused the problems Ian saw.

>> What was being discussed was your assertion that
>> the symptoms that Ian saw can be produced by the use
>> of AUTO drive settings in the bios. You havent actually
>> provided a shred of evidence tosupport that assertion.

> Evidence ?

Yep, evidence. Not a shred on that assertion.

> According to you, on the 27 Jul @ 6:22:
>   That brings up the question of how adequate those experiments were.

> you've already questioned the adequacy of my experimentation.

Yes, and if you had actually spelt out the detail of just what you
had done, particularly on the actual bytes changed in the partition
table and the effect that specific changes made had had on the
CHS to logical block mapping, so anyone could try those changes
and see if they get that effect, that would allow anyone who cared
to try it for themselves to see just how valid your claim about the
bios using data in the partitions tables is on that CHS/LBA mapping.

> So it follows that you will likely question
> any experiments that I may make now,

Anyone can try it for themselves if you spell out exactly what
changes to what bytes in the partition table demonstrate a
change in the CHS/LBA mapping, with nothing else changed.

> and ultimately, it will all end up being hearsay.

Wrong when anyone can try the specifics for themselves.

> So why bother.

Because it would provide the evidence to demostrate that your claim
that data in the partition tables does affect the CHS/LBA mapping.

I'd like to know if that is in fact happening.

Corse it still doesnt do a damned thing about the claim that the
use of AUTO settings can produce the effect Ian saw unless you
can also show that those bytes only affect the CHS/LBA mapping
when the AUTO settings are used and not when they arent.

All basic engineering Rudek, as opposed to your smokescreen of bullshit.

> At any rate, I didn't say "this is the cause", so I don't feel that I need
> to, and neither was I going to. Hmmm, perhaps you might explain what
> you consider "evidence", given that we are in an electronic forum ?

Just did above. Precisely the same evidence used in any decent
engineering, the specifics of a particular test that demonstrates a
particular effect that anyone can try for themselves if they know how
to edit the partition table and see what happens to the drive contents.

> On second thoughts, don't bother.

You get no say on that anyway.

>> And with the AUTO settings being the default, even say the
>> resetting of the cmos settings due to something the user is
>> unaware of happening cant produce the effect Ian saw if
>> the AUTO settings had been used before the failure.

> Hey ?  Resetting of the BIOS ?

You rabbited on about the CHS/LBA mapping changing with
manual drive settings changes. One obvious possibility was that
the cmos setting had got lost spontaneously and so a change to
the drive settings had occurred without the user being aware of that.

> The only changes to the BIOS/CMOS settings that I discussed,
> were in descriptions about how you can test to see wether a
> partition table effects/influences what translation method a BIOS
> may choose, when the Hard disk mode option is set to "Auto".

Yes, and clearly its also possible for the drive settings
to change without the user manually changing them.

> Once again, this was directed at your claim
> (the start of this branch of the thread) that:

>   The bios AUTO setting doesn't use the partition table.

Those aint changes to the partition table,
they're changes to the drive settings.

> Perhaps there is genuine confusion about what I was trying to say, in
> relation to the Hard disk "Auto" *MODE* setting, and the Hard disk "Auto"
> *TYPE* setting, as suggested by Svend's message on 23 Jul @ 1:44.

Nope, I was just a bit lax about how I stated the AUTO in that post.

> But I really dislike the way you try to resolve this confusion,

I really dislike yours too, specially that puerile 'So rather
than waving your arms like a fledgling, try it' stunt.

> and you did in fact recognise that I was talking
> about translations, quite early in the piece.

> At any rate, I've lost interest in the rest of your comments,

Not enough to attempt this pathetic attempt to
bullshit your way out of your predicament now tho.

> as before, it all appears to be silly attempts of goating me,

as before, its obvious you dont have the
balls to actually admit to your footshots.

and I really dislike your attitude.

> After 5.5 days (10-12hr days) of solid programming,
> weekend an all, who needs this shit.

This is where we're all sposed to swoon is it boy ?  You might
not actually be the only individual who does that sort of thing.

> If you want to argue about technical inconsistencies (about a suggestion
> of all things), then start with your comments which started this branch of
> the thread on 21 Jul, and look at what was being responded too, and
> not what you would have liked me (or Svend) to respond too.

More of your pathetic excuse for bullshit. Fooling absolutely no
one at all. Its you two clowns who keep rabbiting on about what
was never disputed, that the CHS/LBA mapping does indeed
change with the drive type, the bios used, drive overlays etc.

What was being discussed was whether the use of AUTO setting
can produce a change in the CHS/LBA mapping and no matter how
desperately you bullshit, you've done no more than just bullshit.
Not a shred of evidence has been presented on that claim.

> In fact, I deliberatley didn't respond to your response
> on 22 Jul 6:22, because, you were basically avoiding
> what I and Svend were trying to "discuss" with you.

It was never disputed that the CHS/LBA mapping does
change with drive type, bios used, drive overlays etc. In
fact I have said that repeatedly over the years in here.
Nothing to 'discuss', just a need to point out that that
doesnt have any relevance to your claim that the AUTO
settings can produce a change in the CHS/LBA mapping.

> Maybe you realised you got that wrong... try it.

Wota pathetic excuse for a bullshit artist you are Rudek.

How odd we aint seen any admission from you that
you were wrong on that claim that the symptoms Ian
saw were 'probably' due to the use of AUTO settings.

And it doesnt actually matter a damn what you have the balls to admit
to anyway, everyone can see your desperate squirming on that now.

> I've spent much too much time on this with you, as you have
> demonstrated that you are not worth it. I think the groups that
> your series of diatribe has been distributed to, will also agree.
> I appologise for any part that I've played in it.

Pathetic really. Even a 3 year old could manage better than that Rudek.

Richard RUDEK <x@invalid.zeta.org.au> wrote in message news:397eaaeb.36545850@news.zeta.org.au...

> Ha ha ha. What else can I do but laugh.

More of your usual pathetic excuse for bullshit when even you have
noticed what a hell of a hole you have dug for yourself Rudek.

> OK, lets assume that you genuinely didn't understand
> what I said on 27 Jul @ 0:16 when I said:

No need to assume a damned thing about your pathetic excuse for bullshit Rudek.

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

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

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

All completely and utterly irrelevant to what was being discussed,
whether the use of AUTO settings for the drive can produce the
effect that Ian saw with the AUTO settings being used all the time.

Like I keep telling you Rudek, no one has ever disputed
that different drive settings, different bios, drive overlays
etc can and do produce different CHS/LBA mapping.

All that crap above has absolutely NOTHING to do
with the situation being discussed, the use of AUTO
settings being able to produce the symptoms Ian saw.

> Better still, lets ignore you, Rod, and pretend that someone
> less adversarial than you, asked me to explain how to test
> this, but didn't quite understand the terse description above.

More of your pathetic excuse for bullshit Rudek.

This crap below aint 'testing' the claim you made, that the use of
AUTO settings in the bios can produce the symptoms Ian saw.

> The only drive I have free at this time is a 1.2GB Seagate ST31270A,
> but this should suffice for our purposes of testing wether a partition table
> effects the translation mode chosen by BIOS, when the Hard disk mode
> setting is set to "Auto". The system uses a Soltek SL-52B2 motherboard
> based on an Intel 430VX chipset and has an Award 4.51PG BIOS. Rev S3,
> for those who may also have this motherboard. Not a current system,
> but that's all that I have available, and shouldn't matter too much.

> First off, enter the BIOS setup, Standard CMOS setup,
> cursor to Primary Master, set the TYPE to "Auto", cursor
> to the MODE column, set that to "Auto" as well :

>     HARD DISKS         TYPE   SIZE     CYLS HEAD PRECOMP LANDZ SECTOR  MODE
>     ------------------------------------------------------------------------
>     Primary Master   : Auto      0        0    0       0     0      0  AUTO

> Save exit. Boot up on a floppy disk, mine being created
> from a Win95B system, containing FDISK, FORMAT, etc.
> Same thing using Win9x Rescue disk.
> See here for more details on my disk:
> http://microdek.homepage.com/info/OSR2bootDiskette.htm#mydisk

> Now pause on the BIOS report screen, the Boxed information
> that is displayed upon completion of POST (Power On Self Tests),
> and before an OS begins to load. It looks something like:

> +------------------------------------------------------------------------
> | CPU Type          : IDT WinChip C6       Base Memory       :     640KB
> | Co-Processor      : Installed            Extended Memory   :   64512KB
> | CPU Clock         : 200MHz               Cache Memory      :     256KB
> +------------------------------------------------------------------------
> | Diskette Drive  A : 1.44M, 3.5 in.       Display Type      : EGA/VGA
> | Diskette Drive  B : 1.44M, 3.5 in.       Serial Port(s)    : 3F8 2E8
> | Pri. Master  Disk : LBA ,Mode 4, 1282MB  Parallel Port(s)  : 378

>           blah, blah....

> Booting from a floppy, you should have plenty of time to press
> the Shift-Pause keystroke to Pause the system Bootstrap,
> and view this report. Press a key to continue, afterwards.

> Now wipe all entries from the partition table (using FDISK or a zeroing
> util), then reboot. Do I really need to go into this detail ?  Perhaps, if
> you don't know how to do this, then you shouldn't be proceeding.

More of your pathetic excuse for bullshit. You have said yourself that
I have often told people how to do this when installing a hard drive where
the results they are getting at fdisk and format time make no sense.

You 'think' you are actually fooling anyone at all with these puerile antics boy ?

> Anyway, without a partition table, the BIOS should
> choose LBA translation, as shown in the above BIOS
> report. This much has never been disputed (by me).

> Now, reboot, and change the Primary Master MODE to "Normal":

No thanks, doesnt have the remotest
relevance to Ian's situation. He didnt do that.

>
>     HARD DISKS         TYPE   SIZE     CYLS HEAD PRECOMP LANDZ SECTOR  MODE
>     ------------------------------------------------------------------------
>     Primary Master   : Auto      0        0    0       0     0      0 NORMAL

> Save exit. The BIOS now reports CHS addressing:

>  Pri. Master  Disk : CHS ,Mode 4, 1282MB

> Boot up on the floppy, and create a Primary DOS Partition. Choose
> defaults. If you chose to use large disk support at the start of FDISK,
> then a FAT32x (ID 0xC) partition is created, else a FAT16x (ID 0xE)
> partition is created. If you were booting an earlier version of DOS,
> say DOS 6.22, then you won't have access to the FAT16x, FAT32
> or FAT32x, thus will be limited to creating a maximum of ~500MB
> FAT16 (ID 0x6) partition. Reboot.

> You can FORMAT it now, but it's not necessary for this experiment.

> Change the Primary Master MODE to back to "Auto",
> Save and exit. The BIOS still reports CHS mode. Why ?

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

> Delete the partition, reboot, the BIOS now reports LBA.
> Hmm, so if the Auto Hard disk mode setting was not
> influenced by a partition table, why did this happen ?

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

> Now try this. Change back to "Normal" mode, and then create a primary,
> but at a capacity such that it will have more than 1024 Cyls, in my case,
> half capacity 611MB looks fine, set the active partition to 1, change the
> Mode to "LBA" or "Large", now try and create an extended partition.

> Whoops, FDISK is saying that we have a 611MB partition,
> but the Total Disk space if 504MB. Strange. OK, so delete
> and recreate the primary partition. Reboot. Oh, look, the BIOS
> is reporting LRG, 1053MB. What happened to the other 229MB ?

> OK, lets see if I can create the extended partition now. Oh good, you can.
> But, we are still missing 229MB. Something seriously screwy here. Change
> the mode back to "Auto". It comes up as LBA, but still only 1053MB.

> Delete all partitions, reboot, now try. All is fine again.

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

> In summary, a partition table with signature and reasonably
> accurate entries, however they got there, will influence both
> the translation used (LBA, Normal, Large), and in some cases,
> the capacity of a drive. Sure, what I've described above shouldn't
> happen as an every day occurance, but that is not the point.

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

> Would someone like to try this with other BIOSes such as
> AMI, Phoenix, or MrBIOS, and later versions of Award ?

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

> If you want to investigate further, then you can use utilities like
> WDTBLCHK (ftp://ftp.wdc.com/drivers/hdutil/tablechk.exe), from
> which you can extract this type of info:

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

>
> MODEL:                 ST31270A
> CYLINDERS:                 2485
> HEADS:                       16
> SPT:                         63
> PHY. SECTORS:           2505528
> PHY. SIZE (MB):            1283
>
> HD mode  INT 13h, 8         INT 13h, 41/48                     Xlat Info
> ------- -----------------  --------------------------------- ------------
> Large 621 64 63 1281MB    621 64 63 2503872 sect (1282MB) CHS to CHS
> LBA 621 64 63 1281MB    621 64 63 2503872 sect (1282MB) LBA
> Normal 1024 16 63  528MB   2485 16 63 2504880 sect (1282MB) No Xlat
>
>
>
> I leave it as an exercise for the reader, to examine the differences between
> the various partition table entries, so as to be able to manually edit it
> with a disk editor like Nortons DISKEDIT. Tinker away, and you tell me...

> :)

Doesnt have the remotest relevance to your original claim
that the use of AUTO settings ALL THE TIME can produce
the symptoms that Ian saw spontaneously. Keep digging.

Keep bullshitting, fooling absolutely no one at all.

Richard RUDEK <x@invalid.zeta.org.au> wrote in message news:397eaaeb.36545850@news.zeta.org.au...

Even with an impossibly remote scenario of say a virus deliberately
overwriting the master boot record of a drive formatted using LBA
mode, with a valid CHS mast boot record for that particular physical
drive, which might well make the data appear to vanish, that STILL
doesnt explain the fact that when Ian replaced the master boot record
the copying of what data could be seen took a long time with
obvious retrys and recals and getting the data eventually.

It has always been much more likely that it wasnt the use of
AUTO settings at all but just an intermittent hardware failure.