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