problem with Sohoware SF110A card
"D. Hugh Redelmeier" <[email protected]> Tue, 12 Aug 2003 10:54:56 -0400 (EDT)
| Newsgroups | gmane.linux.drivers.tulip.general |
|---|---|
| Message-ID | <[email protected]> |
[I mentioned this problem to Donald Becker at Ottawa Linux Symposium, but
we didn't finish the conversation.]
Problem:
An NFS server, when using an SFA110A NIC, seems to be sending corrupt
packets. No layer of networking is catching these errors -- not the
ethernet CRC nor the UDP checksup.
I'm having difficulty analyzing the problem, so I'm including a
description of my many experiments. I would appreciate any
suggestions. What is the simplest explanation that fits the data?
What experiments would confirm or rule out plausible explanations?
Does anyone else have this card? Can you reproduce the failure I
observe?
The test: a script that access .rpm files over NFS and checks if they
are being received correctly (using rpm --checksig). Failures are rare:
typically one to three rpms fail out of about a gigabyte of them.
The failures involve a permutation of some bytes in the file. This
could explain why the UDP checksum does not detect the problem: if the
permutation is within one packet, it will not disturb the checksum.
This does not explain why the ethernet CRC is not catching the
problem.
Theory 1: it *is* detecting lots of errors and causing
retransmissions; only the undetected errors are getting through.
Since no error counts are showing up in the output of /sbin/ifconfig,
I suspect that this is not the case. Donald suggested checking a
/proc entry, but I don't remember which one.
Theory 2: the corruption occurs in the sending NIC's buffer before the
CRC is calculated.
The card in question:
<http://www.sohoware.com/span/new_sohoware/newfiles/subpages/product/sfa100a.htm>
I've tested with two of these cards, and the problem shows up with
both.
[So the problem is unlikely to be a particular broken card.]
The problem goes away when the card is replaced by an RTL8139 card.
[So the problem is related to the card or driver.]
I've moved the card to different PCI slots within the same computer,
with no observed difference.
[So the problem is not a deffective PCI slot.]
I have the same problem when one of these cards is in either of two
different machines. The other misbehaviour is with a different
SFA110A in a different computer.
[So the problem isn't likely a broken computer.]
The problem goes away when the card is replaced by a Network
Everywhere Tulip-based NIC.
[So if the problem is in the tulip driver, it is subtle.]
If I transfer files using ssh instead of NFS, no mistransmissions are
noted. As far as I can tell from the SSH RFCs, ssh is supposed to
abort, not retry, on an error.
[So the problem may be timing related -- SSH is presumabley slower
than NFS. SSH used TCP, not UDP, but I doubt that that is material.
Alternatively, ssh is detecting an error and silently recovering
through retransmission.]
These are recognized by my Linux systems as tulips. Here is the
output of lspci for an SFA110A:
00:09.0 Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 25)
Subsystem: National Datacomm Corp: Unknown device 8110
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 19
Region 0: I/O ports at a400 [size=256]
Region 1: Memory at db000000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=256K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
The MAC address for this card is 00:80:C6:EA:75:24
Here is lspci for a working Network Everywhere tulip card:
00:0d.0 Ethernet controller: Macronix, Inc. [MXIC] MX987x5 (rev 25)
Subsystem: Unknown device 2078:0540
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (2000ns min, 14000ns max), cache line size 08
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 9800 [size=256]
Region 1: Memory at f1000000 (32-bit, non-prefetchable) [size=256]
Expansion ROM at <unassigned> [disabled] [size=256K]
Capabilities: [44] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
[Seems fairly similar].
I'm using Red Hat kernels and the tulip driver module that they
provide. For example, I'm using the following on the NFS servers in
question:
2.4.20-18.7smp (in RHL7.2)
2.4.20-18.8 (in RHL8.0)
2.4.20-18.9 (in RHL9)
I tried KNOPPIX 3.2 on one of the servers and still observed errors.
KNOPPIX 3.2 is Debian-based and has a 2.4.20 kernel.
[So this is not just a Red Hat problem.]
Hugh Redelmeier
[email protected] voice: +1 416 482-8253
Some sample differences. This is output of cmp -l bad good. The
first column is the file offset. The second is the byte from the bad
file (in base 8) and the third is the byte from the good file. Each
example is the complete difference for a particular failing file
transmission.
example 1:
59572 0 2
59580 2 0
example 2:
15349 1 0
15350 3 0
15641 0 1
15642 0 3
example 3:
1785205 164 151
1785206 0 164
1785207 151 0
1785208 164 151
1785209 0 164
1785210 151 0
1785211 164 151
1785212 0 164
1785213 151 0
1785214 164 151
1785215 0 164
1785216 151 0
1785217 164 151
1785218 0 164
1785219 151 0
1785220 164 151
1785221 0 164
1785222 151 0
1785223 164 151
1785224 0 164
1785225 151 0
1785226 164 151
1785227 0 164
1785228 151 0
1785229 164 151
1785230 0 164
1785231 151 0
1785232 164 151
1785233 0 164
1785234 151 0
1785235 164 151
1785236 0 164
1785237 151 0
1785238 164 151
1785239 0 164
1785240 151 0
1785241 164 151
1785242 0 164
1785243 151 0
1785244 164 151
1785245 0 164
1785246 151 0
1785247 164 151
1785248 0 164
1785249 151 0
1785250 164 151
1785251 0 164
1785252 151 0
1785253 164 151
1785254 0 164
1785255 151 0
1785256 164 151
1785257 0 164
1785258 151 0
1785259 164 151
1785260 0 164
1785261 151 0
1785262 164 151
1785263 0 164
1785264 151 0
1785265 164 151
1785266 0 164
1785267 151 0
1785268 164 151
1785269 0 164
1785270 151 0
1785271 164 151
1785272 0 164
1785273 151 0
1785274 164 151
1785275 0 164
1785276 151 0
1785277 164 151
1785278 0 164
1785279 151 0
1785280 164 151
1785281 0 164
1785282 151 0
1785283 164 151
1785284 0 164
1785285 151 0
1785286 164 151
1785287 0 164
1785288 151 0
1785289 164 151
1785290 0 164
1785291 151 0
1785292 164 151
1785293 0 164
1785294 151 0
1785295 164 151
1785296 0 164
1785297 151 0
1785298 164 151
1785299 0 164
1785300 151 0
1785301 164 151
1785302 0 164
1785303 151 0
1785304 164 151
1785305 0 164
1785306 151 0
1785307 164 151
1785308 0 164
1785309 151 0
1785310 164 151
1785311 0 164
1785312 151 0
1785313 164 151
1785314 0 164
1785315 151 0
1785316 164 151
1785317 0 164
1785318 151 0
1785319 164 151
1785320 0 164
1785321 151 0
1785322 164 151
1785323 0 164
1785324 151 0
[I have no idea why an RPM is full of such dull and repetitive stuff.]
example 4 is more complex. I've inserted a blank line when there is a
discontinuity in the file offset. I've inserted a second blank line
whenever the checksum ought to be correct (i.e. what is above is a
permutation). In only one case was there a correct checksum and yet
not a break in offsets.
31771 201 101
31772 244 355
31781 101 201
31782 355 244
31799 101 201
31800 355 244
31811 101 201
31812 355 244
31813 201 101
31814 244 355
31815 201 101
31816 244 355
31827 201 101
31828 244 355
31837 101 201
31838 355 244
31843 201 101
31844 244 355
31853 101 201
31854 355 244
31867 101 201
31868 355 244
31881 201 101
31882 244 355
31893 101 201
31894 355 244
31897 201 101
31898 244 355
31911 101 201
31912 355 244
31923 101 201
31924 355 244
31925 201 101
31926 244 355
31927 201 101
31928 244 355
31939 201 101
31940 244 355
31949 101 201
31950 355 244
31955 201 101
31956 244 355
31965 101 201
31966 355 244
31979 101 201
31980 355 244
31993 201 101
31994 244 355
32005 101 201
32006 355 244
32009 201 101
32010 244 355
32023 101 201
32024 355 244
32035 101 201
32036 355 244
32037 201 101
32038 244 355
32039 201 101
32040 244 355
32063 101 201
32064 355 244
32067 201 101
32068 244 355
32079 201 101
32080 244 355
32089 101 201
32090 355 244
32117 101 201
32118 355 244
32121 201 101
32122 244 355
32145 101 201
32146 355 244
32149 201 101
32150 244 355
[no gap in numbers]
32151 201 101
32152 244 355
32161 101 201
32162 355 244
32175 101 201
32176 355 244
32179 201 101
32180 244 355
32203 101 201
32204 355 244
32217 201 101
32218 244 355
32229 101 201
32230 355 244
32233 201 101
32234 244 355
_______________________________________________
tulip mailing list, [email protected]
To change to digest mode or unsubscribe visit
http://www.scyld.com/mailman/listinfo/tulip