|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Fri, 26 Apr 1996 21:16:13 +0100 (BST) From: John Sullivan <js10039@cam.ac.uk> To: Donald Becker <becker@cesdis1.gsfc.nasa.gov> cc: linux-net@vger.rutgers.edu In-Reply-To: <Pine.SUN.3.91.960425193105.23877C-100000@cesdis1> [cc: list trimmed - I assume everyone is on linux-net...] Also note first that I think Phil (pjb27@cam) may be going to do some work on the 3c507 driver shortly. On Thu, 25 Apr 1996, Donald Becker wrote: > On Thu, 25 Apr 1996, D.A.B. Niggemann wrote: > [[ Context: i82586 chip bugs ]] > > > [Ethernet frame header stored in wrong place by card] > > 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. RFD and RBD resp. I assume. Yes, I think this is exactly the same problem the eexp16 driver used to have. > 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...) Yes. And the first packet received is usually the ARP response for the address of the default router, so we can't do *anything* until a timeout/retransmit has happened for that frame. (Actually, it's not guaranteed to be just the first frame that this happens to but, it usually is. It's a time-related problem, rather than number-of-packets-related.) The problem is that we tell the 82586 not to trim the header off in the chip configuration command, during initialization. We *should* then wait until the configure has completed, before enabling the receive/transmit units for normal traffic, but we don't. So until the command *has* completed, the chip follows its default behaviour of stripping ethernet headers and only delivering the contents... > [various suggested fixes] Some nasty hacks here - keep up the good work ;) At least this bug is now sorted with the eexp16 driver, and hopefully soon with the 3c507 aswell. There exist other bugs still with the eexp, and I presume these also affect the 3c507. Work continues... John -- The cat shat on my mat. The cat is now a hat. <p><a href="http://callisto.girton.cam.ac.uk/users/js10039/">Me.</a>
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |