--Signature=_Mon__24_Jan_2005_11_11_29_+0100_eQ5TqX=M84sMw4Be
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

On Sat, 22 Jan 2005 20:28:11 +0100
"Julio M. Merino Vidal" <jmmv84@gmail.com> wrote:

> I've been pointed out that this is not the correct solution (haha, I
> thought that).  So, due to the lack of public documentation (*sigh*),
> I've looked at what the Linux driver does.
> 
> They ensure that every packet comes with the VR_RXSTAT_FIRSTFRAG and
> VR_RXSTAT_LASTFRAG bits set.  Otherwise, they treat it as an "oversized
> ethernet frame" error.
> 
> 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 ;)
> 
> Does this look more reasonable?  At least it seems to me.

This patch fixes my problem with qemu+tap+bridge+vr(4) reported in:

http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=2866


--Signature=_Mon__24_Jan_2005_11_11_29_+0100_eQ5TqX=M84sMw4Be
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iD8DBQFB9MnSypkLYVDran0RAnQFAKCWs1K5yhTm+c+C1kn/KvuNgly25wCeLSiH
172fNPG4papwi9zvIXs7b3c=
=YYO5
-----END PGP SIGNATURE-----

--Signature=_Mon__24_Jan_2005_11_11_29_+0100_eQ5TqX=M84sMw4Be--