OS? Win98?

You are using 80 conductor cable?

To rule out controller, perhaps install XP. See if it works there.

Fair chance the Win98 sees BIOS reporting a higher transfer speed than controller is capable of and hence defaults to some lower value. I heard that this is a Win98 specific problem, and that later OS don't fall for that. I had it with many of my Award 586 boards. Had to patch the Bios.

Hi ux-3,

thanks for your suggestion. I used Win98SE for running the atto benchmark program and yes I am using 80 conductor cable (working as expected in other system/on 133tx2 controller).
I tried Windows XP and it reports UDMA-2 for IDE1 (Master: IDE-SATA Adapter with HDD connected; Slave: None) and UDMA-3 for IDE2 (Master: DVD-ROM, Slave: None). That's basically the same what the BIOS comes up with and also similar to the behaviour of Win98SE. (The drivers included in WinXP appear to be the most recent ones according to the gigabyte website)

Cheers,
Flo

And now reverse the adapters. If you get UDMA-3 on IDE1 with DVD rom as master and UDMA-2 on IDE2 with HDD, you know that both adapters can do UDMA-3.

Hi ux-3,

with reversed connection UDMA-3 on IDE1 is reported, as well as UDMA-2 on IDE2. The result remains the same when interchanging the cables. So the onboard controller is capable of at least UDMA-3 (for the DVD-ROM 😀 but actually UDMA-4 should be possible. I ordered four "brand-new" 80-conductor cables for ruling out that the onboard controller is just picky and not liking my 20+(?) year old cables from the basement 😉
Anyway I don't have much hope that new cables will bring any change, I will probably use a 40-conductor cable (to get rid of the error message) and the IDE-SDCard adapter was it maxes out at ~25MiB/s anyway.
Thanks again!

Cheers,
Flo

You could check if your award bios is patchable.

.. as expected the new 80-conductor cables did not bring any change.
Anyway I could confirm that the controller is fine, it appears to be a BIOS issue:
Using linux (which ignores broken BIOS obviously) I could see the UDMA-4 being activated ...

1rescue_attic:~# dmesg | grep UDMA
2[   19.053407] AMD7409: 0000:00:07.1 (rev 03) UDMA66 controller
3[   20.876443] hda: UDMA/66 mode selected
4[   20.921771] hdb: UDMA/66 mode selected

.. the transfer rates also hint at something better than UDMA-2 (33.3 MB/s).
Note: hda is the ide-sdcard adapter limited to ~25MB/s, hdb is ide-sata adapter with HDD ..

1rescue_attic:~# hdparm -tT /dev/hda
2
3/dev/hda:
4 Timing cached reads:   304 MB in  2.01 seconds = 151.40 MB/sec
5 Timing buffered disk reads:   74 MB in  3.02 seconds =  24.48 MB/sec
6
7rescue_attic:~# hdparm -tT /dev/hdb
8
9/dev/hdb:
10 Timing cached reads:   304 MB in  2.00 seconds = 151.98 MB/sec
11 Timing buffered disk reads:  154 MB in  3.02 seconds =  50.97 MB/sec

.. and UDMA-4 appears to be used for both devices

1rescue_attic:~# hdparm -iv /dev/hda # or /dev/hdb
2
3[...]
4 UDMA modes: udma0 udma1 udma2 udma3 *udma4 udma5 
5
6 * signifies the current active mode

As for patching the BIOS I am absolutely clueless where to start, I am not familiar with assembler and I don't have a BIOS chip flashing device 😀
Cheers,
Flo

floppydream wrote on 2024-09-23, 15:38:

As for patching the BIOS I am absolutely clueless where to start, I am not familiar with assembler and I don't have a BIOS chip flashing device 😀

I have neither either, I just followed the instructions. HOWEVER, the patch description fitted my case well. I started out with a less valuable board. After that worked, I tried my better board too, which worked as well. Then I tried another suggested bios, which failed. I had the chip reflashed and then patched to the working version again.

This is the thread, but I am not sure if it is relevant in your case:

DMA Mode check does not stick in Windows 98SE?

Hi,

a few words just for closure.
I followed the thread and managed to patch a BIOS blob using the biospatcher tool (latest, 6 alpha 9 IIRC) and flashed it. Only to find out that I used the BIOS blob of a completely different motherboard thus temporarily bricking the GA-7IX.
So now I am an owner of a T48 programmer and learned how to use it 😀

In the end I managed to patch the correct BIOS blob, also flashing went fine but there was no UDMA related fixes mentioned in the logging output of biospatcher tool. Of course this did not lead to the vanishing of the 80 conductor cable warning nor speeds beyond UDMA-2.
Only some "rom.by" string and details on the CPU are now visible on POST. I will probably flash back the original Gigabyte BIOS and settle on using the promise tx133 IDE controller.

Cheers,
Flo