Re: CFT: vr(4)

From: Pyun YongHyeon <pyunyh_at_gmail.com>
Date: Mon, 11 Feb 2008 14:35:37 +0900
On Mon, Feb 04, 2008 at 09:03:00PM -0500, Mike Tancsa wrote:
 > At 02:56 PM 2/4/2008, Stefan Ehmann wrote:
 > >On Monday 04 February 2008 18:47:44 Marcin Wisnicki wrote:
 > >> On Mon, 04 Feb 2008 10:48:02 -0500, Mike Tancsa wrote:
 > >> > At 09:23 PM 2/3/2008, Pyun YongHyeon wrote:
 > >> >>Dear all,
 > >> >>
 > >> >>Here is overhauled vr(4) that shall address all known issues. PR
 > >> >>database showed vr(4) is not stable enough under high load and
 > >> >
 > >> > Hi,
 > >> >          Is there a RELENG_7 or 6 version of the driver to test ?
 > >> > Using RELENG_7 from this morning, I get
 > >>
 > >> Try this:
 > >>   http://wisnia21.freeshell.org/f/freebsd/if_vr-pyunyh-to-releng6.diff
 > >>
 > >> On RELENG7 there could be a conflict in second change that should be
 > >> safe to ignore.
 > >Using it with the second chunk ignored.
 > >
 > >> I'm not 100% sure if this is all that is required for RELENG6, but it
 > >> works wonderfully so far.
 > >>
 > >> Even fixed Rx errors I was seeing for some time and didn't have the time
 > >> to investigate whether they were caused by some recent commit to releng6
 > >> (like the last mfc) or simply a hardware failure.
 > >
 > >The current vr driver works fine for me but the interface is only slightly
 > >loaded. It got stuck very rarely. Since I can't reproduce this, I don't 
 > >know
 > >whether it's fixed.
 > >
 > >vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xa000-0xa0ff mem
 > >0xf0000000-0xf00000ff at device 18.0 on pci0
 > >vr0: Quirks: 0x0
 > >vr0: Revision: 0x74
 > >miibus0: <MII bus> on vr0
 > >vr0: Ethernet address: 00:0e:a6:40:3f:d0
 > >vr0: [ITHREAD]
 > >
 > >Works fine so far.
 > 
 > 

Sorry for late reply.
I just returned from lunar New Year holiday.

 > Still seeing some "Forced Reset", although at a slightly lower 
 > rate.  The rx shutdown error is new however.
 > 
 > vr0: vr_stop: Rx shutdown error
 > vr0: vr_stop: Rx shutdown error

These messages are printed from vr_stop() which is called
to stop the operation of the NIC. By any chance do you perodically
stop and restart the interface? 

 > vr0: Using force reset command.
 > 

This message comes from vr_reset() which is always executed first
in vr_init_locked(). Don't know why soft reset does not work under
certain conditions. Datasheet for Rhine III(VT6105M, VT6105LOM)
says nothing about it. I guess you can ignore it unless this
message and above messages are continuously printed on your
console.

 > This is RELENG_7 from this morning
 > 
 > 
 > vr0: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe100-0xe1ff mem 
 > 0xa0004000-0xa00040ff irq 11 at device 6.0 on pci0
 > vr0: Quirks: 0x6
 > vr0: Revision: 0x96
 > miibus0: <MII bus> on vr0
 > ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
 > ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > vr0: Ethernet address: 00:00:24:c9:34:88
 > vr0: [ITHREAD]
 > vr1: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe200-0xe2ff mem 
 > 0xa0004100-0xa00041ff irq 5 at device 7.0 on pci0
 > vr1: Quirks: 0x6
 > vr1: Revision: 0x96
 > miibus1: <MII bus> on vr1
 > ukphy1: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
 > ukphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > vr1: Ethernet address: 00:00:24:c9:34:89
 > vr1: [ITHREAD]
 > vr2: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe300-0xe3ff mem 
 > 0xa0004200-0xa00042ff irq 9 at device 8.0 on pci0
 > vr2: Quirks: 0x6
 > vr2: Revision: 0x96
 > miibus2: <MII bus> on vr2
 > ukphy2: <Generic IEEE 802.3u media interface> PHY 1 on miibus2
 > ukphy2:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
 > vr2: Ethernet address: 00:00:24:c9:34:8a
 > vr2: [ITHREAD]
 > vr3: <VIA VT6105M Rhine III 10/100BaseTX> port 0xe400-0xe4ff mem 
 > 0xa0004300-0xa00043ff irq 12 at device 9.0 on pci0
 > vr3: Quirks: 0x6
 > vr3: Revision: 0x96
 > 
 > 
 >         ---Mike 
 > 

-- 
Regards,
Pyun YongHyeon
Received on Mon Feb 11 2008 - 04:35:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:27 UTC