--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--