CFT: vr(4)

[Milan Obuch]

On Monday 03 March 2008, Pyun YongHyeon wrote:
> On Sat, Mar 01, 2008 at 11:53:41AM -0500, Mike Tancsa wrote:
>
> Sorry for late handling. I wanted to solve Milan Obuch's issue first
> before committing vr(4). But it seems that it's not easy to fix
> Milan's issue. :-(
>

Well, I see some progress there... Today I was able to do some tests again, 
and I was able to ping -f another box on the same network for some time. I 
tried then csup sources and I got hard hang, again, this time with following 
lines on console:

vr0: PCI bus error -- resetting
vr0: restarting

And no ability to enter kdb, either.
Just for record, I am getting following when kldload'ing if_vr:

vr0: <VIA VT6105M Rhine III 10/100BaseTX> port 0x9c00-0x9cff mem 
0xfceff000-0xfceff0ff irq 18 at device 8.0 on pci3
vr0: Quirks: 0x6
vr0: Revision: 0x96
miibus1: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus1
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto

(one out of four devices shown)

>  > At 07:30 PM 2/27/2008, Pyun YongHyeon wrote:
>  > >I never thought this kind of testing. It's good to hear vr(4)
>  > >recovers from the abrupt link change events. I guess this also
>  > >indicates the overhauled vr(4) can close lots of PR for vr(4).
>  >
>  > BTW, any chance of these fixes being backported to RELENG_7 and
>  > RELENG_6 ? Its not just media speed changes that causes the nic to
>
> I'm sure I'll MFC the change to RELENG_7 but not sure it could be
> done on RELENG_6 due to lack of spare time.
>

In my eyes, if new vr works for others and no regression was found, it should 
go in. I did not encountered a regression - it did not work with old driver, 
it does not work (yet) with the new... but I hope we can get this one 
working, too...

Milan

-- 
Address this mail is sent from is used only for this mailing list.
Do not send any messages to it directly as a response, reply only
to mailing list. For mail to me personally, use milan in address instead.