This problem is solved.
Regards,
Clayton Weaver
<mailto:[email protected]>
(Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers
(just kidding)
It was the cache alignment setting in tulip.c (saved me sifting through
the bowels of the pci code to find it).
I choose "486" for the cpu in "make config" for the kernel for a Cyrix
5x86 running on an Asus sp3 with sis496 pci 2.0 bus (it has been
wonderfully stable for 5 years this way, why rock the boat).
The .90 driver in 2.0.38 detects the "486" and sets the cache alignment to
0x01a0480. The .91g-ppc driver in 2.2.15+ doesn't check to see if we're
running a 486 or lower, it simply sets CSR0 to 0x01A08000 if __i386__
is defined. Using "static int csr0 = 0x01A00000 | 0x4800;" and
recompiling fixed the http-induced kernel deadlocks that I was seeing.
I could send a patch, but I don't know if the variable that the code
in .90 was using is defined in 2.2.1x, etc, whether it is deprecated,
various stuff that anyone maintaining 2.2.x pci ethernet drivers probably
already knows.
But that fixed it.
--
make config for 5x86 note:
Both the AMD and Cyrix, different as they are, should be 486 IIRC. The
AMD certainly does not implement the p5 instruction set. The Cyrix might
benefit from 586 instruction scheduling, but I'd have to see it to believe
it, and it certainly won't help the AMD5x86, which is merely a fast 486dx
with a bigger cache. If your gcc specs file considers "-m586" to mean both
-mcpu=i586 and -march=i586, you are doomed if you compile with that flag
for sure for the AMD, and maybe for the Cyrix 5x86 too. Who knows whether
the p5 instructions all worked in the m1sc, even if that logic was on the
chip before they hacked the m1sc to use the narrow 486 memory bus? IIRC
Cyrix never claimed that you could run p5 binaries on it.