🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.ibm.pc.hardware.misc
Article #85

Re: My hard drive does a Lazarus.

#85
From: Richard RUDEK
Date: Tue, 25 Jul 2000 00:00
143 lines
8178 bytes
"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/                           |
          |________________________________________________________|
Technical Details
Message-ID: <397da796.35367520@news.zeta.org.au>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <oor9nscq5ldltuk16h9il5atrgfrhqtusi@4ax.com> <3976fa9e.41626850@news.zeta.org.au> <39775e15$0$11143$7f31c96c@news01.syd.optusnet.com.au> <39787361.3040784@news.inet.tele.dk> <39779df9$0$11167$7f31c96c@news01.syd.optusnet.com.au> <39784439.1930310@news.zeta.org.au> <3978584a$0$11168$7f31c96c@news01.syd.optusnet.com.au> <jt_d5.30473$pD2.625571@news.tpnet.pl> <3979a943.642282@news.zeta.org.au> <397ac1ce$0$11186$7f31c96c@news01.syd.optusnet.com.au> <397b000e.4817808@news.zeta.org.au> <397b8135$0$11146$7f31c96c@news01.syd.optusnet.com.au>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 10d683,32a2c7d098843a09
X-Google-Attributes: gid10d683,public
X-Google-Thread: 1102f1,32a2c7d098843a09
X-Google-Attributes: gid1102f1,public
X-Google-Thread: 109e38,32a2c7d098843a09
X-Google-Attributes: gid109e38,public
X-Google-Thread: f4d7c,32a2c7d098843a09
X-Google-Attributes: gidf4d7c,public
From: x@invalid.zeta.org.au (Richard RUDEK)
Subject: Re: My hard drive does a Lazarus.
Date: 2000/07/25
Message-ID: <397da796.35367520@news.zeta.org.au>
X-Deja-AN: 650559749
References: <oor9nscq5ldltuk16h9il5atrgfrhqtusi@4ax.com> <3976fa9e.41626850@news.zeta.org.au> <39775e15$0$11143$7f31c96c@news01.syd.optusnet.com.au> <39787361.3040784@news.inet.tele.dk> <39779df9$0$11167$7f31c96c@news01.syd.optusnet.com.au> <39784439.1930310@news.zeta.org.au> <3978584a$0$11168$7f31c96c@news01.syd.optusnet.com.au> <jt_d5.30473$pD2.625571@news.tpnet.pl> <3979a943.642282@news.zeta.org.au> <397ac1ce$0$11186$7f31c96c@news01.syd.optusnet.com.au> <397b000e.4817808@news.zeta.org.au> <397b8135$0$11146$7f31c96c@news01.syd.optusnet.com.au>
X-Complaints-To: abuse@pacific.net.au
X-Trace: nina.pacific.net.au 964536249 15897 210.23.143.186 (25 Jul 2000 14:44:09 GMT)
Organization: Pacific Internet (Australia)
NNTP-Posting-Date: 25 Jul 2000 14:44:09 GMT
Newsgroups: comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.hardware.storage,comp.os.ms-windows.misc,aus.computers.ibm-pc