[2669] in linux-net channel archive
Re: 3c507/exos205/ni5210 drivers. ARP problems?
daemon@ATHENA.MIT.EDU (Donald Becker)
Fri Apr 26 10:06:22 1996
Date: Thu, 25 Apr 1996 19:48:10 -0400 (EDT)
From: Donald Becker <becker@cesdis1.gsfc.nasa.gov>
To: "D.A.B. Niggemann" <dabn100@hermes.cam.ac.uk>
Cc: linux-net@vger.rutgers.edu, Alan Cox <iialan@iifeak.swan.ac.uk>,
Michael Hipp <Michael.Hipp@student.uni-tuebingen.de>
In-Reply-To: <Pine.SOL.3.91.960425175428.29028A@hammer.thor.cam.ac.uk>
On Thu, 25 Apr 1996, D.A.B. Niggemann wrote:
[[ Context: i82586 chip bugs ]]
> It appeared that the ethernet packet header (source, dest, packet type)
> was put in the RFD rather than in the RBD. Since each RFD has a single
> RBD in my driver, this does not seem to have anything to do with anything
> sensible (there appears to be a bug in i82586 _multiple_ RBD handling
> according to Michael, but this bug should not appear with only one RBD!
Although I don't have a 3c507, I encountered exactly the same problem with
the EtherExpress driver. It should be impossible, but the header was
put with the RFD, and the rest of the packet was put in the RFD.
The subseqent received packets would be stored correctly, which meant that
the configuration setting was still correct! (The configuration can only be
changed with a complete setup frame.)
> This problem seems to only happen with the _first_ packet recived
> (although I have had timeouts with ncsa ftp which lead me to believe it
> could happen with random packets as well...)
I saw it happen with random packets as well.
> I am wondering whether:
>
> a) this is a known problem and the packet has to be manually reconstructed...
Hmmm, I didn't even think of that approach! I'll bet that it would have
worked...
> b) this is not due to info being written in the RFD but due to an
> incorrect RBD offset of some sort.
No, I don't think so. I tried seperating them, writing known marker values
in those locations, etc.
> c) it is due to incorrect initialization of the i82586 (can you _tell_ it
> to put this data in the RFD instead?)
Yes, you can tell it to always put the header info with the RFD instead of
with the RFBs. Doing so has several other effects. I don't recall what they
were, but I remember that they didn't look like a Good Thing.
> Somebody with an i82586 data book (and, hopefully, an errata sheet) could
> really help me on this one....)
The Intel literature dept. claims that no errata sheet is available, and
the support people that they pointed me to implied that the part works as
documented. I would have had to pay them money and sign an NDA to find
out otherwise. Grrrr.
Donald Becker becker@cesdis.gsfc.nasa.gov
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
301-286-0882 http://cesdis.gsfc.nasa.gov/pub/people/becker/whoiam.html
