Re: Problems with Ethernet on PowerBook Wallstreet G3
From: Wolfgang Denk <hidden>
Date: 2000-04-13 09:39:05
In message [off-list ref] you wrote:
That might be a result of the interface init - if there are no real collisions otherwise. What number of collisions does the other machine log?
Seems normal to me for a usually lightly loaded network; for instance:
RX packets:15315134 errors:1699 dropped:210 overruns:1691 frame:16
TX packets:1427615 errors:7 dropped:0 overruns:3 carrier:4
collisions:27791 txqueuelen:100
RX packets:11453931 errors:10 dropped:0 overruns:0 frame:20
TX packets:5286558 errors:3 dropped:0 overruns:2 carrier:1
collisions:1157 txqueuelen:100
RX packets:2011658 errors:0 dropped:0 overruns:0 frame:0
TX packets:1477258 errors:0 dropped:0 overruns:0 carrier:0
collisions:8579 txqueuelen:100
This, together with your info that the missing bytes happen on packet boundaries, strongly supports BenH's idea that we may be running into the txdma bug quoted above. The chipset apparently needs to be tweaked some way to reset the transmitter before starting the next DMA frame.
Yepp.
What machine is on the receiving end? The file size being conserved may be
The other machines are either PC's running Linux (2.2.12 on a AMD-K6, 2.2.13 on a dual P-II, 2.3.51 on a dual P-III) or embedded systems (2.2.13 on MPX8xx, with xx=23, 50 and 60).
due to Linux only looking at the packet size from the header (not cross checking with the size actually received), the sending machine padding the packet, or the BMAC on the receiving end placing packet size and status at the end of the frame. No idea why the bug correlates with disk activity - is the disk interrupt priority higher than ethernet DMA?
Well, I have no absolute evidence that there is a strict correlation.
It's more a certain feeling, and the observation that usually a 'tar
-zcf - . | rsh ..." is almost certain to fail, while a plain FTP has
at least a 50...70% chance to be ok.
Regarding the interrupts:
# cat /proc/interrupts
CPU0
4: 0 PMAC-PIC SCC-txdma
5: 0 PMAC-PIC SCC-rxdma
6: 0 PMAC-PIC SCC-txdma
7: 0 PMAC-PIC SCC-rxdma
8: 1 PMAC-PIC AWACS out
12: 15 PMAC-PIC MESH
13: 20987 PMAC-PIC ide0
14: 5 PMAC-PIC ide1
15: 0 PMAC-PIC SCC
16: 0 PMAC-PIC SCC
17: 0 PMAC-PIC AWACS
18: 6587 PMAC-PIC VIA-PMU
19: 0 PMAC-PIC SWIM3
27: 1 PMAC-PIC interrupt cascade
32: 92922 PMAC-PIC BMAC-txdma
33: 70818 PMAC-PIC BMAC-rxdma
42: 163755 PMAC-PIC BMAC-misc
68: 0 PMAC-PI2 SCC-txdma
69: 0 PMAC-PI2 SCC-rxdma
79: 0 PMAC-PI2 SCC
83: 0 PMAC-PI2 SWIM3
Hm... I have no idea if this relates to interrupt priorities on this
box.
Also, after a failing FTP transfer:
# cat /proc/net/bmac
BMAC counters & registers
MEMADD: 0x000000
MEMDATAHI: 0x000000
MEMDATALO: 0x000000
TXPNTR: 0x000214
RXPNTR: 0x0002ce
IPG1: 0x000008
IPG2: 0x000004
ALIMIT: 0x000010
SLOT: 0x000040
PALEN: 0x000007
PAPAT: 0x0000aa
TXSFD: 0x0000ab
JAM: 0x000004
TXCFG: 0x000001
TXMAX: 0x0005ee
TXMIN: 0x000040
PAREG: 0x00000b
DCNT: 0x00b861
NCCNT: 0x0092cf
NTCNT: 0x003635
EXCNT: 0x000000
LTCNT: 0x000000
TXSM: 0x000010
RXCFG: 0x000b01
RXMAX: 0x0005ee
RXMIN: 0x000040
FRCNT: 0x0014d2
AECNT: 0x000000
FECNT: 0x000000
RXSM: 0x000002
RXCV: 0x000000
# ifconfig eth0
eth0 Link encap:Ethernet HWaddr 00:05:02:07:39:97
inet addr:10.0.0.3 Bcast:10.255.255.255 Mask:255.0.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:70896 errors:1 dropped:0 overruns:0 frame:0
TX packets:92979 errors:2 dropped:0 overruns:0 carrier:0
collisions:0
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de
"It is better to have tried and failed than to have failed to try,
but the result's the same." - Mike Dennison
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/