Here is a copy of some mail I sent in Oct. when I started having
problems with the 3C900 and 3C905 cards.
This email is pretty long and detailed, so please bear with me.
I have not had any problems recently since I have been using
a 3C590 card. (The other 2 cards are waiting to be used).
It seems that there are problems when either Bus Mastering or
Full Duplex Mode is turned on.
-primus
PS I have since upgraded to 2.0.24 and 64M ram.
I have used both:
static char *version = "3c59x.c:v0.28c 8/25/96 becker@cesdis.gsfc.nasa.gov\n";
static char *version = "3c900.c:v0.35 9/13/96 becker@cesdis.gsfc.nasa.gov\n";
---------- Forwarded message ----------
To: becker@cesdis.gsfc.nasa.gov
Subject: strange 3c905 behaviour...
Sun Oct 20 21:09:36 EDT 1996
Mr. Becker:
I have tried the 3c900 card and am now using the 3c905 card (both 10Mbs
operation).
Ever since switching from the 3c590 card, my machine would crash every
3 days - the error: "Couldn't allocate a sk_buff ...."
When I temporarily installed an extra 32M of ram, the system seemed
stable, but eventually crashed again.
The other two strange occurences are:
1) On some ocassions, after an 'ifconfig eth0 down', and a
subsequent 'ifconfig eth0 ....', the card would not
be able to transmit:
ct 20 20:00:58 ip kernel: 3c900.c:v0.35 9/13/96 becker@cesdis.gsfc.nasa.gov
Oct 20 20:00:58 ip kernel: loading device 'eth0'...
Oct 20 20:00:58 ip kernel: eth0: 3Com 3c905 Boomerang 100baseTx at 0x6100, 00:a0:24:c8:92:f6, IRQ 11
Oct 20 20:00:58 ip kernel: Internal config register is 16302d8, transceivers 0xe040.
Oct 20 20:00:58 ip kernel: 8K word-wide RAM 3:5 Rx:Tx split, autoselect/MII interface.
Oct 20 20:00:58 ip kernel: Media override to transceiver type 0 (10baseT).
Oct 20 20:00:58 ip kernel: eth0: Media override to transceiver 0 (10baseT).
Oct 20 20:00:58 ip kernel: eth0: vortex_open() InternalConfig 010302d8.
Oct 20 20:00:58 ip kernel: eth0: vortex_open() irq 11 media status 8830.
Oct 20 20:09:39 ip kernel: eth0: Trying to send a packet, Tx index 0.
Oct 20 20:09:39 ip kernel: eth0: Infinite loop in interrupt, status e101. Disabling functions (7efe).
Oct 20 20:09:44 ip kernel: eth0: Trying to send a packet, Tx index 1.
Oct 20 20:09:49 ip kernel: eth0: Trying to send a packet, Tx index 2.
Oct 20 20:10:49 ip kernel: eth0: Trying to send a packet, Tx index 3.
Oct 20 20:11:49 ip kernel: eth0: transmit timed out, tx_status 00 status e000.
Oct 20 20:12:49 ip kernel: eth0: Trying to send a packet, Tx index 4.
Oct 20 20:13:08 ip kernel: eth0: transmit timed out, tx_status 00 status e000.
In some cases of Tx time out, there was no indication of an infinite loop
in interrupt:
Oct 20 19:42:39 ip kernel: eth0: Media MII is has no indication, 8802.
Oct 20 19:42:39 ip kernel: eth0: Media selection timer finished, MII.
Oct 20 19:44:01 ip kernel: eth0: Trying to send a packet, Tx index 0.
Oct 20 19:44:06 ip kernel: eth0: Trying to send a packet, Tx index 1.
Oct 20 19:44:11 ip kernel: eth0: Trying to send a packet, Tx index 2.
Oct 20 19:45:11 ip kernel: eth0: Trying to send a packet, Tx index 3.
Oct 20 19:45:30 ip kernel: eth0: transmit timed out, tx_status 00 status e000.
Oct 20 19:46:11 ip kernel: eth0: Trying to send a packet, Tx index 4.
O
2) The other strange phenomenom is an alarming increase 'speed/time'
-for want of a better word to describe it.
for ping (5sec on my machine):
# ping aleph
PING aleph.sensenet.com (199.33.238.2): 56 data bytes
64 bytes from 199.33.238.2: icmp_seq=0 ttl=255 time=8.5 ms
64 bytes from 199.33.238.2: icmp_seq=1 ttl=255 time=5.6 ms
64 bytes from 199.33.238.2: icmp_seq=2 ttl=255 time=5.2 ms
64 bytes from 199.33.238.2: icmp_seq=3 ttl=255 time=11.0 ms
64 bytes from 199.33.238.2: icmp_seq=4 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=5 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=6 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=7 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=8 ttl=255 time=5.3 ms
64 bytes from 199.33.238.2: icmp_seq=9 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=10 ttl=255 time=4.7 ms
64 bytes from 199.33.238.2: icmp_seq=11 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=12 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=13 ttl=255 time=5.9 ms
64 bytes from 199.33.238.2: icmp_seq=14 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=15 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=16 ttl=255 time=4.6 ms
64 bytes from 199.33.238.2: icmp_seq=17 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=18 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=19 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=20 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=21 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=22 ttl=255 time=5.5 ms
64 bytes from 199.33.238.2: icmp_seq=23 ttl=255 time=4.7 ms
64 bytes from 199.33.238.2: icmp_seq=24 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=25 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=26 ttl=255 time=4.7 ms
64 bytes from 199.33.238.2: icmp_seq=27 ttl=255 time=4.6 ms
64 bytes from 199.33.238.2: icmp_seq=28 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=29 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=30 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=31 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=32 ttl=255 time=4.4 ms
64 bytes from 199.33.238.2: icmp_seq=33 ttl=255 time=5.5 ms
64 bytes from 199.33.238.2: icmp_seq=34 ttl=255 time=4.7 ms
64 bytes from 199.33.238.2: icmp_seq=35 ttl=255 time=4.5 ms
64 bytes from 199.33.238.2: icmp_seq=36 ttl=255 time=4.8 ms
64 bytes from 199.33.238.2: icmp_seq=37 ttl=255 time=5.4 ms
64 bytes from 199.33.238.2: icmp_seq=38 ttl=255 time=5.5 ms
--- aleph.sensenet.com ping statistics ---
39 packets transmitted, 39 packets received, 0% packet loss
round-trip min/avg/max = 4.4/5.1/11.0 ms
#
on weird (ping to aleph - 5 sec) - 3c590
[micro@weird micro]$ ping aleph
PING aleph.sensenet.com (199.33.238.2): 56 data bytes
64 bytes from 199.33.238.2: icmp_seq=0 ttl=255 time=0.9 ms
64 bytes from 199.33.238.2: icmp_seq=1 ttl=255 time=0.7 ms
64 bytes from 199.33.238.2: icmp_seq=2 ttl=255 time=0.9 ms
64 bytes from 199.33.238.2: icmp_seq=3 ttl=255 time=0.8 ms
64 bytes from 199.33.238.2: icmp_seq=4 ttl=255 time=0.7 ms
64 bytes from 199.33.238.2: icmp_seq=5 ttl=255 time=0.8 ms
--- aleph.sensenet.com ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max = 0.7/0.8/0.9 ms
[micro@weird micro]$
These date commands were taken 5 sec apart:
# date
Sun Oct 20 20:16:08 EDT 1996
# date
Sun Oct 20 20:16:52 EDT 1996
Within that space of time, my clock advanced 44sec.
I attribute the accelerated clock due the the fact the I use xntp.
The ping examples above, however, were done before xntp was started.
Thanks for any help in solving this mystery.
-primus
PS System Specifics:
Processor: Pent 133 Triton IIX motherboard
RAM: 32M
Cache: 512k
Ethernet: 3c905
OS: Linux-2.0.20
Distribution: Debian (rex)
conf.modules: alias eth0 3c90x
options eth0 debug=4 #options=0
*NOTE* whenever 'options' is used card cannot transmit
libc5: 5.2.18-11
netbase: 2.06-1
netstd: 2.07-1