Subject: Re: Fix for bug in vr(4)
To: Julio M. Merino Vidal <email@example.com>
From: Juan RP <firstname.lastname@example.org>
Date: 01/24/2005 11:11:29
Content-Type: text/plain; charset=US-ASCII
On Sat, 22 Jan 2005 20:28:11 +0100
"Julio M. Merino Vidal" <email@example.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:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)
-----END PGP SIGNATURE-----