Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 Jul 2002 10:09:00 -0500
From:      Barry Pederson <bp@barryp.org>
To:        Dermot McNally <dermot@directski.com>
Cc:        stable@freebsd.org
Subject:   Re: vr driver causing problems on some chipsets?
Message-ID:  <3D23138C.6040401@barryp.org>
References:  <3D22F53D.2080006@directski.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Dermot McNally wrote:
> Hi,
> 
> I recently installed 4.6 Release (updating to stable) on a new laptop. 
> Its NIC identifies itself as <VIA VT6102 Rhine II 10/100BaseTX> and uses 
> the vr driver - badly. Any kind of heavy load (transferring a large file 
> over LAN, say) triggers the error "vr0: watchdog timeout".
> 
> There isn't much in the archives on this (specifically, no solution), 
> but other folks have reported the same thing, and there's a suggestion 
> that this has been happening ever since this driver started using miibus.

I've got a VIA mini-itx motherboard with that comes up with the same chip 
(VT6102), that stops receiving packets under heavy loads (I can kill it on 
demand just by sending a 3 or 4mb file to Samba).  Outgoing pings are still 
sent, it's really just the receiving that's stopped. Doing an ifconfig 
up/down brings it back to life, or doing a "tcpdump" on that interface will 
revive it too.  Haven't seen the "watchdog timeout" messages though.

I was looking at /usr/src/sys/pci/if_vr.c, and the vr_intr() function looks a 
bit odd to me.  I believe under a heavy load, the chip will frequently report 
a status of 0x801 (which is VR_ISR_RX_DROPPED | VR_ISR_RX_OK), which I take 
to mean a packet has been received, but some others have been dropped.

The way the code is written, in that case it'll call vr_rxeof(sc) 3 times 
back-to-back (twice explicitly and once through vr_rxeoc(sc)), and then reset 
some bits (by way of vr_rxeoc).

I took a look at the Linux drivers I could find, and from what I can tell it 
doesn't do anything special when the VR_ISR_RX_DROPPED status bit is set - 
which sort of makes sense, if a packet's been lost you can't do much about 
it, and should just keep going.

I altered my if_vr.c to remove the check for VR_ISR_RX_DROPPED and have been 
getting much better results with it.  Transferring files to Samba no longer 
kills the interface (although transfers are a bit slow, but that might be bad 
samba tuning?)

Looking at Net/OpenBSD, I found that one (I don't remember which) only calls 
vr_rxeof() twice when a packet is dropped, and the other is basically the 
same as FreeBSD.  But both still act on that "dropped" status bit.

Maybe this driver needs a bit of review by people that know more about this 
hardware?

	Barry


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D23138C.6040401>