Aren
/
NetBSD
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Pull a fix for PCIe variants from FreeBSD's if_re.c rev 1.71: 

> - With the PCIe devices, it looks issuing a TX command while there's
>   already a transmission in progress doesn't have any effect. In other
>   words, if you send two packets in rapid succession, the second one may
>   end up sitting in the TX DMA ring until another transmit command is
>   issued later in the future. Basically, if re_txeof() sees that there
>   are still descriptors outstanding, it needs to manually resume the
>   TX DMA channel by issuing another TX command to make sure all
>   transmissions are flushed out. (The PCI devices seem to keep the
>   TX channel moving until all descriptors have been consumed. I'm not
>  sure why the PCIe devices behave differently.)
This commit is contained in:
tsutsui 2007-05-10 14:04:47 +00:00
parent 7806d3dfc4
commit 25476aa317
1 changed files with 15 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
sys/dev/ic/rtl8169.c
View File

@ -1,4 +1,4 @@
/* $NetBSD: rtl8169.c,v 1.84 2007/03/21 12:17:31 tsutsui Exp $ */
/* $NetBSD: rtl8169.c,v 1.85 2007/05/10 14:04:47 tsutsui Exp $ */
/*
* Copyright (c) 1997, 1998-2003
@ -1358,9 +1358,21 @@ re_txeof(struct rtk_softc *sc)
* interrupt that will cause us to re-enter this routine.
* This is done in case the transmitter has gone idle.
*/
if (sc->re_ldata.re_txq_free < RE_TX_QLEN)
if (sc->re_ldata.re_txq_free < RE_TX_QLEN) {
CSR_WRITE_4(sc, RTK_TIMERCNT, 1);
else
if ((sc->sc_quirk & RTKQ_PCIE) != 0) {
/*
* Some chips will ignore a second TX request
* issued while an existing transmission is in
* progress. If the transmitter goes idle but
* there are still packets waiting to be sent,
* we need to restart the channel here to flush
* them out. This only seems to be required with
* the PCIe devices.
*/
CSR_WRITE_2(sc, RTK_GTXSTART, RTK_TXSTART_START);
}
} else
ifp->if_timer = 0;
}