From owner-freebsd-stable Wed Jul 3 8: 9:24 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC79A37B400 for ; Wed, 3 Jul 2002 08:09:20 -0700 (PDT) Received: from msn166-109.med.und.nodak.edu (msn166-109.med.und.NoDak.edu [134.129.166.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70DE643E31 for ; Wed, 3 Jul 2002 08:09:20 -0700 (PDT) (envelope-from bp@barryp.org) Received: from geo.med.und.nodak.edu ([134.129.166.11] helo=barryp.org) by msn166-109.med.und.nodak.edu with esmtp (TLSv1:RC4-MD5:128) (Exim 4.03) id 17Plkj-0007Uw-00; Wed, 03 Jul 2002 10:09:09 -0500 Message-ID: <3D23138C.6040401@barryp.org> Date: Wed, 03 Jul 2002 10:09:00 -0500 From: Barry Pederson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dermot McNally Cc: stable@freebsd.org Subject: Re: vr driver causing problems on some chipsets? References: <3D22F53D.2080006@directski.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dermot McNally wrote: > Hi, > > I recently installed 4.6 Release (updating to stable) on a new laptop. > Its NIC identifies itself as 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