Subject: Re: kern/28664: vr(4) driver timeouts
To: Juan RP <juan@xtraeme.nopcode.org>
From: Julio M. Merino Vidal <jmmv@menta.net>
List: netbsd-bugs
Date: 12/16/2004 21:28:27
On Wed, 15 Dec 2004 04:20:00 +0000 (UTC)
"Juan RP" <juan@xtraeme.nopcode.org> wrote:

> >Description:
> 
> 
> I was playing with the QEMU emulator, when I noticed a weird thing,
> My configuration looks like:
> 
> 	vr0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
>         address: 00:11:2f:3c:66:b5
>         media: Ethernet autoselect (100baseTX full-duplex)
>         status: active
>         inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::211:2fff:fe3c:66b5%vr0 prefixlen 64 scopeid 0x1
> 
> ethfoo0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
>         address: f0:0b:a4:c3:29:bb
>         media: Ethernet autoselect
>         inet 192.168.1.5 netmask 0xffffff00 broadcast 192.168.1.255
>         inet6 fe80::f20b:a4ff:fec3:29bb%ethfoo0 prefixlen 64 scopeid 0x3
> bridge0: flags=41<UP,RUNNING> mtu 1500
> 
> When I boot an OS inside QEMU, it gets assigned an IP via dhcp correctly
> and you can interact correctly, but when trying to install a package from
> pkgsrc (NFS mount), my vr(4) was totally stopped without receiving/sending
> packets, I saw "vr0: device timeout".
> 
> I have no problems when using it without the bridge0.

I think this is due to the card being set to promiscuous mode, because I
have a related problem.

Two days ago I also set up a bridge to connect two different networks, one
in vr0 (my home network), and another one in ne0 (connected to another
single pc).

Since then, I get many panic's during startup while dhclient configures
the network card.  After the card is configured, everything works flawlessy
though.  Some time ago, I posted to current-users@ (I think) about the
problem, but got no solution.  That time, I could "easily" (but not always)
reproduce it by using tcpdump while running dhclient.

But it's not very deterministic.  I also hit this problem (panics, not the
time outs) without tcpdump nor a bridge from time to time (though this way
it's _very_ random).

I'll try to get a crash dump tomorrow, because I'm sure it'll happen again
when I power up the computer.  BTW, when in ddb, any attempt to sync
results in timeouts from all devices (ne0, vr0 and ata).  I guess it's due
to the kernel being locked and not being able to service them?

By the way, it's quite curious:  I boot the computer, it panics, reboot it,
panics again, reboot it, works fine.  It's usually this way... will see
what happens tomorrow.

-- 
Julio M. Merino Vidal <jmmv@menta.net>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/