Maximum Disk size on the ide1/ide2 controllers.

Peripherals, parts, data storage...
Post Reply
oli
Posts: 6
Joined: Tue Jul 13, 2004 2:50 am
Contact:

Maximum Disk size on the ide1/ide2 controllers.

Post by oli »

Hi, I've seen a few threads where people have said that they have large disks on their extra TX2 controllers, and I know that the HPT366 controller doesn't support drives over 137GB (I don't want to use it anyway).

Anyway my BP6 system has an Adaptec SCSI card with 3 Quantum SCSI drives attached to it, I wanted to add some more storage space and was thinking of buying a 200GB disk. Since it's for non intensive storage, speed is not a big issue, I don't want to go out and buy a TX2 with it if it's not necessary. I've searched all over for limitations both on the i440BX chipset and on the BP6 board but can't find any information about what the maximum drive size is that the onboard controller will handle? That is, the 1st and 2nd IDE channels!

So can anyone tell me, Will I be able to connect a 200GB drive to IDE1 or IDE2? If not, what is the maximum drive size I can connect to the onboard IDE1/IDE2 adapter?
BCN
Posts: 508
Joined: Tue Nov 26, 2002 9:50 am
Location: Barcelona, Spain
Contact:

Post by BCN »

I think you will be connect to it, no probs, but if it does not see above certain size, so then be certain to chop your hard into partitions that do not exceed that limit....

maybe I am wrong.....
Dual C366@550MHz 1.90V :) (History)
yet single PIII-S 512Kb L2 cache at 1400MHz@700MHz
BP6 (not modded yet)
256MB PC133 C2
GF4Ti4200-8x
Maxtor 2x60Gb - all on promise ATA133
Lite-On LTR 40125S@48125W!!!
Plus P4 system
Holodeck2
Modder Extraordinaire
Posts: 256
Joined: Fri Jun 13, 2003 12:57 am
Location: Purdue University
Contact:

Post by Holodeck2 »

if you format them in NTFS I think win2k and XP will support 137Gb+ just fine. HDDs also come bundled with software to take care of that problem too
you might need to use ATA/100 I think...
yea, back from the dead

If it ain't broken, mod it until it is
oli
Posts: 6
Joined: Tue Jul 13, 2004 2:50 am
Contact:

Post by oli »

I want to install Linux on the SCSI drives and use the 200GB for storage, I might just have to try it and see how I go - if it doesn't work I'll go buy a TX2
InactiveX
BeOS Forever
Posts: 1385
Joined: Wed Jul 24, 2002 8:25 am
Location: UK

Post by InactiveX »

Hi there oli, hope you are enjoying BP6.com. :)

Please let us know what happens, this info should be in the FAQ.
RRLedford
HPT IS EVIL!
Posts: 604
Joined: Wed Jul 24, 2002 11:15 pm
Location: Chicago USA

Post by RRLedford »

The Promise ATA-100/133 can be found for ~$20.
If your time has any value - 200GB of crashed drive can represent a lot of time ==> money.
So do yourself a big favor & get a Promise card!
Zero point energy
BCN
Posts: 508
Joined: Tue Nov 26, 2002 9:50 am
Location: Barcelona, Spain
Contact:

Post by BCN »

don't think the drive could get trashed if it connected to IDE (normal) and not to HPT666 :)
Dual C366@550MHz 1.90V :) (History)
yet single PIII-S 512Kb L2 cache at 1400MHz@700MHz
BP6 (not modded yet)
256MB PC133 C2
GF4Ti4200-8x
Maxtor 2x60Gb - all on promise ATA133
Lite-On LTR 40125S@48125W!!!
Plus P4 system
Holodeck2
Modder Extraordinaire
Posts: 256
Joined: Fri Jun 13, 2003 12:57 am
Location: Purdue University
Contact:

Post by Holodeck2 »

the HPT is evil you should just take a hot glue gun to the connectors of that and seal up the gates of hell
yea, back from the dead

If it ain't broken, mod it until it is
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Hi oli (that doesn't happen to be the Icelandic name "'Óli" now does it?)

If you are going to run Linux on that drive then you should be safe since Linux doesn't care how BIOS thinks how large it should be after boot. I ran a 40 GB drive in a Pentium Pro machine that had a BIOS induced 8.4 GB limit on it, and yes, it was only a single partition of 40GB that I used. I can't see how this would be different from the 137GB limit imposed by newer BIOS'es. This post deals with the same issue:

http://www.bp6.com/board/viewtopic.php?t=2313
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
oli
Posts: 6
Joined: Tue Jul 13, 2004 2:50 am
Contact:

Post by oli »

purrkur: No, it's from the German name "Oliver"

Thanks for your help everyone, I think I'll be using the onboard controller since Linux will ignore whatever the BIOS picks up and be able to use all the space anyway.

Later if I want to add more drives, then I'll get a TX2 of course, but since I am booting from SCSI drives and have no optical drives that might take awhile since I can use the two channels onboard (not the HPT) for 4 drives first anyway...

Unfortunately I can't do this for a few weeks yet anyway because a guest is using the PC - but once they've left I'll be setting it all up!
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

I always thought the BIOS had to support 48bit LBA, regardless of the OS. But that's obviously wrong. In addition to the comments already given, Intel says you need BIOS support only if you use the Windows 9x OS series. Not needed for W2K/XP.

From my experience, the HPT366 does not like Seagate drives (7200.7, U6, 5400.1). But I had no trouble with any drive (up to 120GB) on the standard IDE to date. Would still recommend an external controller, because from my experience you will be limited to about 25MB/s maximum STR on the standard IDE.
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Wolfram wrote:From my experience, the HPT366 does not like Seagate drives (7200.7, U6, 5400.1). But I had no trouble with any drive (up to 120GB) on the standard IDE to date.
What type of problems have you run into with the Seagates and HPT366? I am a big Seagate shop although I haven't tested on of those on the 366...

Also, I think the BIOS limit for the BP6 and harddrives is 137 Gigs, or so it seems from the comments made by fellow BP6:ers. ..
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

purrkur wrote:
Wolfram wrote:From my experience, the HPT366 does not like Seagate drives (7200.7, U6, 5400.1). But I had no trouble with any drive (up to 120GB) on the standard IDE to date.
What type of problems have you run into with the Seagates and HPT366? I am a big Seagate shop although I haven't tested on of those on the 366...
The system froze with a 7200.7 80GB installed (http://www.bp6.com/board/viewtopic.php? ... highlight=).

My U7 (not a U6, like I said, sorry) 60GB suffered from data corruption. All of a sudden the partition table was destroyed. Could recover the data anyway.

My current Samsung SV1203 (120GB) is recognized with a wrong size (~"58 GB") by the HPT366 BIOS, but it works nicely.
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Wolfram: What OS do you use??
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

purrkur wrote:Wolfram: What OS do you use??
Windows 2000 SP4.
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Wolfram: OK. It would be good to know if I would see the same issues in Linux. I have done some digging into the HPT366 and why it has issues with some drives and I have found that some of the issues are caused by the BIOS and some are caused by the kernel (and are not a failure of the chip itself). The reason why I have been doing this is because when things break, I like to know why. "It sucks" just doesn't cut it as a reason for me.

I have found some Linux kernel issues relating to the 366 and Seagate drives but these have been fixed in later versions of the kernel. That is the good part about Linux. You can identify issues and fix/patch them. If you are running Windows you are at the mercy of Microsoft which usually doesn't patch these type of things.

I guess I better get myself a new Seagate drive to run on the 366. My experiments with an older 12 gig IBM drive on the 366 have gone really well. I have given it hard thrashing but it has been rock-solid and performance has been good too. The 366 has also responded predictably to Linux IDE control tools. I might write a report on this once I go on vacation and post it here.
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

purrkur wrote:Wolfram: OK. It would be good to know if I would see the same issues in Linux. I have done some digging into the HPT366 and why it has issues with some drives and I have found that some of the issues are caused by the BIOS and some are caused by the kernel (and are not a failure of the chip itself). The reason why I have been doing this is because when things break, I like to know why. "It sucks" just doesn't cut it as a reason for me.
Nice attitude. Everybody seems to know that the HPT366 is bad but noone seems to know why.

The speed is said to be slow. Just read in the emerging FAQ for de.comp.hardware.laufwerke.festplatten (festplatten=harddisks) that the HPT366 seems to have timing problems. But that is concluded from the observation(?) that overclocking the PCI bus by 1-3 Mhz is said to help.
But for me my BP6 always felt noticeably more responsive when the harddisk was on the HPT366 than on the standard IDE.

The HPT366 is said to cause corruption, some even say it has destroyed their drive. Can't confirm that. Only case of data corruption was with the U7, no problems with a WD 20GB, two different 40GB Fujitsus or the Samsung SV1203N.

I wouldn't dare to say all the people claiming the HPT366 is bad are wrong. But is it really a piece of trash?
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
Stobe
Posts: 32
Joined: Thu Jun 10, 2004 5:01 am
Location: .fi

Post by Stobe »

I never had any problems with the HPT366 despite the fact that I ran IBM Deathstar disks on it for several years (yes, the system disk too!)

Always upgraded the drivers and BIOS as they came out, even after Abit stopped posting them on their site (got them directly from Highpoint's site.) I read on several websites that HPT was total crap and Deskstars were even worse, and hey, maybe they balanced each other out? :D

Well, since then I've sold all my ATA hard disks and now I only have SATA disks. I just wanted to let you know that I never had any data loss, data corruption or weird noises coming from my hard drives although I used the BP6 UDMA controller for a long time. But don't take my word for it, 'cause even emperors have to sh*t sometime! :shock:
Sto be or not Sto be, that is not even a question...
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Stobe wrote:Always upgraded the drivers and BIOS as they came out, even after Abit stopped posting them on their site (got them directly from Highpoint's site.) I read on several websites that HPT was total crap and Deskstars were even worse, and hey, maybe they balanced each other out? :D
Hehehe! You mean like when you multiply two negative numbers you get a positive :D That must mean what I have thought all along about my Seagate drives. They are pretty good! :)

Wolfram: I wouldn't mind gettng an exact copy of my Seagate drive I got hooked up to my BP6 already (not the 366). It is a 40 Gig 7200.7 drive so it would be good fun to have two of the same connected to each adapter to see how they perform. In my opinion, the *real* speed increase between the two shouldn't be all that great and probably not noticable by the user. I think that it is just like going from AGP 2x to AGP 4x . The latter is faster but my just a small percentage so it is not noticable by the user. I know many will disagree with me but my experience shows that there is always a huge difference between theoretical speeds and actual speeds in the computer world. AGP is one such case and so is dual DDR memory setups. My theory is that IDE speeds fall into that category as well.

Oh, well. I guess it is time to put my money where my mouth is :D

Also, if you are interested: The issues the kernel was having with Seagate drives connecting to the 366 was a DMA issue which the kernel couldn't really turn on but it tried and so messed up its communications with the drive. However, the bugfix was apparently an easy, straightforward job (after they had read the HPT366 specifications :) ). I think I will end up getting one of those drives to play around with but it will have to wait until next month when I finally will get some vacation time.
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

Some very interesting info about the HPT366 and 48bit LBA. It's about the BE6II, but I'd guess it also applies to the HPT366 on the BP6.

Taken from:

http://www.motherboard-forum.com/abit/2 ... 24471.html (bottom of the page, bold accentuations by me)
Date: 06 Jul 2004 07:49:03
From: Bill Drake
Subject: Re: 200GB HDD on Abit BE6-II?

To use the BE6-2 with the HPT366 controller and Hard Disk Drives
larger than 64GB, you require an update to the HPT366 BIOS
insert in the BE6 motherboard BIOS.

The latest version of the BE6-2 BIOS available from Abit themselves
is Version 70. This BIOS contains the HPT366 Version 1.25 BIOS
insert -- which has a 64GB HDD Size Limit. This limitation makes
the use of a 200GB hard disk impossible with the HPT366 chip.


Fortunately, the HPT366 Version 1.28b BIOS increases the HDD
Size Limit to a minimum of 137GB (LBA 32)
. A version of the
BE6-2 Version 70 BIOS -- modified to include the Version 1.28B
HPT366 BIOS insert was created some months ago and uploaded
to Tom Geery's FTP Server.

The modified BIOS is called BEH70128.ZIP -- which is available in
the "Beta" BIOS section on Tom Geery's FTP Server at:

ftp://geerynet.d2g.com


Caveats, wrinkles and "gotchas":

1. It is *confirmed and verified* that the above BIOS works properly
with Hard Disks smaller than 137GB (LBA 32). I have personally
verified correct operation under both Windows 2000 and Windows
XP with disks of both 80GB and 120GB using the above BIOS.

2. It is *unknown* at this time whether this BIOS works properly
with Hard Disks larger than 137GB (LBA 48). If you wish to
experiment with this possibility, please let the newsgroup know
the results of your experiments.

3. It is known that this BIOS *requires* the use of updated HPT366
Drivers. Either Version 1.25.1, Version 1.28b or Version 1.30b
are required for proper compatibility with the Version 1.28b
HPT 366 BIOS insert.

Note: The order shown above is the preferred order of driver
installation. Version 1.25.1 is the latest version of the
HPT366 driver. Version 1.28b has specific bugfixes for
some IBM Hard Disk firmware compatibility bugs.
Version 1.30b has specific bugfixes for some Maxtor
Hard Disk firmware compatibility bugs.

It is highly recommended to try the 1.25.1 driver first.
If this driver causes system instability, then one of the
other drivers may be tried as an experiment. However,
please note that there are some Hard Disk models that
will not work properly with *any* of the abovementioned
drivers -- and the user in this situation will have to change
their installed Hard Disk to a make and model compatible
with the HPT366 controller and the abovementioned
drivers.

4. There is a *known* shutdown-compatibility problem with
Windows 2000 and Windows XP when using the HPT366
controller. The problem manifests itself as intermittent hard
disk corruption on shutdown -- which causes the machine to
run NT Chkdsk on the next startup after a full power-off
shutdown.


This problem can and does create a "creeping paralysis"
situation with Windows 2000 and Windows XP installations.
Since by far the most common files written and modified on
Windows systems are the Registry -- can you guess which
files get corrupted most commonly by the abovementioned
bug?

5. The compatibility problem mentioned above occurs because
none of the existing HPT 366 drivers properly force the Hard
Disk to disable its write-behind caching as part of the
Windows 2000/XP shutdown process.


The above is a known error that Microsoft have tried to fix
through many Windows XP updates and revisions. Regardless,
this problem remains *unfixed to date* as far as the HPT366
IDE controller chip is concerned. It is unconfirmed at this
time whether this is a Microsoft or Highpoint omission.

As a result of the above, it is *absolutely mandatory* that the
Hard Disk Firmware in the drive itself properly bulletproofs its
own shutdown process. As of the date of this post, the *only*
Hard Disks that I have found that reliably perform the required
bulletproofing are made by Samsung.

I have tested Quantum, Maxtor and Seagate drives -- up to
and including current Maxtor and Seagate drive production to
date. All these brands and models have failed to properly
handle their cache-flush through hardware and as a result,
disk-data-corruption-on-shutdown has occurred.


Occasionally, the Samsung drives will also trigger an NT
Chkdsk at restart. However, so far I have found this
Chkdsk run finds no errors and Windows starts normally.
As a result, when this error occurs on the Samsung drives,
I can only assume the "cache-dirty" bit was not cleared,
even though all the in-cache info was properly written to
disk before power-off occurred.

6. It is *possible* the above shutdown-problem is related
to the size of the hardware disk-cache on the Hard Disk
in use with the HPT366 controller.

If the problem persists when using a Hard Disk with an
8MB hardware cache on the drive, then the problem
*may* be solved by using a Hard Disk with a 2MB
hardware cache instead. You may wish to experiment
with this possibility.


Conclusion:

I recommend extreme caution when using untested Hard
Disks under the HPT366 controller. A current full Ghost
Image of the Hard Disk should be maintained at all times,
and multiple ghost images should be taken at regular
intervals during the XP or 2000 install-process so the
machine can be easily recovered if one or more of the
shutdowns during the install-process induces disk data
corruption.

During installation, it is highly recommended that you do
*not* perform Power-Off shutdowns during the build or
update process. Power-On reboots are perfectly OK,
because the power is not removed from the Hard Disk
and therefore the Disk Cache data is always preserved
and written to the disk as part of the restart.

It is *only* when the machine is allowed to completely
power down that your data is at risk.


Hope the above helps your understanding.


Best I can do for now. <tm >


Bill
This might explain why my current Samsung 120GB drive works on the HPT366 while I had problems with Seagate drives.

Note that you can't enable/disable the write cache for drives connected to the HPT366 in the device manage (it's greyed out). You can do that for drives on the standard IDE.
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
Wolfram
Posts: 401
Joined: Tue Jul 30, 2002 3:19 am
Location: Germany

Post by Wolfram »

double post
BP6, RU BIOS, XP SP3, ACPI, 2x366@523(1,95V), Pentalpha HS + 1x 12cm fan @5V, 768MB, Powercolor Geforce 3, RTL8139D NIC, Terratec EWS64L, Samsung M40 80GB (2,5''), LiteOn CDRW
purrkur
Linux Guru
Posts: 687
Joined: Fri Dec 12, 2003 5:57 pm
Location: Sweden
Contact:

Post by purrkur »

Hello Wolfram,

Your posts are most interesting as always :)

I read the post and found myself asking more questions than I felt it answered. It seems like the author has got decent knowledge but he leaves too many unanswered questions. For example:

1.
This limitation makes the use of a 200GB hard disk impossible with the HPT366 chip
This is only true if you are talking of Windows as an operating system. Linux doesn't care one bit about what restrictions BIOS puts on harddisk size.

2.
Note: The order shown above is the preferred order of driver
installation.
He has got a lot of those statements on requirements and preferred order etc. What are his sources? Where does he get his information from?

3.
There is a *known* shutdown-compatibility problem with
Windows 2000 and Windows XP when using the HPT366 controller. The problem manifests itself as intermittent hard disk corruption on shutdown -- which causes the machine to run NT Chkdsk on the next startup after a full power-off shutdown.
What? I would like to see references to Microsofts Knowledgebase on this one. I simply cannot accept this since I could find no references on this at all in their kbase, so this bug cannot be *known*. He is not entirely incorrect about the shutdown problem but he is missing the point in my opinion, although he does touch upon it (without explanation) in point 6 in his list. Let me explain later.

4.
The compatibility problem mentioned above occurs because
none of the existing HPT 366 drivers properly force the Hard Disk to disable its write-behind caching as part of the Windows 2000/XP shutdown process.
This isn't really true. From what I understand, the controller driver doesn't tell the drive to do that. The operating system tells the harddrive to flush its cache. More on this later.

5.
As a result of the above, it is *absolutely mandatory* that the
Hard Disk Firmware in the drive itself properly bulletproofs its own shutdown process. As of the date of this post, the *only* Hard Disks that I have found that reliably perform the required bulletproofing are made by Samsung.
Again, he is headed in the right direction, but he doesn't quite make it and his statement about the hard disk firmware securing the shutdown process is wrong because there are other factors involved that the harddrive has no control over! What if the harddrive isn't allowed to complete its own shutdown process?? Again, I'll explain below.

6.
I recommend extreme caution when using untested Hard
Disks under the HPT366 controller.
OK. I'll admit that the HPT366 isn't the best behaved controller out there but I think it is once again getting full blame for things not working when it actually shouldn't! This is again because people maybe don't always know exactly what goes on when the computer shuts down (for example). The author also doesn't seem to fully know what is responsible for doing what. He mentions bugs in the Windows OS that cause HPT366 problems, he talks of the HPT366 driver that doesn't work as they should and then how the harddrive itself should flush its cache but doesn't. I find his train of thought quite confusing.

OK. Let me do some explaining. The cache that we are talking about is the write-back cache as opposed to write-through cache. Write-through caching effectively means that write operations are sent directly to the disk (to the platter) before the operating system (OS) is told that the information sent has been safely stored. Write-back cache uses the onboard cache memory as a buffer to temporarily store information. After the information is written to cache, the drive will tell the OS that the information has been stored. The adapter will then in its own time move the data to the hard disk platter. Disk cache is an electronic method used for speeding up the communication between a fast device and a slow device (in this case meaning the fast electronic data bus and the slow mechanics of the hard disk). This cache is the memory that is found built into the harddrive (in the case we are talking about). For awhile, 2 megs of memory was quite popular and so was 8 megs of memory. We are however beginning to see IDE/ATA drives with 16 megs of cache memory.

How does it work? Well, The operating system is responsible for activating this cache. When the OS activates this cache, the harddrive access will dramatically increase but you also become vulnerable for loosing data. Why is That? Look at the definition for write-back cache above. When the OS flushes data to disk, the disk will enter that data into it's cache and tell the OS that the data is on disk already. However, it is not. It is only found in the cache memory and not on the actual platter. In order to be able to guarantee delivery from the cache to the platter, you would need battery backup of the cache like most SCSI adapters have. But these drives are cheap so nobody wants to add a battery to it in order to make sure we don't loose data. So basically, if you have 8 megs of cache on your drive and 6 megs are being used when your power goes off then that means that 6 megs of memory that the OS believes is on disk is lost. This is effectively what Bill (the author of the article Wolfram showed us) is talking about.

But why does this happen at shutdown? Why is the Windows registry so affected? Is there really a Microsoft bug that messes with the HPT366? Do Quantum, Maxtor and Seagate drives have broken firmware that don't allow the drive to empty (flush) its cache to the platters at shutdown?? If yes, then why doesn't this "bug" show up on any controller you connect it to??? Let me try to fill in the holes that Bill misses!

OK. So lets take a scenario. An older motherboard (like the BP6) connected to a new harddrive with 8 meg cache that is activated by the OS. The OS continuously flushes information to the drive as expected and the drive is telling the OS that the information has been successfully stored, even though it has only been entered into the drive cache and nothing else. Lets say that 6 megs out of 8 are being continuously used (unrealistic but lets say it for arguments sake).

Now the user decides to shut down the computer. He gives the command and the OS starts going through its shutdown process. First and foremost, the OS must flush all open data down to disk. The write-back cache is activated so the OS just writes (remember that writing to a write-back cache is about 10-20 times faster than writing directly to the disk) and believes that the information has been stored because that is what the drive is saying. After the OS has flushed all the information to disk, the drive is still left with lets say 3 megs of data in its on cache. However, the OS believes that the information is stored so it gives the signal to the ATX powersupply to *shut down*!!!! This effectively means that the power to the drive is cut and everything that was left in the cache is now gone!!!

So why is the registry so affected? Because one of the last things that Windows does at shutdown is to write "last known" information down to the registry. This information is now gone so the next time you start windows, things might get very strange, and if you do this often (which you do because windows is the king of reboots) then you slowly but surely start corrupting the registry (if you don't kill it alltogether resulting in a BSOD).

Why did I specifially state an "old" motherboard in my example above? Well, for a few reasons. Fact of the matter is that this problem became known some time ago and it was fixed in many new motherboards. They simply don't allow the OS to shut down the power until after a little while, diving the drives time to flush. When older motherboards were made, the write-back cache size was maybe 64 to 512 kbytes in size so this wasn't really a problem. Take an older motherboard and set it up with a new drive and you will run into problems. This is why Bill mentions in his point 6 that if you are seeing this problem with your drive with 8 meg cache then you might get rid of it by using a drive with 2 meg cache instead (but he seems to miss the reason why).

So the statement that firmwares in many drives are broken and don't allow cache flush is simply wrong. The reason for the breakdown is that the flush process never gets executed from beginning to end. Why does Bill mention that many drives excluding Samsung seem to be affected? This is a very good question. Go back to my point about battery backup. Battery backup of the electronic cache is used on many expensive I/O adapters, especially SCSI adapters. However, there is another way of providing electronic backup without the use of battery. You integrate a large (in terms of micro-Farad) capacitor that contains enough charge to allow the cache to flush properly even after the current has been cut off. Is Samsung using this technique? I dunno. They might. However, the cap-solution is often used in mechanical solutions where position keeping is utilized. If you have a motor that is being tracked by an encoder (for example) and the current is pulled off the device it is in, it is extremely important to be able to return the motor to a known position before next powerup. Caps are often used instead of battery backup.

So how does Microsoft tie into all of this? Bill mentioned bugs here and there that have to do with Windows and the shutdown process. Is this correct? Yes and no. And there is no Windows related HPT366 bug that I have ever heard of. I can't find any evidence of it. However, MS had bugs in their write-back cache functionality but they are not specifically related to HPT366. The bug is detailed here (along with cures and status for different versions of Windows):

http://support.microsoft.com/default.as ... -us;332023

If you browse through the MS knowledgebase you will find many references to problems with write cache. However, before you start pointing them out, please make sure you really check if they are specific to the right version of Windows and if they are SCSI issues only or not (many of them are).

OK, last question then. How come many drives seem to have issues with the HPT366? Well, I think Bill outlines that part pretty well actually although in a different context. It seems as if the HPT366 BIOS and/or driver is buggy and doesn't work well with the firmware in the various different harddrives. This is also somewhat tied in with the operating system you are running. I have been playing around with the HPT366 under Linux and so far not had any problems whatsoever (IBM drive). I may hook up a Seagate drive and/or a Maxtor drive just to see how that would work because many have mentioned problems with Seagate especially. All I need is time :)

Sorry for the long rant. I hope you find it useful, if I haven't put you to sleep already...
2x533MHz@544MHz, 2.0V
640MB PC100 memory
Realtek RTL-8139 NIC
Maxtor 6Y080L0 80GB hdd
Debian Linux stable with 2.4.8 kernel
Post Reply