pyunyh at gmail.com
Mon Feb 11 05:35:47 UTC 2008
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
> >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
> 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
More information about the freebsd-current