Date: Wed, 2 May 2001 21:09:39 -0500 (CDT) From: Jonathan Lemon <jlemon@flugsvamp.com> To: tlambert@primenet.com, current@freebsd.org Subject: Re: panic in fxp driver Message-ID: <200105030209.f4329dR74591@prism.flugsvamp.com> In-Reply-To: <local.mail.freebsd-current/200105030158.SAA29983@usr09.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <local.mail.freebsd-current/200105030158.SAA29983@usr09.primenet.com> you write:
>The fxp driver is broken in a lot of places.
>
>For example, in fxp_intr():
>
> for (txp = sc->cbl_first; sc->tx_queued &&
> (txp->cb_status & FXP_CB_STATUS_C) != 0;
> txp = txp->next) {
> if (txp->mb_head != NULL) {
> m_freem(txp->mb_head);
> txp->mb_head = NULL;
> }
> sc->tx_queued--;
> }
>
>...notice the "for" loop doesn't check to see if "txp = txp->next"
>ends up being NULL? You can get this, if you put your system
>under extreme load.
I would be quite interested in knowing just how you manage
to accomplish that, given that all the transmit control buffers
are arranged in a circular linked list:
fxp_init(void *xsc)
{
...
for (i = 0; i < FXP_NTXCB; i++) {
...
txp[i].next = &txp[(i + 1) & FXP_TXCB_MASK];
}
I would suggest actually examining the rest of the code to see
how it works before making erroneous proclamations based on the
myopic examination of a single statement.
--
Jonathan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200105030209.f4329dR74591>