Jump to content

Enable48BitLBA | Break the 137Gb barrier!


Recommended Posts


I tried the patch and there might be a problem. I unplugged my VIA PATA/SATA/RAID card, uninstalled all the related drivers and gave the patched driver a try.

Problem is this: When testing the drive (trying to fill up a 160GB PATA HD) once it reaches around 130GB-140GB or so, the file transfer stops, and it immediately my mouse/system freeze for 3-4 seconds. Then the system unfreezes for 3-4 seconds, after that it again freezes for 3-4 seconds, and it keeps doing that (freezing/unfreezing) until I stop the transfer.

There was no damage of any kind to my data or system, so far. I tried breaking the limit several times, it would always end up doing the same old freezing/unfreezing loop once it reaches a certain point. (around 130GB-140GB)

No data corruption though.

Any idea, anyone?

(By the way I'm using driver ver. 4.10.2225)

Link to comment
Share on other sites

The chipset has a native driver, but it's only for Win2k/XP. You already know the manufacturer (I already told you about it in a PM I sent you week ago, before posting in this thread) I think I know what you're aiming at though: the system is using your modified driver, I checked.

As far as I can tell, the modified driver is a failure, on my system at least. Quite probably the only reason my data is intact is because I have heckuva motherboard with built in virus protection and plenty of security features (on-chip). It just happens that one of the BIOS options is MBR protection (from viruses) as well as other data loss prevention features. So, the modified driver would probably ^&*$-up my system if it wasn't for the BIOS security features.

I suspect the stalling during the transfer is probably because BIOS firmware is halting it. Only reason my BIOS firmware would halt the transfer is because something on my system was up to no good. Since the stalling occurs at a pretty specific time/period during the transfer (once it reaches around 130GB-140GB ), its pretty obvious what is happening, no?

Any ideas, anyone?

Edited by Lunac
Link to comment
Share on other sites

Try disabling all those protection options and see what happens.

Ensure LBA access mode in BIOS is enabled.

Backup data before proceeding.

You could try some of the other fileversions I've fixed as well.

Link to comment
Share on other sites

  • 4 weeks later...

Thank you for making it possible, LLXX! Great work! :yes: I've got one question though - I've read everything here but I'm only more confused about it: I'm using Win98SE 4.10.2222 A, my original .pdr was v.2222; should I use your 1.0 (2222) or 1.1 (2225) version? Is 2225 your newer version of the 2222 or is it your patch of Microsoft's newer 2225 version? Am I making some terrible mistake using the patched v.2225 instead of my old v.2222 .pdr ?

Thanks,

Max

If everything was fine with .2222, use the patched .2222. The newer versions are for systems that don't work with the original 2222 version.

The version numbers just refer to M$'s original file versions. The 2225 is a patched 2225, etc.

I have Win98SE (4.10.2222A) so I assumed I needed the 2.10.2222F) update as you confirm in your reply above... BUT....

then I go to MGDxx's great site and it says this:

Install ESDI_506.PDR 4.10.2225 Fix on ALL PCs/portables EXCEPT IBM portables with removable disks!

Install ESDI_506.PDR 4.10.2226 Fix ONLY on IBM portables with removable disks!

So from that I take it I should use 4.10.2225 fix.

Now I'm confused? What's the pros and cons of each version for my situation?

Oh And love your work!

Pretty good for a Sheila :P

:thumbup

EDIT:

After re-reading this entire Thread I think I understand it now. 2225 was an update of 2222 to fix support for Scandisk or something. So using it would indeed be an OK option.

So using the 2225 update should be fine?

Edited by galahs
Link to comment
Share on other sites

Moin,

the 4.10.2222 can be quite dangerous.

See http://www.pcreview.co.uk/forums/thread-1944044-2.php and http://www.partitionsupport.com/gb32-13.zip for explanation.

In short: Microsoft chose to not admit version 2225 fixes not just the Phoenix BitShift bug but also a bug where certain mappings can cause the driver to have a wraparound at 32GB.

Last week, a friend lost his system partition due to this bug when he filled the second partition over the (absolute) 32GB mark, overwriting the start of the system partition of the harddisk, completely trashing partition root sector and FAT (it is quite surprising how long 98SE kept running until it finally crashed ...). Also above mentioned gb32.exe showed 1000 identical sectors before and 0 after installing KB243450. This was on a Compaq Armada E700 (with latest BIOS 6h_0315.02) which unfortunately decided to use a 240 heads mapping on a 40GB disk.

LLXX, as you stated earlier in this thread that your patch only jumps to the new code when a LBA48 harddisk is encountered, this would leave patched systems vulnerable to the wraparound bug if a drive between (slightly less than) 32GB and 128GB was used. If a user just plugged in another harddisk and start losing data, the problem could be very hard to detect as it is really counter-intuitive that a >128GB patched driver could have problems with drives between 32 and 128GB, so I'd recommend pulling the patch to .2222 completely or at least add a big fat-a** warning. Every system that can use .2222 should be able to run .2225 anyway.

MfG MOW

Link to comment
Share on other sites

LLXX, as you stated earlier in this thread that your patch only jumps to the new code when a LBA48 harddisk is encountered
Wrong. It switches over to 48-bit LBA commands when accesses are made to and beyond the 256th billion physical sector.
this would leave patched systems vulnerable to the wraparound bug if a drive between (slightly less than) 32GB and 128GB was used. If a user just plugged in another harddisk and start losing data, the problem could be very hard to detect as it is really counter-intuitive that a >128GB patched driver could have problems with drives between 32 and 128GB, so I'd recommend pulling the patch to .2222 completely or at least add a big fat-a** warning. Every system that can use .2222 should be able to run .2225 anyway.
The data loss would be noticed much beyond the 128Gb barrier. Also, if you read the previous posts I have made in this thread, that data loss is statistically a rare occurrence and only applies to specific BIOSae and hardware configurations which are not very prominent.

Regarding the warning, re-read the OP again.

I provide fixed versions of drivers for the replacement of an existing driver with one of exactly the same version. The newer ones are actually slightly *slower* than the original 2222 and if your disk/BIOS combination worked fine with 2222 then there is no reason to switch to a newer version to "fix" bugs which don't exist in your system.

Link to comment
Share on other sites

Moin,

LLXX, as you stated earlier in this thread that your patch only jumps to the new code when a LBA48 harddisk is encountered
Wrong. It switches over to 48-bit LBA commands when accesses are made to and beyond the 256th billion physical sector.

Hmm, what happens if a multi-sectors transfer starts just below and ends beyond 128GB? If this leads to the harddisk producing an error, would the original code be able to handle it?

this would leave patched systems vulnerable to the wraparound bug if a drive between (slightly less than) 32GB and 128GB was used. If a user just plugged in another harddisk and start losing data, the problem could be very hard to detect as it is really counter-intuitive that a >128GB patched driver could have problems with drives between 32 and 128GB, so I'd recommend pulling the patch to .2222 completely or at least add a big fat-a** warning. Every system that can use .2222 should be able to run .2225 anyway.
The data loss would be noticed much beyond the 128Gb barrier. Also, if you read the previous posts I have made in this thread, that data loss is statistically a rare occurrence and only applies to specific BIOSae and hardware configurations which are not very prominent.

Well, not that rare. And it might even happen to bigger than 128GB disk if the BIOS decides to map them into something with 240 heads. Thus it is important to test not only for correct function around 128GB but also around 32GB.

Regarding the warning, re-read the OP again.
I just see a general warning, not a specific one about .2222 vs. .2225.
I provide fixed versions of drivers for the replacement of an existing driver with one of exactly the same version. The newer ones are actually slightly *slower* than the original 2222 and if your disk/BIOS combination worked fine with 2222 then there is no reason to switch to a newer version to "fix" bugs which don't exist in your system.

Except in the cases where the user is in for an unpleasant surprise because (s)he

1) wasn't even aware that a 32GB problem existed on the drives already in the system

2) has not used a HD >32GB yet and happens to trigger the problem with the new >128GB HD

3) later on adds a HD whose mapping triggers the problem, not even aware that another HD, even smaller than 128GB, could lead to trouble when a working big HD already is present in the system - how long would it take said user to identify the .2222 code as the source of the problem?

I'd rather be on the safe side. Especially if it's only a *slight* slowdown it's not worth taking the risk, and does anyone know what other fixes Microsoft built into the .2225?

MOW

Link to comment
Share on other sites

Hmm, what happens if a multi-sectors transfer starts just below and ends beyond 128GB? If this leads to the harddisk producing an error, would the original code be able to handle it?
Actually the first sector on which 48-bit LBA is used is 256 sectors below 128Gb. This is because the maximum number of sectors which the original driver can transfer at once is 256, and while this may lead to problems with hard drives of a size between 128GB-128KB and 128GB-512y that do not support 48-bit LBA, I have yet to find a hard drive within this (tiny) size range - not to mention that the size produced below this is 120Gb, and the size above 150Gb.
Well, not that rare. And it might even happen to bigger than 128GB disk if the BIOS decides to map them into something with 240 heads. Thus it is important to test not only for correct function around 128GB but also around 32GB.
LBA mode is used so CHS values are unimportant. CHS code still resides within the driver to handle legacy drives that do not support LBA commands (and thus are likely to be far below any limits).
Link to comment
Share on other sites

Well, not that rare. And it might even happen to bigger than 128GB disk if the BIOS decides to map them into something with 240 heads. Thus it is important to test not only for correct function around 128GB but also around 32GB.
LBA mode is used so CHS values are unimportant. CHS code still resides within the driver to handle legacy drives that do not support LBA commands (and thus are likely to be far below any limits).

That's how it should be, but when .2222 encounters certain mappings with e.g. 240 heads the wraparound occurs, hence .2225. I don't know what moronic code causes the CHS mapping to have such a strange side effect on the LBA access, but I know it does not happen in .2225. For further details please see the forum link above.

Link to comment
Share on other sites

Update: There is no off option for DataGuard (only on or auto). I tried both, no difference. I turned off the built in anti-virus stuff, also no difference. Could the driver be misbehaving because of my perhaps unusual partitioning (multiple Win98 installations on a single disk)? Two of them to be exact, and both have the updated driver.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...