VOGONS


First post, by auron

User metadata
Rank Oldbie
Rank
Oldbie

it appears that my jetway 430FX board has some kind of problem with its cache. this manifested itself specifically in network transfers that came out with bad crc checksums, and even more specifically, files about 20mb or bigger. about 1 in 10 times they would show a correct checksum, mostly it was randomly bad. any smaller file showed no issue. i went and eliminated about any other variable and was ready to call this an issue with win95's network stack, until i thought to try and disable the external cache - since then, any file transfer came out fine.

the setup is 256k onboard, 2x UM61-3232AF-7 and IS61C64AH-15N tag, and it's upgraded with another 256k on coast, 2x W25P010AF-8 and IS61C64AH-15J tag. i recall that some asus coast that i had didn't work on this board and thought that the board might need the 2nd tag. i've literally beaten quake on this setup years ago and it's still running heavy games like that seemingly fine, but it looks like it's silently corrupting files now. if only large files are affected one could probably be using this for a while without even noticing.

i've tried reseating the coast module about five times, didn't change anything. when i run the ctcm17a tool, it hangs midway with a blinking prompt, i think before it should show "write strategy", and at the bottom it says MMOVI and nothing else - this should be for MMX which the CPU doesn't have so not sure what's going on. it does the exact same thing with the cache disabled too. what other tool could test L2 cache?

if i had to guess it's probably the coast, and i need to jumper it to 256k and just test with the onboard cache. it seems unlikely to me that the higher latency on the coast chips would present an issue on a 430FX board, and there is no l2 latency setting unlike later boards. i could try to apply the bios update as a last resort though.

Reply 1 of 4, by auron

User metadata
Rank Oldbie
Rank
Oldbie

removed the coast stick, and file transfers come out good so far. the difference is marginal in DOS but in demanding win95 games it seems that the smaller cache can be felt, even on a pentium 133. however, the ctcm7 program still fails in the exact same way. the tool is apparently from 2000 so one wouldn't think this setup would be too old for it, but who knows...

by the way, one detail about this cache stick - apart from two jumpers for "256k/512/upgrade", of which it's jumpered to upgrade, there is a third jumper to set "M1 Liner Mode". supposed to mean linear i guess. what could that be for?

Reply 2 of 4, by jakethompson1

User metadata
Rank l33t
Rank
l33t
auron wrote on 2024-06-24, 20:04:

by the way, one detail about this cache stick - apart from two jumpers for "256k/512/upgrade", of which it's jumpered to upgrade, there is a third jumper to set "M1 Liner Mode". supposed to mean linear i guess. what could that be for?

It's for certain Cyrix 6x86 processors aka M1

Reply 3 of 4, by auron

User metadata
Rank Oldbie
Rank
Oldbie

found another stick with the same type of chips as the other one, but lacking the upgrade jumper. it's from a board that doesn't have any cache of its own. didn't expect this to work and indeed it doesn't, only 256k detected and a hang during windows loading. i think it's clear that only sticks with the jumper work, which makes replacement harder.

Reply 4 of 4, by auron

User metadata
Rank Oldbie
Rank
Oldbie

i've since tried to run the cachechk tool, which really wasn't of any use. one time it did complain about some timing error, but this was with some drivers loaded, not a clean DOS boot. it passed 5 runs or so otherwise, including with the -w switch. memtest isn't able to reliably detect the fault either, while one time it did hang with over a 1000 errors, it also passed over 5 times as well. so it looks like simply FTPing over a 100 megabyte file and checking crc32 is an ideal method to verify motherboard l2 cache, it would show the fault 100% in my testing. it seems that network transfers for some reason are stressing l2 cache in a way that just copying a file between two hard drives does not, because i tried that as well and it would not change the file's checksum.

i also tried to use tweakbios to set a slower l2 cache timing, but sadly this just results in a system hang. i could try to use modbin or something to permanently edit the bios, but since the timing that the board uses is 3-1-1-1-2-1-1-1 and i'm seeing 3-1-1-1-1-1-1-1 mentioned as supported in the winbond datasheet, this would probably just be a waste of time.