This is the 2nd time My HD's Been Corrupt

On Sat, 23 Oct 2004 01:10:10 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>> In this case they probably cannot handle the 16 heads BIOS setting.
>
>What makes you think that the driver is using 16-heads translation?
>Or did you mean to say that the 16-head bios setting is triggering the
>modulo ~32GB bug, since obviously it can't be using CHS mode at all?

Triggered. The wrap distance in this case is 65536*16*63 sectors.
There must be a connection.

>> If you currently do not have any partitions on the disk, you can auto
>> detect the disk in BIOS, and make sure a 255 heads translation is chosen.
>
>Are you implicating that the modulo ~32 GB bug is triggered when
>the heads value is unequal the large disk placeholder value (presuming
>heads fall within that category too)? What about the cylinder value?

No, if the BIOS setting does not match the partition tables, that
gives other problems, such as the partitions not following cylinder
boundaries, confusing partitioning tools.

>> Verify using the GB32 program that the problem was solved.
>
>Presumably that is after repartitioning with the 255 heads value.
>Shouldn't the drive be zeroed first before checking?

No. Making a false positive match would require that the sectors 0 to
999 were written 32 GB into the disk. A zeroed disk would give a false
positive match. That is why I say in the GB32 tool that the disk
should be partitioned before it can be checked.

>> An alternative is to update the disk drivers, and verify if the problem
>> is still present after that. For Microsoft drivers this update may work:
>>
>> http://support.microsoft.com/kb/q243450/
>>
>> What happens is that as soon as data should be written more than 32 GB
>> into the disk, they are written at the beginning of the disk in stead.

It should be noted that the update solves other problems than
described by Microsoft, and that it can be used with all BIOS brands.

Some months ago I promised here that I would make the GB32 program
detect the Windows 95/98/ME 128 GB problem. A version which will
detect one 128 GB problem is in

http://www.partitionsupport.com/gb32-12.zip

but I did not post a link to it before, since I am working on figuring
out yet another Windows 95/98/ME 128 GB bug, which really is beyond
understanding. My current recommendation would be that disks larger
than 128 GB only are used with Windows 95/98/ME with the newest
version of Intel Application Accelerator. In one Windows 98
installation I have, I simply have to force compatibility mode to use
a more than 128 GB disk.
--
Svend Olaf

"Svend Olaf Mikkelsen" <svolaf@partitionsupport.com> wrote in message news:417f204d.2345462@dtext.news.tele.dk
> On Sat, 23 Oct 2004 01:10:10 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>
> > > In this case they probably cannot handle the 16 heads BIOS setting.
> >
> > What makes you think that the driver is using 16-heads translation?
> > Or did you mean to say that the 16-head bios setting is triggering the
> > modulo ~32GB bug, since obviously it can't be using CHS mode at all?
>
> Triggered. The wrap distance in this case is 65536*16*63 sectors.

Except that you plucked that 65536 out of thin air.
That 65536 is not from the MBR. And not from the bios either
as (I'll assume) the bios reported the 116300, not 65536.
If it was the 16 heads then the wrap would be at 1024*16*63*512 = 504 MB.
If it was the heads then the wrap would be at different places depending on the
value of heads yet it always occurs at the FFFFFh*63*512/(1024*1024*1024) =
1048575*63*512/1073741824 = 31.5 GB.

> There must be a connection.

But it's not 65536*16*63 sectors, it's 20-bits*63 sectors or 31.5 GB.
The 65536 is only the result (representation) of 31.5GB/(16*63*512).
It doesn't matter what the number of heads is other than that it triggers
the use of that internal 20-bits register whereas a 'large drive' place
holder (1023/254/63) wouldn't.

My bet is that if one of the three C, H and S values in the MBR is lower
than the max number for that value, signalling a drive smaller than 8GB,
then the ~32GB bug in that driver is triggered.

Btw, didn't we see a similar problem with Win2k related to that?
Although in that case it was on the ATA interface side of the BIOS/
Driver, 15 heads vs 16 heads that forced the driver into CHS mode.

>
> > > If you currently do not have any partitions on the disk, you can auto
> > > detect the disk in BIOS, and make sure a 255 heads translation is chosen.
> >
> > Are you implicating that the modulo ~32 GB bug is triggered when
> > the heads value is unequal the large drive placeholder value (presuming
> > heads fall within that category too)? What about the cylinder value?
>
> No, if the BIOS setting does not match the partition tables, that
> gives other problems, such as the partitions not following cylinder
> boundaries, confusing partitioning tools.

That's assuming that the BIOS values can be different from the
values in the MBR and that the partitioning tools take the values
from the bios and not the MBR. I'm sceptical and the answer of
the OP appears to confirm my scepticism when auto came back
with the values that (presumably) already were in his MBR.

AIUI the bios either copies the CHS from the MBR when it is
there and when it's not, it recommends one based on the default
setting in the drive's Identify sector and translated into Int13
form based on the translation type setting chosen.

>
> > > Verify using the GB32 program that the problem was solved.
> >
> > Presumably that is after repartitioning with the 255 heads value.
> > Shouldn't the drive be zeroed first before checking?
>
> No. Making a false positive match would require that the sectors 0 to
> 999 were written 32 GB into the disk. A zeroed disk would give a false
> positive match. That is why I say in the GB32 tool that the disk
> should be partitioned before it can be checked.

Oops, did it again.

>
> > > An alternative is to update the disk drivers, and verify if the problem
> > > is still present after that. For Microsoft drivers this update may work:
> > >
> > > http://support.microsoft.com/kb/q243450/
> > >
> > > What happens is that as soon as data should be written more than 32 GB
> > > into the disk, they are written at the beginning of the disk in stead.
>
> It should be noted that the update solves other problems than
> described by Microsoft, and that it can be used with all BIOS brands.
>
> Some months ago I promised here that I would make the GB32 program
> detect the Windows 95/98/ME 128 GB problem. A version which will
> detect one 128 GB problem is in
>
> http://www.partitionsupport.com/gb32-12.zip
>
> but I did not post a link to it before, since I am working on figuring
> out yet another Windows 95/98/ME 128 GB bug,

> which really is beyond understanding.

Oh, hows that?
How can you top the 32GB wrap-around bug when that is already beyond
understanding?

> My current recommendation would be that disks larger
> than 128 GB only are used with Windows 95/98/ME with the newest
> version of Intel Application Accelerator. In one Windows 98
> installation I have, I simply have to force compatibility mode to use
> a more than 128 GB disk.

That then requires a 48-bit LBA compatible bios.

On Tue, 26 Oct 2004 20:29:55 +0200, "Folkert Rienstra"
<see_reply-to@myweb.nl> wrote:

>Except that you plucked that 65536 out of thin air.
>That 65536 is not from the MBR. And not from the bios either
>as (I'll assume) the bios reported the 116300, not 65536.
>If it was the 16 heads then the wrap would be at 1024*16*63*512 = 504 MB.
>If it was the heads then the wrap would be at different places depending on the
>value of heads yet it always occurs at the FFFFFh*63*512/(1024*1024*1024) =
>1048575*63*512/1073741824 = 31.5 GB.

A Goggle search gave me this:

>>Distance 4096*240*63: 1000 matches.
>>Distance 65536*16*63: 0 matches.
>>Distance 65536*15*63: 1000 matches.

Well, however we write the wrap values, the bottom line is that the
GB32 program catches all Windows 95/98/ME 32 GB cases.

>But it's not 65536*16*63 sectors, it's 20-bits*63 sectors or 31.5 GB.
>The 65536 is only the result (representation) of 31.5GB/(16*63*512).
>It doesn't matter what the number of heads is other than that it triggers
>the use of that internal 20-bits register whereas a 'large drive' place
>holder (1023/254/63) wouldn't.

I bet the problem is there, even with a not partitioned disk.

>My bet is that if one of the three C, H and S values in the MBR is lower
>than the max number for that value, signalling a drive smaller than 8GB,
>then the ~32GB bug in that driver is triggered.
>
>Btw, didn't we see a similar problem with Win2k related to that?
>Although in that case it was on the ATA interface side of the BIOS/
>Driver, 15 heads vs 16 heads that forced the driver into CHS mode.

I do only remember the 128 GB problem in Windows 2000.

>That's assuming that the BIOS values can be different from the
>values in the MBR and that the partitioning tools take the values
>from the bios and not the MBR. I'm sceptical and the answer of
>the OP appears to confirm my scepticism when auto came back
>with the values that (presumably) already were in his MBR.
>
>AIUI the bios either copies the CHS from the MBR when it is
>there and when it's not, it recommends one based on the default
>setting in the drive's Identify sector and translated into Int13
>form based on the translation type setting chosen.

>> which really is beyond understanding.
>
>Oh, hows that?
>How can you top the 32GB wrap-around bug when that is already beyond
>understanding?

It is beyond understanding how the driver writers were able to screw
this up, but it is understandable what the 32 GB problem does to the
disk content.

There now is a GB32 program at my page, which will detect three
different Windows 95/98/ME 128 GB problems. The disk does not need to
be partitioned to run the 128 GB tests.
--
Svend Olaf
http://www.partitionsupport.com/utilities.htm

"Svend Olaf Mikkelsen" <svolaf@partitionsupport.com> wrote in message news:417fe367.13653056@dtext.news.tele.dk
> On Tue, 26 Oct 2004 20:29:55 +0200, "Folkert Rienstra" <see_reply-to@myweb.nl> wrote:
>
> > Except that you plucked that 65536 out of thin air.
> > That 65536 is not from the MBR. And not from the bios either
> > as (I'll assume) the bios reported the 116300, not 65536.
> > If it was the 16 heads then the wrap would be at 1024*16*63*512 = 504 MB.
> > If it was the heads then the wrap would be at different places depending on the
> > value of heads yet it always occurs at the FFFFFh*63*512/(1024*1024*1024) =
> > 1048575*63*512/1073741824 = 31.5 GB.
>
> A Google search gave me this:
>
> > > Distance 4096*240*63: 1000 matches.
> > > Distance 65536*16*63: 0 matches.
> > > Distance 65536*15*63: 1000 matches.

So while you have a point in your favor, again your example shows
that the first and last are just the same values, written differently.

Further testing may reveal what effect non full binary values for
heads (15 instead of 16, 240 in stead of 256) have on the outcome.
Your numbers appear to suggest that it reserves the number of bits
needed for heads in that 20-bits of mine and then use the remainder
for cylinders, to the full. And since you provided some probable proof
that it is counting with the actual number provided for heads it is
interesting to see what happens for sectors other than 63 as well.
But that will probably need some special preparing.

>
> Well, however we write the wrap values, the bottom line is that the
> GB32 program catches all Windows 95/98/ME 32 GB cases.

Well, as you kind of proved, it isn't really 32GB.
And while you shot a hole in my theory I still think it is a 20-bit re-
gister (or a 26-bit register if you include sectors) that is used and is
causing the wrap as soon as the bits used for cylinders are all used up.

It would be interesting to see what happens with say 130 heads.
That would predict the wrap at 4096*130*63*512 = 16 GB.
(1111 1111 1111)*(1000 0001)*(11 1111)

If that's the case then you may want to simulate the bug (use the same
numbers converted to 20 (or 26) bits to catch all cases, instead of the
most common ones that you are doing now.

>
> > But it's not 65536*16*63 sectors, it's 20-bits*63 sectors or 31.5 GB.
> > The 65536 is only the result (representation) of 31.5GB/(16*63*512).
> > It doesn't matter what the number of heads is other than that it triggers
> > the use of that internal 20-bits register whereas a 'large drive' place
> > holder (1023/254/63) wouldn't.
>
> I bet the problem is there, even with a not partitioned disk.

Probably, as it is not the disk drive, but the number(s), where ever it is
supplied from. What keeps you from changing GB32 to check it that
way? It must be quite easy to check whether the first 1000 sectors
are empty and then write them with a pattern before the actual check.

>
> > My bet is that if one of the three C, H and S values in the MBR is lower
> > than the max number for that value, signalling a drive smaller than 8GB,
> > then the ~32GB bug in that driver is triggered.

Are you game?

> >
> > Btw, didn't we see a similar problem with Win2k related to that?
> > Although in that case it was on the ATA interface side of the BIOS/
> > Driver, 15 heads vs 16 heads that forced the driver into CHS mode.
>
> I do only remember the 128 GB problem in Windows 2000.

It was the Win2k 8 GB bug, see:
Re: 8 GB barrier in XP and W2k for 20 GB Seagate HDD ST320420A

>
> > That's assuming that the BIOS values can be different from the
> > values in the MBR and that the partitioning tools take the values
> > from the bios and not the MBR. I'm sceptical and the answer of
> > the OP appears to confirm my scepticism when auto came back
> > with the values that (presumably) already were in his MBR.
> >
> > AIUI the bios either copies the CHS from the MBR when it is
> > there and when it's not, it recommends one based on the default
> > setting in the drive's Identify sector and translated into Int13
> > form based on the translation type setting chosen.
>
> > > which really is beyond understanding.
> >
> > Oh, hows that?
> > How can you top the 32GB wrap-around bug when that is already
> > beyond understanding?
>
> It is beyond understanding how the driver writers were able to screw
> this up,

Well, lets see whether it is understandable or not.

> but it is understandable what the 32 GB problem does to the disk content.

So what does the 128 GB bug do that isn't understandable in the way
the ~32GB bug presents itself? The fact that you know how to detect
it seems to suggest that it actually is understandable or else you would
not know what to look for.

>
> There now is a GB32 program at my page, which will detect three
> different Windows 95/98/ME 128 GB problems.

> The disk does not need to be partitioned to run the 128 GB tests.

But it still needs to be for the ~16-32GB bug?