I've been fighting with some of the problems with the 0.40 version
of the 3c59x.c driver and the boomerang cards. The problem is, most
definitly, collision and timeout related. Turning off the bus-mastering
seems to help some and some posted patches in the time-out logic have also
helped.
I recently tried to compile in the 0.40 driver into a 2.1.42
kernel on a recent RedHat distribution. This is with gcc version 2.7.2.1.
Before, it had been with earlier kernels, distributions, and compilers.
This time I got the following errors:
gcc -D__KERNEL__ -I/usr/src/linux-2.1.42/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pipe -fno-strength-reduce -m486 -DCPU=486 -c -o 3c59x.o 3c59x.c
3c59x.c: In function `vortex_start_xmit':
3c59x.c:1054: void value not ignored as it ought to be
3c59x.c: In function `boomerang_start_xmit':
3c59x.c:1135: void value not ignored as it ought to be
make[3]: *** [3c59x.o] Error 1
make[3]: Leaving directory `/usr/src/linux-2.1.42/drivers/net'
make[2]: *** [first_rule] Error 2
make[2]: Leaving directory `/usr/src/linux-2.1.42/drivers/net'
make[1]: *** [sub_dirs] Error 2
make[1]: Leaving directory `/usr/src/linux-2.1.42/drivers'
make: *** [linuxsubdirs] Error 2
These two lines are "if( set_bit( .... ) )".
It seems that the "set_bit" function is (or is now) a void function.
Since this is right at the heart of some of the busy/time-out logic, the
immediate question becomes "Is this something new or is this something
that has been an influence in the driver screw-ups?"
Is this an old error that the new compiler is catching or is it a
change in the 2.1 series kernels that the driver has not caught up with.
Next question, and one that I have not delved into the code deep
enought to answer yet (maybe someone else can answer) is "what is the
correct function at this point". The two obvious alternatives are to
use "test_bit( ... )" if all we are doing is testing the state of the
bit, or "set_and_test_bit( ... )" if we are attempting to do an atomic
test and set operation. I think the later is the correct answer, but I'm
not sure and would appreciate comments from others.
So far, with this and a couple of the other patches to 0.40 that
have floated around, this SEEMS to be functional and stable. Unfortunately,
the network where I have typically testing this on (and consequently gotten
the failures) had become so congested that we changed over to a switched
100Mbit Hub which reduced the number of collision by several orders of
magnitude. Is the driver now more stable or is it just the improvement
in my network environment? I don't know... At this point, the patched up
0.40 driver does not appear TO ME to be any less stable than the 0.30 driver
which many are dropping back to. But then, quite a number of people were
not having problems with the 0.40 driver. Must have been lightly loaded
networks...
If this is reaching Don Becker, we could probably use the time-out
patches and the correct fix for the set_bit problem above in the sources.
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!