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

[LaLa Land]

On this Abit BH6, there are 3 drives:

Primary Master: IBM 45GB
Primary Slave: Quantum 40GB
Secondary Master: Western Digital 60GB
Secondary Slave: Norcent 40X CD-RW

Problem Drive: Western Digital 60GB


Drive was originally purchased in April 2003, but failed in December
2003. WD sent me a refurbished drive in January 2004. After a few
months, the disc became corrupt. What happened was this:

As I was moving files to this drive, Windows 98SE would give me the
error that this drive was full. Actually, there should have been 47GB
free. Anyway, on reboot the bios sees the drive. Unfortunately,
Windows says:

--------------------------------------------------------------
D:\ is not accessible.
A Device attached to the system is not functioning.

-------------------------------------------------------------

DOS does not see it either. Luckily, the utility "GetDataBack" was
able to recover the files. I reformatted and everything was fine for
a few months until a couple of days ago. This exact same thing has
happened again. What is going on? I can recover the data like last
time, but this is getting annoying. I don't want to spend hours
recovering, reformatting, moving data to this drive if the same errors
are going to happen again. So, what is the problem?

1. Bad Abit BH6 controller?
2. Bad IDE Cable?
3. Bad WD refurb HD even though it passed WD diagnostics?
4. Bad WD utility that formatted drive?
5. Unknown virus?
6. Wrong BIOS setup?

Thanks for any suggestions.

 

[Svend Olaf Mikkelsen]

On this Abit BH6, there are 3 drives:

Primary Master: IBM 45GB
Primary Slave: Quantum 40GB
Secondary Master: Western Digital 60GB
Secondary Slave: Norcent 40X CD-RW

Problem Drive: Western Digital 60GB


Drive was originally purchased in April 2003, but failed in December
2003. WD sent me a refurbished drive in January 2004. After a few
months, the disc became corrupt. What happened was this:

As I was moving files to this drive, Windows 98SE would give me the
error that this drive was full. Actually, there should have been 47GB
free. Anyway, on reboot the bios sees the drive. Unfortunately,
Windows says:

--------------------------------------------------------------
D:\ is not accessible.
A Device attached to the system is not functioning.

-------------------------------------------------------------

DOS does not see it either. Luckily, the utility "GetDataBack" was
able to recover the files. I reformatted and everything was fine for
a few months until a couple of days ago. This exact same thing has
happened again. What is going on? I can recover the data like last
time, but this is getting annoying. I don't want to spend hours
recovering, reformatting, moving data to this drive if the same errors
are going to happen again. So, what is the problem?

1. Bad Abit BH6 controller?
2. Bad IDE Cable?
3. Bad WD refurb HD even though it passed WD diagnostics?
4. Bad WD utility that formatted drive?
5. Unknown virus?
6. Wrong BIOS setup?

Thanks for any suggestions.

It seems possible, but not likely, that it is the 32 GB problem. To
check for that you can download the GB32 program at

http://www.partitionsupport.com/utilities.htm

do in a Windows 98 DOS box (assuming the Western Digital is disk 3
numbered from 1):

gb32 3 fp-a.txt

If the 32 GB problem is present, it may be present for the other disks
too.

 

[LaLa Land]

It seems possible, but not likely, that it is the 32 GB problem. To
check for that you can download the GB32 program at

http://www.partitionsupport.com/utilities.htm

do in a Windows 98 DOS box (assuming the Western Digital is disk 3
numbered from 1):

gb32 3 fp-a.txt

If the 32 GB problem is present, it may be present for the other disks
too.

You're right. Here are the results:

IBM 45GB: No known 32 GB problems were observed.
Quantum 40GB: No known 32 GB problems were observed.


However, Western Digital 60GB's output:
_______________________________________________
GB32, version 1.1 Copyright Svend Olaf Mikkelsen, 2001.

OS: DOS 7.10 WINDOWS 4.10

Disk: 3 Cylinders: 116300 Heads: 16 Sectors: 63 MB: 57241

Comparing sector 0 to 999 with an area later on the disk:

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

A 32 GB problem is present.

_________________________________________________


I have never heard of this 32GB issue before. Is there anything that
I can do with this system to eliminate this issue? Or, is a new ide
card or installing overlay software the only solution?

Thanks.

 

[Tom]

You're right. Here are the results:

IBM 45GB: No known 32 GB problems were observed.
Quantum 40GB: No known 32 GB problems were observed.


However, Western Digital 60GB's output:
_______________________________________________
GB32, version 1.1 Copyright Svend Olaf Mikkelsen, 2001.

OS: DOS 7.10 WINDOWS 4.10

Disk: 3 Cylinders: 116300 Heads: 16 Sectors: 63 MB: 57241

Comparing sector 0 to 999 with an area later on the disk:

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

A 32 GB problem is present.

_________________________________________________


I have never heard of this 32GB issue before. Is there anything that
I can do with this system to eliminate this issue? Or, is a new ide
card or installing overlay software the only solution?

I ran four 120 GB WD drives each had two partitions. They were connected
to a Promise Ultra133TX2 controller. This was in a 5 year old computer
with a no-name motherboard. Never had a problem. My only concern was
hitting the 64GB limit of some of the Win98se included apps (eg:
scandisk, etc.).

 

[Svend Olaf Mikkelsen]

You're right. Here are the results:

IBM 45GB: No known 32 GB problems were observed.
Quantum 40GB: No known 32 GB problems were observed.


However, Western Digital 60GB's output:

GB32, version 1.1 Copyright Svend Olaf Mikkelsen, 2001.

OS: DOS 7.10 WINDOWS 4.10

Disk: 3 Cylinders: 116300 Heads: 16 Sectors: 63 MB: 57241

Comparing sector 0 to 999 with an area later on the disk:

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

A 32 GB problem is present.

I have never heard of this 32GB issue before. Is there anything that
I can do with this system to eliminate this issue? Or, is a new ide
card or installing overlay software the only solution?

Thanks.

The problem is the Windows disk drivers. In this case they probably
cannot handle the 16 heads BIOS setting. 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. If partitions are
present, the BIOS setting should not be changed. Verify using the GB32
program that the problem was solved.

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.

 

[Folkert Rienstra]

The problem is the Windows disk drivers.

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?

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?

If partitions are present, the BIOS setting should not be changed.

What if you do? The setting is not used untill (re)partitioning time.

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?

 

[Arno Wagner]

On Oct 22 2004, LaLa Land wrote:

I ran four 120 GB WD drives each had two partitions. They were connected
to a Promise Ultra133TX2 controller. This was in a 5 year old computer
with a no-name motherboard. Never had a problem. My only concern was
hitting the 64GB limit of some of the Win98se included apps (eg:
scandisk, etc.).

Same experience here. The Promise controllers do LBA so no 32GB limit.
Works with older hardware.

Arno

 

[Folkert Rienstra]

Same experience here. The Promise controllers do LBA so no 32GB limit.

Utterly clueless.

 

[LaLa Land]

The problem is the Windows disk drivers. In this case they probably
cannot handle the 16 heads BIOS setting. 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. If partitions are
present, the BIOS setting should not be changed. Verify using the GB32
program that the problem was solved.

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.

Strange, when set to "auto" in the bios, the Abit BH6 correctly chose
255 heads for the other drives, but not this Western Digital. Looks
like I will spend this weekend moving all the data, changing the bios
setting and then fdisk/reformat. That update Microsoft driver seems
to refer to a Phoenix bios, but not an Award which Abit uses, so I
will not install that.

Thank you for your help.

 

[Svend Olaf Mikkelsen]

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.

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 does not follow cylinder
boundaries, confusing partitioning tools.

 

[Svend Olaf Mikkelsen]

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.

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.

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.

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.

 

[Folkert Rienstra]

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.

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.

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.

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.

 

[Svend Olaf Mikkelsen]

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:

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.

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.

 

[Folkert Rienstra]

A Google search gave me this:

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.

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.

Are you game?

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

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?