Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.
i'm running the PCMCIA-cs built into the linux 2.6.8 kernel.
i have 3 different PCMCIA NICs:
buffalo LPC4-CLX (100baseTX, 16-bit i/f) - axnet_cs
xircom PS-CE2-10 (10baseT) - xirc2ps_cs
Dlink DE-650 (10baseT) - pcnet_cs
all of these cards perform just fine shuffling packets to & from the internet. however they all behave differently when mounting NFS shares.
the Dlink card works perfectly AFAICT. this is what convinces me my problem is a pcmcia-cs problem, rather than something else.
the Xircom card takes a very very long time to mount NFS shares (timescale of minutes), but once mounted, performs acceptably.
the Buffalo card sometimes hangs completely on NFS mounts; sometimes mounts after a very very long time, then can browse remote directories, but then immediately hangs upon real packet loading. the card cannot be used at all for NFS. IIRC, i had previously gotten this NIC working correctly on a previous linux installation with a 2.4 kernel and pcmcia-cs built as standalone modules.
can anyone give me some pointers for how to troubleshoot this situation & get these two NICs working properly with linux?
First off, what hardware are you connecting to? You're connecting to the same hub/switch/whatever in each case? Are you using known-good network cabling? It could be that if you've got any slightly flaky equipment, that the demands of NFS may produce qualitatively different results with different cards. NFS tends to be more sensitive to occasional lost packets than some other protocols.
i haven't got a cable tester, and the switch is poorly instrumented (jellybean ASIC on my home gateway). however, these are both of recent manufacture, and the network installation is identical in every case, except for varying the NIC.
looking at the interface statistics:
the Buffalo card produces many dropped packets (rate ~100/min) when an NFS share is mounted & subjected to ethernet load. it also shows a few bad frames. presumably this behavior, and NFS's intolerance of the loss, causes the freezes.
however, this problem disappears when the same remote directory is remounted as an SMB share and subjected to an identical load. zero bad frames, zero dropped packets. i find this puzzling. why should varying a higher-layer protocol affect layer 2 errors?
also, the Xircom card (which is slow-mounting under NFS, like the Buffalo, but otherwise works OK) shows zero frame/drop errors. again, this card performs well doing the same test over SMB; only NFS presents symptoms. i suppose the slow-mounting problem, whatever it is, is unrelated to the dropped-frame problem.
thanks for any help