Avoiding check of RxBufEmpty.
Wed Oct 6 00:47:49 1999
On Tue, 5 Oct 1999, Daniel Kobras wrote:
> On Sat, 2 Oct 1999, Donald Becker wrote:
> > It might be possible that we can compare RxBufPtr with RxBufAddr, and
> > avoid any interaction with the ChipCmd register. I'll check on that the
> > next time I have a rtl8139 card in the test machine.
> I gave it a try and was partially successful. I changed rtl8129_rx to
> compare RxBufPtr and RxBufAddr to determine if the Rx buffer is empty and
> it works most of the time. But my implementation can't be 100% correct as
> from time to time the driver reports rx errors. In case of an error,
> rx_size always equals 0xfff0 but that's the only thing they have in
> common. Unfortunately I fail to see the bug. But then I also fail to fully
> understand the code, especially as far as the '- 16' in
> outw(cur_rx - 16, ioaddr + RxBufPtr);
> is concerned. I see RX_BUF_LEN+16 bytes kmalloc()ed for the rx ring but
> apart from debugging the last 16 bytes should never be touched, no? Is
> this somehow related?
The chip doesn't write to the ring size specified. If the header would be
near the end of the ring, it doesn't wrap. This is documented by the ring
size in the datasheet e.g. 32KB + 16. There is an operating mode where
the packet doesn't wrap either -- it just continues linearly past the end of
I'm fuzzy on remembering the details of how I figured out the chip
operation, but the original 8129 datasheet had almost no information on how
the chip works. I spent a lot of time writing test code that filled memory
with a known value went though all of the wrap cases.
> Below's the patch against 2.3.18ac8 I'm currently running with. While http
> and terminal access via slogin work fine, scp and ssh myserver somecmd
> seem to trigger random rx errors in the driver:
Check to see if these errors are always at the end of the ring, or just
Donald Becker firstname.lastname@example.org
USRA-CESDIS, Center of Excellence in Space Data and Information Sciences.
Code 930.5, Goddard Space Flight Center, Greenbelt, MD. 20771
| To unsubscribe, send mail to Majordomo@cesdis.gsfc.nasa.gov, and within the
| body of the mail, include only the text:
| unsubscribe this-list-name email@example.com
| You will be unsubscribed as speedily as possible.