Subject: Re: Fix for bug in vr(4)
To: Julio M. Merino Vidal <jmmv84@gmail.com>
From: Jachym Holecek <freza@liberouter.org>
List: tech-kern
Date: 01/22/2005 22:48:37
> Indeed, adding this check captures the problem, and if I discard those
> packets as erroneous, everything works fine later on (no need for an
> ugly reset). The patch that does this is pasted below.
>
> However... I've tried the same commands that here produce the failure
> under Linux but saw nothing strange (aside from some mysterious
> delays). It may be because their messages are printed at "warning"
> level and my current setting is higher than that... Haven't used linux
> for a long while, so I don't know how to change/verify this ;)
Same here, but the following URL suggests they have/had the same
behaviour:
http://uwsg.iu.edu/hypermail/linux/net/0006.1/0005.html
> Does this look more reasonable? At least it seems to me.
Looks good I think (but someone @netbsd.org should say, really ;-).
Oh, a bit more googling reveals a FreeBSD driver directly from VIA, which
does (reformatted for readability):
if (! ((rxstat & FET_RXSTAT_FIRSTFRAG) &&
(rxstat & FET_RXSTAT_LASTFRAG))) {
fet_newbuf(sc, cur_rx, m);
/*
* For flow control, update RXRDU in FlowCR1 after return buffer
* to MAC.
*/
if (sc->fet_chip_revid >= REV_ID_VT3106)
CSR_WRITE_1(sc, FET_FlowCR0, 1);
continue;
}
Maybe this is worth trying/looking at? Regular FreeBSD's if_vr looks just
the same as current NetBSD's.
Regards,
-- Jachym Holecek