From nobody@FreeBSD.org  Fri Feb 23 21:39:30 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id ADC6016A400
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 Feb 2007 21:39:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 9114F13C4A3
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 Feb 2007 21:39:30 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l1NLdULm020463
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 23 Feb 2007 21:39:30 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l1NLdUu2020462;
	Fri, 23 Feb 2007 21:39:30 GMT
	(envelope-from nobody)
Message-Id: <200702232139.l1NLdUu2020462@www.freebsd.org>
Date: Fri, 23 Feb 2007 21:39:30 GMT
From: Burkhard Steding<burkhard.steding@gmx.de>
To: freebsd-gnats-submit@FreeBSD.org
Subject: onboard via vt6103 ethernet does not work
X-Send-Pr-Version: www-3.0

>Number:         109477
>Category:       kern
>Synopsis:       [vr] [patch] onboard via vt6103 ethernet does not work
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    yongari
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Feb 23 21:40:03 GMT 2007
>Closed-Date:    Fri Sep 24 19:57:24 UTC 2010
>Last-Modified:  Fri Sep 24 19:57:24 UTC 2010
>Originator:     Burkhard Steding
>Release:        6.2-Release
>Organization:
>Environment:
FreeBSD  6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 08:32:24 UTC 2007     root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC  amd64
>Description:
Feb 23 20:55:50  kernel: vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xee00-0xe
eff mem 0xdfffd000-0xdfffd0ff irq 23 at device 18.0 on pci0
Feb 23 20:55:50  kernel: miibus0: <MII bus> on vr0
Feb 23 20:55:50  kernel: ukphy0: <Generic IEEE 802.3u media interface> on miibus
0
Feb 23 20:55:50  kernel: ukphy0:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy1: <Generic IEEE 802.3u media interface> on miibus
0
Feb 23 20:55:50  kernel: ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX
, auto
Feb 23 20:55:50  kernel: ukphy2: <Generic IEEE 802.3u media interface> on miibus
0
Feb 23 20:55:50  kernel: ukphy2:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy3: <Generic IEEE 802.3u media interface> on miibus
Feb 23 20:55:50  kernel: ukphy3:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy4: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy4:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy5: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy5:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy6: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy6:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy7: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy7:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy8: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy8:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy9: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy9:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy10: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy10:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy11: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy11:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy12: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy12:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy13: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy13:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy14: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy14:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy15: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy15:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy16: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy16:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy17: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy17:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy18: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy18:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy19: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy19:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy20: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy20:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy21: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy21:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy22: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy22:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy23: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy23:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy24: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy24:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy25: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy25:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy26: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy26:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy27: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy27:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy28: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy28:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy29: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy29:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy30: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy30:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: ukphy31: <Generic IEEE 802.3u media interface> on miibus0
Feb 23 20:55:50  kernel: ukphy31:  100baseTX, 100baseTX-FDX, 100baseT4
Feb 23 20:55:50  kernel: vr0: Ethernet address: 00:30:1b:81:02:96

and, somewhat later:

Feb 23 20:55:54  kernel: vr0: watchdog timeout

I can do a "ping 192.168.42.21" but I can not reach any other machine on
the subnet. I have verified that it's neither a hardware nor a cable
problem. It works fine with a NetBSD installation. By the way, the FreeBSD
and the NetBSD if_vr.c driver are derived from the same original source,
but have evolved since then.

I have build a custom kernel specific for my hardware with if_vr.ko as
a loadable module and I am willing to assist in bug fixing, if my time
allows. I have some experience in writing a device driver but do not
know anything about the via rhine chips.

>How-To-Repeat:
The problem can easyly be repeated both with the GENERIC kernel and a
custom kernel that uses if_vr.ko as a loadable module. Then the messages
show up after "kldload if_vr.ko".
>Fix:

>Release-Note:
>Audit-Trail:
From: Remko Lodder <remko@FreeBSD.org>
To: Burkhard Steding <burkhard.steding@gmx.de>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: misc/109477: onboard via vt6103 ethernet does not work
Date: Sat, 24 Feb 2007 09:54:42 +0100

 >> Description:
 > Feb 23 20:55:50  kernel: vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xee00-0xe
 > eff mem 0xdfffd000-0xdfffd0ff irq 23 at device 18.0 on pci0
 > Feb 23 20:55:50  kernel: miibus0: <MII bus> on vr0
 > 
 > and, somewhat later:
 > 
 > Feb 23 20:55:54  kernel: vr0: watchdog timeout
 > 
 > I can do a "ping 192.168.42.21" but I can not reach any other machine on the subnet. I have verified that it's neither a hardware nor a cable problem. It works fine with a NetBSD installation. By the way, the FreeBSD and the NetBSD if_vr.c driver are derived from the same original source, but have evolved since then.
 > 
 > I have build a custom kernel specific for my hardware with if_vr.ko as a loadable module and I am willing to assist in bug fixing, if my time allows. I have some experience in writing a device driver but do not know anything about the via rhine chips.
 > 
 >> How-To-Repeat:
 > The problem can easyly be repeated both with the GENERIC kernel and a custom kernel that uses if_vr.ko as a loadable module. Then the messages show up after "kldload if_vr.ko".
 >> Fix:
 
 Hello,
 
 Now that is interesting, I happen to have the exact same ethernet card
 onboard of my motherboard:
 
 redqueen# cat /var/run/dmesg.boot | grep vr
 vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0x7400-0x74ff mem 
 0xf0000000-0xf00000ff at device 18.0 on pci0
 miibus0: <MII bus> on vr0
 vr0: Ethernet address: 00:0c:6e:8d:88:ad
 
 I am using this for like two years now without a problem. Can you tell
 me whether you see traffic passing over the vr0 card at all? (tcpdump
 -n -i vr0 would give information about that), do you see arp adresses
 being exchanged? What happends when you try to setup traffic towards
 another host?
 
 What do you have installed on your system? (anything of these might
 prevent your data other then ping, being blocked)...
 
 Hope to see your answers soon!
 
 Cheers,
 Remko
 
 -- 
 Kind regards,
 
       Remko Lodder               ** remko@elvandar.org
       FreeBSD                    ** remko@FreeBSD.org
 
       /* Quis custodiet ipsos custodes */

From: linimon@lonesome.com (Mark Linimon)
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/109477: [vr] onboard via vt6103 ethernet does not work
Date: Mon, 26 Feb 2007 14:46:28 -0600

  The following diff fixed the problem for me.
  
  __FBSDID("$FreeBSD: src/sys/pci/if_vr.c,v 1.104.2.6 2006/03/17 21:30:57 
  glebius Exp $");
  
  *** if_vr.c~    Mon Feb 26 11:21:43 2007
  --- if_vr.c     Mon Feb 26 11:22:43 2007
  ***************
  *** 457,462 ****
  --- 457,463 ----
   
          switch (sc->vr_revid) {
          case REV_ID_VT6102_APOLLO:
  +       case 0x78:
                  if (phy != 1) {
                          frame.mii_data = 0;
                          goto out;
  ***************
  *** 482,487 ****
  --- 483,489 ----
   
          switch (sc->vr_revid) {
          case REV_ID_VT6102_APOLLO:
  +       case 0x78:
                  if (phy != 1)
                          return (0);
          default:
  
Responsible-Changed-From-To: freebsd-bugs->remko 
Responsible-Changed-By: remko 
Responsible-Changed-When: Tue Feb 27 06:54:20 UTC 2007 
Responsible-Changed-Why:  
I'll take it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 

From: "Nobuhiro Ban" <ban.nobuhiro@gmail.com>
To: bug-followup@freebsd.org, burkhard.steding@gmx.de
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not work
Date: Sun, 5 Aug 2007 01:01:41 +0900

 I have two PCs with VT6102 chips (pcA and pcB).
 The src/sys/pci/if_vr driver (1.104.2.6) worked well on pcA,
 but didn't work on pcB.
 
 I noticed that these two chips have different revision IDs.
 I don't know how to show the revision ID on FreeBSD, so I checked on Linux.
 
 Linux's lspci command said:
 > pcA$ lspci | grep Rhine
 >  00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)
 
 > pcB$ lspci | grep Rhine
 >  00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78)
 
 I applied the patch from Mark Linimon, which adds support for ID=0x78.
 Thanks for this nice patch, it seems to work good on pcB.

From: "Arno J. Klaassen" <arno@heho.snv.jussieu.fr>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not work
Date: 31 Oct 2007 21:17:18 +0100

 Hi,
 
 I've a board giving problems with rev 0x78 as well.
 
 Dunno what happened exactly (box (EPIA) at custumor site) but
 I see the following in the log :
 
 Oct 25 18:31:04 scito kernel: vr1: watchdog timeout
 Oct 25 18:31:04 scito kernel: vr1: Using force reset command.
 Oct 25 18:32:19 scito kernel: vr1: watchdog timeout
 Oct 25 18:33:33 scito kernel: vr1: watchdog timeout
 Oct 25 18:34:48 scito kernel: vr1: watchdog timeout
 Oct 25 18:38:34 scito last message repeated 3 times
 Oct 25 18:38:34 scito kernel: vr1: Using force reset command.
 Oct 25 18:39:49 scito kernel: vr1: watchdog timeout
 Oct 25 18:41:04 scito kernel: vr1: watchdog timeout
 
 
 Then, vr0 is still working OK, vr1 is out of service (till next
 reboot).
 
 From pciconf :
 
 vr0@pci0:13:0:  class=0x020000 card=0x01071106 chip=0x30651106 rev=0x8d hdr=0x00
     vendor     = 'VIA Technologies Inc'
     device     = 'VT6102 Rhine II PCI Fast Ethernet Controller'
 
 vr1@pci0:18:0:  class=0x020000 card=0x01021106 chip=0x30651106 rev=0x78 hdr=0x00
     vendor     = 'VIA Technologies Inc'
     device     = 'VT6102 Rhine II PCI Fast Ethernet Controller'
 
 
 I'll cook a new kernel with the proposed patch, but this is the first
 time a see such a hard hang in 6 months service ...
 
 Regards,
 
 Arno
 
 -- 
 
   Arno J. Klaassen
 
   SCITO S.A.
   8 rue des Haies
   F-75020 Paris, France
   http://scito.com
 
Responsible-Changed-From-To: remko->yongari 
Responsible-Changed-By: remko 
Responsible-Changed-When: Mon Nov 12 20:40:23 UTC 2007 
Responsible-Changed-Why:  
Pyon has a nice patch in progress that could resolve this, so this 
might be better of in his guard. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 

From: Carsten Baecker <carbaecker@gmx.de>
To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
 work
Date: Tue, 20 Nov 2007 17:09:45 +0000

 This is a multi-part message in MIME format.
 --------------050806000307000509020101
 Content-Type: text/plain; charset=ISO-8859-15; format=flowed
 Content-Transfer-Encoding: 7bit
 
 Hi,
 
 my VIA KT400 based MSI-KT4V leads into vr-problems with VT6102 rev 0x74 
 as well.
 
 Continuing watchdog timeouts and resets. I didn't experience any problem 
 running 6.2-STABLE nor running 6.3-PRERELEASE. Problems occurred after 
 updating to 7.0-BETA3 using cvsup and rebuilding world + kernel.
 
 Since i got some older information from Google, i checked PCI-Delayed 
 transaction and tried disabling ACPI. No effort.
 Setting the driver to use "10baseT/UTP" helped a lot. Setting "100baseTX 
 half-duplex" reduced watchdog timeouts, but leads into losing some packets.
 
 I noticed a boot-message, saying that an obsoleted if_watchdog interface 
 was used.
 
 *Here's the block from dmesg:*
 
     vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xc400-0xc4ff mem 
 0xdfff9d00-0xdfff9dff irq 11 at device 18.0 on pci0
     vr0: Quirks: 0x0
     miibus1: <MII bus> on vr0
     ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
     ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
     vr0: using obsoleted if_watchdog interface
     vr0: Ethernet address: 00:10:dc:96:a6:06
     vr0: [ITHREAD]
 
 
 *Output from pciconf:*
 
     vr0@pci0:0:18:0:        class=0x020000 card=0x71201462 
 chip=0x30651106 rev=0x74 hdr=0x00
         vendor     = 'VIA Technologies Inc'
         device     = 'VT6102 Rhine II PCI Fast Ethernet Controller||Used 
 by GERICOM in laptop Webengine Advanced'
 
 *
 uname -a says:*
 
     FreeBSD cBSD-1.Baecker 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Tue Nov 20 
 13:36:49 UTC 2007 root@cBSD-1.Baecker:/usr/obj/usr/src/sys/CB-2200 i386
 
 Problem also exists when running GENERIC.
 
 
 Best Regards,
 
 Carsten
 
 --------------050806000307000509020101
 Content-Type: text/html; charset=ISO-8859-15
 Content-Transfer-Encoding: 8bit
 
 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
 <head>
 </head>
 <body bgcolor="#ffffff" text="#000000">
 Hi,<br>
 <br>
 my VIA KT400 based MSI-KT4V leads into vr-problems with VT6102 rev 0x74
 as well.<br>
 <br>
 Continuing watchdog timeouts and resets. I didn't experience any
 problem running 6.2-STABLE nor running 6.3-PRERELEASE. Problems
 occurred after updating to 7.0-BETA3 using cvsup and rebuilding world +
 kernel.<br>
 <br>
 Since i got some older information from Google, i checked PCI-Delayed
 transaction and tried disabling ACPI. No effort. <br>
 Setting the driver to use "10baseT/UTP" helped a lot. Setting
 "100baseTX half-duplex" reduced watchdog timeouts, but leads into
 losing some packets.<br>
 <br>
 I noticed a boot-message, saying that an obsoleted if_watchdog
 interface was used.<br>
 <br>
 <b>Here's the block from dmesg:</b><br>
 <br>
  vr0: &lt;VIA VT6102 Rhine II 10/100BaseTX&gt; port 0xc400-0xc4ff
 mem 0xdfff9d00-0xdfff9dff irq 11 at device 18.0 on pci0<br>
  vr0: Quirks: 0x0<br>
  miibus1: &lt;MII bus&gt; on vr0<br>
  ukphy0: &lt;Generic IEEE 802.3u media interface&gt; PHY 1 on miibus1<br>
  ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto<br>
  vr0: using obsoleted if_watchdog interface<br>
  vr0: Ethernet address: 00:10:dc:96:a6:06<br>
  vr0: [ITHREAD]<br>
 <br>
 <br>
 <b>Output from pciconf:</b><br>
 <br>
  vr0@pci0:0:18:0: class=0x020000 card=0x71201462
 chip=0x30651106 rev=0x74 hdr=0x00<br>
   vendor = 'VIA Technologies Inc'<br>
   device = 'VT6102 Rhine II PCI Fast Ethernet
 Controller||Used by GERICOM in laptop Webengine Advanced'<br>
 <br>
 <b><br>
 uname -a says:</b><br>
 <br>
  FreeBSD cBSD-1.Baecker 7.0-BETA3 FreeBSD 7.0-BETA3 #4: Tue Nov 20
 13:36:49 UTC 2007 <a class="moz-txt-link-abbreviated" href="mailto:root@cBSD-1.Baecker:/usr/obj/usr/src/sys/CB-2200">root@cBSD-1.Baecker:/usr/obj/usr/src/sys/CB-2200</a> i386<br>
 <br>
 Problem also exists when running GENERIC.<br>
 <br>
 <br>
 Best Regards,<br>
 <br>
 Carsten<br>
 </body>
 </html>
 
 --------------050806000307000509020101--
State-Changed-From-To: open->feedback 
State-Changed-By: yongari 
State-Changed-When: Wed Nov 21 01:39:20 UTC 2007 
State-Changed-Why:  
I guess you're seeing different bug in vr(4). How about vr(4) patch 
posted to CURRENT? 
http://lists.freebsd.org/pipermail/freebsd-current/2007-October/077941.html 

Btw, I have a overhauled vr(4) that fixes several known issues. If you 
see phantom phys attached to vr(4) as the PR indicates try overhauled 
version. 
http://people.freebsd.org/~yongari/vr/if_vr.c 
http://people.freebsd.org/~yongari/vr/if_vrreg.h 


http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 

From: Carsten Baecker <carbaecker@gmx.de>
To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
 work
Date: Fri, 23 Nov 2007 14:45:48 +0000

 Hi again,
 
 your overhauled files work pretty good. No more timeouts or resets, no 
 messages about using obsoleted interfaces.
 
 I performed a stress-test yesterday and it went pretty good. Just some 
 information about Tx underruns and increasing Tx threshold.
 vr0: Tx underrun -- increasing Tx threshold(128 -> 256)
 vr0: Tx underrun -- increasing Tx threshold(256 -> 512)
 vr0: Tx underrun -- increasing Tx threshold(512 -> 1024)
 
 Best regards
 Carsten

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Carsten Baecker <carbaecker@gmx.de>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not work
Date: Sat, 24 Nov 2007 10:24:28 +0900

 On Fri, Nov 23, 2007 at 01:50:04PM +0000, Carsten Baecker wrote:
  > The following reply was made to PR kern/109477; it has been noted by GNATS.
  > 
  > From: Carsten Baecker <carbaecker@gmx.de>
  > To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
  > Cc:  
  > Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
  >  work
  > Date: Fri, 23 Nov 2007 14:45:48 +0000
  > 
  >  Hi again,
  >  
  >  your overhauled files work pretty good. No more timeouts or resets, no 
  >  messages about using obsoleted interfaces.
  >  
  >  I performed a stress-test yesterday and it went pretty good. Just some 
  >  information about Tx underruns and increasing Tx threshold.
  >  vr0: Tx underrun -- increasing Tx threshold(128 -> 256)
  >  vr0: Tx underrun -- increasing Tx threshold(256 -> 512)
  >  vr0: Tx underrun -- increasing Tx threshold(512 -> 1024)
  >  
  >  Best regards
  >  Carsten
 
 Thanks for testing. The Tx underrun message is harmless and
 informtional one. The overhauled vr(4) changes too many parts and
 various error handling case so it needs more expore and testing
 before hitting tree.
 
 Since we're approching to the last state of releasing 7.0-RELESE I'd
 like to know whether the patch posted to CURRENT has any effect.
 http://lists.freebsd.org/pipermail/freebsd-current/2007-October/077941.html
 
 -- 
 Regards,
 Pyun YongHyeon

From: Carsten Baecker <carbaecker@gmx.de>
To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
 work
Date: Sat, 24 Nov 2007 10:41:24 +0000

 OK. I just applied the patch to if_vr.c
 
 The message about the obsoleted interface is back. So are the timeouts 
 and resets. The patch doesn't bring any improvement - at least for my 
 problem.
 
 I got about twenty timeouts in less than two minutes while doing a very 
 simple test. (Copying a file from nfs-mounted file-system)
 
  From Nov 24 10:15:22 to Nov 24 10:17:06
 
 kernel: vr0: watchdog timeout
 last message repeated 2 times
 kernel: vr0: Using force reset command.
 vr0: watchdog timeout
 last message repeated 6 times
 last message repeated 11 times
 
 
 How can i help?
 
 Best Regards
 Carsten
State-Changed-From-To: feedback->analyzed 
State-Changed-By: yongari 
State-Changed-When: Mon Nov 26 07:46:04 UTC 2007 
State-Changed-Why:  
Feedback received. vr(4) needs major rework which would be done 
after releasing 7.0-RELEASE. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Burkhard Steding <burkhard.steding@gmx.de>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not work
Date: Mon, 26 Nov 2007 16:38:55 +0900

 On Sat, Nov 24, 2007 at 02:03:16PM +0100, Burkhard Steding wrote:
  > yongari@FreeBSD.org wrote:
  > >Synopsis: [vr] [patch] onboard via vt6103 ethernet does not work
  > >
  > >State-Changed-From-To: open->feedback
  > >State-Changed-By: yongari
  > >State-Changed-When: Wed Nov 21 01:39:20 UTC 2007
  > >State-Changed-Why: 
  > >I guess you're seeing different bug in vr(4). How about vr(4) patch
  > >posted to CURRENT?
  > >http://lists.freebsd.org/pipermail/freebsd-current/2007-October/077941.html
  > >
  > >Btw, I have a overhauled vr(4) that fixes several known issues. If you
  > >see phantom phys attached to vr(4) as the PR indicates try overhauled
  > >version.
  > >http://people.freebsd.org/~yongari/vr/if_vr.c
  > >http://people.freebsd.org/~yongari/vr/if_vrreg.h
  > >
  > >
  > >http://www.freebsd.org/cgi/query-pr.cgi?pr=109477
  > >
  > >  
  > Yes, I saw a different bug.
  > My problem was gone with the patch mentioned in kern/109477 (revision id 
  > 0x78).
 
 I think that's not correct fix for the issue. In order to fix the
 phanthom phys attached to vr(4), phy handling code should be
 modified to get correct PHY address loaded from EEPROM. It needs
 major rework for phy accesses and only overhauled vr(4) will handle
 the issue correctly. I'll handle it after releasing 7.0-RELEASE.
 
  > I don't use current, so I can't apply your patch.
  > 
 
 
 -- 
 Regards,
 Pyun YongHyeon

From: Pyun YongHyeon <pyunyh@gmail.com>
To: Carsten Baecker <carbaecker@gmx.de>
Cc: yongari@FreeBSD.org, bug-followup@FreeBSD.org
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not work
Date: Mon, 26 Nov 2007 16:42:25 +0900

 On Sat, Nov 24, 2007 at 09:50:02AM +0000, Carsten Baecker wrote:
  > The following reply was made to PR kern/109477; it has been noted by GNATS.
  > 
  > From: Carsten Baecker <carbaecker@gmx.de>
  > To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
  > Cc:  
  > Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
  >  work
  > Date: Sat, 24 Nov 2007 10:41:24 +0000
  > 
  >  OK. I just applied the patch to if_vr.c
  >  
  >  The message about the obsoleted interface is back. So are the timeouts 
  >  and resets. The patch doesn't bring any improvement - at least for my 
  >  problem.
  >  
  >  I got about twenty timeouts in less than two minutes while doing a very 
  >  simple test. (Copying a file from nfs-mounted file-system)
  >  
  >   From Nov 24 10:15:22 to Nov 24 10:17:06
  >  
  >  kernel: vr0: watchdog timeout
  >  last message repeated 2 times
  >  kernel: vr0: Using force reset command.
  >  vr0: watchdog timeout
  >  last message repeated 6 times
  >  last message repeated 11 times
  >  
  >  
  >  How can i help?
 
 Thanks for testing. As you've seen vr(4) should be taught to handle
 edge cases and that requires major changes. I'll handle it after
 releasing 7.0-RELEASE.
 
 Thanks.
 -- 
 Regards,
 Pyun YongHyeon

From: =?ISO-8859-15?Q?Carsten_B=E4cker?= <carbaecker@gmx.de>
To: bug-followup@FreeBSD.org, burkhard.steding@gmx.de
Cc:  
Subject: Re: kern/109477: [vr] [patch] onboard via vt6103 ethernet does not
 work
Date: Fri, 25 Jul 2008 16:08:48 +0200

 FYI:
 
 I rebuilt world+kernel recently (RELENG_7 2008-07-20 11:20) and just 
 retried network-connection using the vr-interace. I did not run into any 
 further trouble.
 So it seems to work fine on VT6102 rev 0x74.
 
 Thanks.
 
 Regards
 Carsten
State-Changed-From-To: analyzed->feedback 
State-Changed-By: yongari 
State-Changed-When: Mon May 31 23:53:57 UTC 2010 
State-Changed-Why:  
Is it still issue on more recent FreeBSD releases? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 
State-Changed-From-To: feedback->closed 
State-Changed-By: yongari 
State-Changed-When: Fri Sep 24 19:56:59 UTC 2010 
State-Changed-Why:  
Feed back timeout(4 months) 
I believe it was fixed long time ago. If you encounter the issue 
again please open a new PR. 
Thanks for reporting. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109477 
>Unformatted:
