Subject: Re: Fix for bug in vr(4)
To: Julio M. Merino Vidal <>
From: Juan RP <>
List: tech-kern
Date: 01/24/2005 11:11:29
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" <> 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:

Content-Type: application/pgp-signature

Version: GnuPG v1.4.0 (NetBSD)