VOGONS


First post, by appiah4

User metadata
Rank l33t++
Rank
l33t++

I remember this being an issue and being resolvable, but I can't remember why it happens or how to fix it.

I'm getting this problem with my current Windows 98SE install on a ZIDA 5STX 430TX motherboard. I click DMA mode for the hard drive, reboot - and the tick is gone..

What is the fix here?

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 1 of 10, by Anonymous Coward

User metadata
Rank l33t
Rank
l33t

I think I remember seeing a few cheap drives that couldn't handle DMA mode (I think one of them was a SamDung). Did you try a different one?

"Will the highways on the internets become more few?" -Gee Dubya
V'Ger XT|Upgraded AT|Ultimate 386|Super VL/EISA 486|SMP VL/EISA Pentium

Reply 4 of 10, by appiah4

User metadata
Rank l33t++
Rank
l33t++
Oetker wrote on 2020-06-11, 12:57:

What hard drive are you using...

A Seagate 7200.10 80GB IDE drive jumpered to 32GB. BIOS detects it as running at UDMA5 at POST.

Retronautics: A digital gallery of my retro computers, hardware and projects.

Reply 5 of 10, by auron

User metadata
Rank Member
Rank
Member

using the same windows installation across different setups seems to be at least one cause of this. deleting the IDE controller driver in device manager (even if it's listed as working correctly) and letting it reinstall can fix this problem, along with CD drive detection issues.

Reply 6 of 10, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie

Sorry for the necro post, but I just stumbled upon this thread, and thought I'd share my two cents (just in case anyone runs into the same issue):
1. This is (usually) not a HDD problem, but a BIOS issue (and it predominantly affects some motherboards with certain BIOS revisions from the socket 7 era).
2. Depending on the motherboard (BIOS), it can be quickly solved by disabling UDMA in the BIOS "Integrated Peripherals" section. After doing that, the DMA check will remain active and it will increase the HDD throughput/decrease CPU usage as it should. However, this will limit the transfer to ~ 16 MB/s.

Another option (when possible) is to limit the UltraDMA mode to 5 or lower. This way you get the best of both worlds. 😀

2 x PGA132 / 5 x Socket 3 / 4 x Socket 7 / 6 x Super Socket 7 / 5 x Slot 1 / 3 x Slot A
5 x Socket 370 / 5 x Socket A / 1 x Socket 478 / 2 x Socket 754 / 3 x Socket 939 / 4 x LGA775 / 1 x LGA1155
Current rig: Ryzen 5 3600X
Backup rig: Core i7 7700k

Reply 7 of 10, by _UV_

User metadata
Rank Newbie
Rank
Newbie

bloodem that is definitely not a BIOS issue, that is HDDs newer than UDMA33 (most of them) working properly only at their native UDMA 66/100 or PIO. That is true for Seagate and IBM drives.
That's also half of famous W98 shutdown bug. Because of that many people suggest using third party controllers.

examples
https://fcenter.ru/online/hardarticles/hdd/54 … arracuda_ATA_IV (article in russian, it just found first by google, translate it and search for "udma33")
https://forums.gentoo.org/viewtopic-p-4029318 … 410cf7d531ac28b
it's hard to find exact info from the past

Year ago i assembled simple test rig for old videocards using ABIT BX board with Barracuda IV, once i enabled DMA and rebooted windows 2-3 times "something went wrong" and PC startup or any disk related operations being dog slow. I checked HDD and DMA CRC errors field in SMART went from 5-10 to something like 38000.

Reply 8 of 10, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie

No, that's not the case. Yes, the issue is clearly related to newer storage devices, but this is not the complete story.
I've just had 2 days ago an Acorp 5TX29 motherboard that refused to work in DMA mode with the initial 1997 BIOS, but worked just fine (with the same HDD) after updating it to the latest version (the new BIOS reverted to UltraDMA mode 2 as fallback).
And this is not a singular issue, I've seen it countless times.
Which is why, for boards (BIOS versions) that don't support this automatic fallback, the methods described in my previous post can be used.

2 x PGA132 / 5 x Socket 3 / 4 x Socket 7 / 6 x Super Socket 7 / 5 x Slot 1 / 3 x Slot A
5 x Socket 370 / 5 x Socket A / 1 x Socket 478 / 2 x Socket 754 / 3 x Socket 939 / 4 x LGA775 / 1 x LGA1155
Current rig: Ryzen 5 3600X
Backup rig: Core i7 7700k

Reply 9 of 10, by auron

User metadata
Rank Member
Rank
Member
_UV_ wrote on 2021-04-04, 22:45:

bloodem that is definitely not a BIOS issue, that is HDDs newer than UDMA33 (most of them) working properly only at their native UDMA 66/100 or PIO. That is true for Seagate and IBM drives.
That's also half of famous W98 shutdown bug. Because of that many people suggest using third party controllers.

that's an interesting statement, but if it such a general issue backwards compatibility issue on IDE existed, wouldn't it be much more widely known as UDMA66 became a thing in 1998/99 and these drives would have been widely used on UDMA33 connectors? or did nobody bother to tick that DMA checkbox?

moreover i looked up the manual for that ST380021A drive you mentioned and it literally lists UDMA 0-5 modes as supported. and as another example, both drive types from seagate and WD used in the original xbox were UDMA100 drives that were connected with a 40-wire cable... unfortunately i can't find any good info on whether the xbox OS actually used UDMA33 or PIO.

also, it's worth saying that 3rd party IDE controllers aren't necessarily a magic bullet either. i've once made a post about issues with silicon image and promise controllers and i think there's other threads about that as well. all in all i find SCSI actually less troublesome as you'd never even have to think about these issues there, and quality controllers are available for basically nothing... it's a shame that the drives do tend to be louder for whatever reason.

Reply 10 of 10, by bloodem

User metadata
Rank Oldbie
Rank
Oldbie
auron wrote on 2021-04-05, 05:57:

that's an interesting statement, but if it such a general issue backwards compatibility issue on IDE existed, wouldn't it be much more widely known as UDMA66 became a thing in 1998/99 and these drives would have been widely used on UDMA33 connectors? or did nobody bother to tick that DMA checkbox?

Yeah, of course this was never the case 😀 There are countless motherboards with Ultra ATA/33 HDD controllers which work just fine with any disk you throw at them, including UDMA7 storage devices.
So, yeah, this recurrent theme that this is a HDD problem is just wrong.

2 x PGA132 / 5 x Socket 3 / 4 x Socket 7 / 6 x Super Socket 7 / 5 x Slot 1 / 3 x Slot A
5 x Socket 370 / 5 x Socket A / 1 x Socket 478 / 2 x Socket 754 / 3 x Socket 939 / 4 x LGA775 / 1 x LGA1155
Current rig: Ryzen 5 3600X
Backup rig: Core i7 7700k