The tested switch is some kind of 10/100M switch. I put two Windows 98
SE client on 10M full duplex ports, and linux box on 100M full duplex
port. All machines are Dell with 3C905C NIC. All NIC are configured
autonegotiation(N-WAY)
I use a mpeg software to generate mpeg UDP stream from one of two clients,
and use a enhanced media player to view the stream on another client.
Client to client transfer is ok. That is,
Client A(10M) -> Switch -> Client B(10M)
So I go to the next test: one client dialup using pppoe, linux box acts
as pppoe AC. Now the client to client traffic is like:
Client A(10M) -> Switch -> Linux Box(100M) ->Switch -> Client B(10M)
I can see that linux network interface down and up. I can confirm
that by interrupts got from "vmstat 1", and ping result, and status
LEDs of switch.
To isolate the real problem, I tried unicast UDP mpeg stream
Client A(10M) -> Switch -> Linux Box(100M)
And interface of linux box dies as crazy as it can. The ftp put test
and ping -f test can reproduce the same problem.
TO ANSWER Andrew's QUESTION:
1. The error message does come from 2.2.14-15
2. I think physical network problem is possible, but why TX is ok
while RX is bad? The switch did suffer a power failure and function
abnormally until I reset it. I will use another switch later
3. 2.2.14 can survive but 2.3.99-pre8 and 2.4.0-test1-ac11 are killed.
I attached error message generated by 2.2.14 and 2.4.0-test1-ac11.
.debug3 means debug=3 and .debug6 means debug=6
Friday, June 09, 2000, 8:25:06 PM, you wrote:
>> During a multimedia test, I find that 3c59x NIC is apt to die when
>> rx small amount data, but tx is robust enough to output 900KB/s data.
>>
>> I have a linux box running 2.3.99-pre8 and 2.4.0-test1-ac11.
>> A ping -f from another machine is enough to bring the NIC down
>> without response for a long time. Then the NIC back to work and down.
>> And ftp client can only put data to it for 2 sec.
>>
>> Under 2.4.0-test1-ac11, the dmesg reports:
>> --X--
>> 3c59x.c:v0.99L+LK1.1.6 28 May 2000 Donald Becker and others. http://www.scyld.
>> com/network/vortex.html $Revision: 1.97 $
>> eth0: 3Com PCI 3c905C Tornado at 0x1000, 00:50:da:b2:04:f1, IRQ 11
>> Full duplex capable
>> Internal config register is 3800000, transceivers 0xa.
>> 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
>> MII transceiver found at address 24, status 782d.
>> 3c59x: Wake-on-LAN functions disabled
>> Enabling bus-master transmits and whole-frame receives.
>> --X--
>>
>> I have reverted back to 2.2.14-15(Redhat 6.2 stock kernel), and 2.2.14
>> can sustain the traffic. But with "options 3c59x debug=3", 2.2.14
>> reports the following error:
>> ....
>> Rx error: status 08.
AM> CRC error.
>> Rx error: status 08.
>> Rx error: status 8c.
AM> CRC + alignment + dribblebits. (No, I don't know what a dribblebit is!)
>> ...
>> Rx error: status 18.
AM> CRC + oversized frame.
AM> Now, in your final paragraph you said the above errors came out with
AM> 2.2.14? Can you please confirm this?
AM> If the driver is doing this on 2.2.14, 2.3.99-pre8 and 2.4.0-test1-ac11
AM> then I think you have a physical network problem. A bad one.
AM> If it happens on only 2.3 and 2.4 then perhaps I a driver problem. A bad
AM> one.
AM> Please check everything, let me know?
AM> If indeed the above Rx errors came out on 2.2.14 then could you please
AM> tell me how frequently they come out?
AM> Finally, could you please tell me what your LAN setup is? 10baseT with
AM> shared media, I assume? If so, the driver is perhaps going into
AM> full-duplex mode. Please use 'debug=7' and send me more of the output
AM> after module insertion.
AM> Thanks.
-- lark
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:23 EST