Patch the transmit error handler to avoid following NULL pointers and

generating a trap 12 panic. The code blindly assumed that in the event
of a transmit error, the packet that caused the error would still be
at the head of the driver's transmit queue (sc->xl_cdata.xl_tx_head).
However in the case of error 82 (which indicates that a transmit error
occurred after part of the transmit FIFO memory has been reclaimed)
this is not true: the TX queue has already been flushed, and the
pointer to the head of the queue is NULL, so trying to dereference
the pointer to find the transmit descriptor address causes a crash.

The code now checks for a NULL pointer before trying to reload the
chip's download pointer register. There may still be error messages
printed warning of the transmit error, but no panic should occur.

Note that this eror code is only generated with "cyclone" chipsets
(3c900B, 3c905B, and presumeably the 3c980 server adapter). It should
only appear during periods of heavy traffic, probably only on
non-switched networks.

Problem reported by: Darcy Buskermolen <darcy@ok-connect.com>
This commit is contained in:
wpaul 1998-09-06 14:58:46 +00:00
parent e5d890e538
commit 70e4d378e2

View File

@ -29,7 +29,7 @@
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGE.
*
* $Id: if_xl.c,v 1.49 1998/09/04 15:30:02 wpaul Exp $
* $Id: if_xl.c,v 1.9 1998/09/04 16:22:15 wpaul Exp $
*/
/*
@ -127,7 +127,7 @@
#ifndef lint
static char rcsid[] =
"$Id: if_xl.c,v 1.49 1998/09/04 15:30:02 wpaul Exp $";
"$Id: if_xl.c,v 1.9 1998/09/04 16:22:15 wpaul Exp $";
#endif
/*
@ -1904,7 +1904,8 @@ static void xl_txeoc(sc)
sc->xl_unit, txstat);
CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_RESET);
xl_wait(sc);
CSR_WRITE_4(sc, XL_DOWNLIST_PTR,
if (sc->xl_cdata.xl_tx_head != NULL)
CSR_WRITE_4(sc, XL_DOWNLIST_PTR,
vtophys(sc->xl_cdata.xl_tx_head->xl_ptr));
/*
* Remember to set this for the