Re: CFT: vr(4)

Pyun YongHyeon wrote:
> On Mon, Mar 03, 2008 at 10:02:07AM -0700, Phil Oleson wrote:
>  > Pyun YongHyeon wrote:
>  > >On Mon, Mar 03, 2008 at 10:10:25AM +0100, Milan Obuch wrote:
>  > > > 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
>  > > > 
>  > >
>  > >Hmm, this is interesting. 6105M datasheet said nothing what can be
>  > >done for this case. I guess this kind of error can come from
>  > >improperly seated NICs or broken hardware. Would you re-seat the NIC
>  > >or change PCI slot and try again with attached patch?
>  > >
>  > > > 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...
>  > > > 
>  > >
>  > >Yes, I really like to fix it too.
>  > >
>  > 
>  > Hey.. unfortunately I have to chime in too.. (with a failure)
>  > Last night I was running a crusty RELENG_6 from about july of last year.
>  > I had some issues unrelated to this, so I decided to update the system
>  > to check if that resolved those issues (it did - RELENG_6 as of sometime 
>  > last night).  However, vr stopped working.  As I remembered this thread,
>  > I booted to my old kernel, and downloaded the rewrite/patchset for 6
>  > and tried it out.  Unfortunately, It is failing:
>  > 
>  > vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xe800-0xe8ff mem 
>  > 0xe3004000-0xe30040ff irq 10 at device 18.0 on pci0
>  > vr0: Quirks: 0x0
>  > vr0: Revision: 0x70
>  > vr0: phy read timeout 31:1
>  > vr0: MII without any phy!
>  > device_attach: vr0 attach returned 6
>  > 
>  > 
>  > I'm attaching the complete dmesg, and the version of if_vr.c used.. (a 
>  > couple of the smaller patches you suggested I hand applied to reduce the
>  > turnaround time).   Any suggestions would be tested tonight.
>  > 
> 
> It seems that I've made mistake in implementing memory mapped
> register access. Even if datasheet says no special things for
> reloading EEPROM, Rhine family seems to default to io register
> access after reloading EEPROM. I guess this would be root cause of
> Milan Obuch's issue. It seems that his hardware requires memory
> mapped register access but reloading EEPROM disabled it.
> ATM I have no clean idea how can I renable memory mapped register
> access after EEPROM reloading without hacks so I completely backed
> out memory mapped register access and put updated vr(4) to the same
> URL. Please try again updated vr(4) and let me know how it goes.
> 

Okay, some success.. (sorry about the delay in testing.. after a 30 hour 
day I crashed hard last night)

I downloaded both the if_vr.c and if_vr.c.memio and applied the 
if_vr-pyunyh-to-releng6.diff to make it compile on this RELENG_6 box.

if_vr.c:

dmesg.boot:
<snip>
vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xe800-0xe8ff mem 
0xe3004000-0xe30040ff irq 10 at device 18.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x70
miibus0: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
vr0: Ethernet address: 00:50:2c:02:1e:e6
<snip>

#ifconfig
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=8<VLAN_MTU>
         inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255
         ether 00:50:2c:02:1e:e6
         media: Ethernet autoselect (none)
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
         inet6 ::1 prefixlen 128
         inet 127.0.0.1 netmask 0xff000000

#ifconfig vr0 media 100baseTX mediaopt full-duplex

vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=8<VLAN_MTU>
         inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255
         ether 00:50:2c:02:1e:e6
         media: Ethernet 100baseTX <full-duplex>
         status: active

went from 'status: no carrier' to 'status: active'

not sure why it's not autonegotiating...
---------

if_vr.c.memio   (tried it for a chuckle as it had differences from the 
revision I tried the other day).

dmesg.boot:
<snip>
vr0: <VIA VT6102 Rhine II 10/100BaseTX> port 0xe800-0xe8ff mem 
0xe3004000-0xe300
40ff irq 10 at device 18.0 on pci0
vr0: Quirks: 0x0
vr0: Revision: 0x70
miibus0: <MII bus> on vr0
ukphy0: <Generic IEEE 802.3u media interface> on miibus0
ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
<snip>

better...

#ifconfig
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=8<VLAN_MTU>
         inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255
         ether 00:00:00:00:00:00
         media: Ethernet autoselect (none)

not sure why the mac address is nulled out..

home# ifconfig vr0 media 100baseTX mediaopt full-duplex
home# ifconfig
vr0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
         options=8<VLAN_MTU>
         inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255
         ether 00:00:00:00:00:00
         media: Ethernet 100baseTX <full-duplex>
         status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
         inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
         inet6 ::1 prefixlen 128
         inet 127.0.0.1 netmask 0xff000000

home# ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1): 56 data bytes
ping: sendto: Host is down
64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=15.448 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.039 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.929 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.018 ms



so.. it's working.. tried pinging yahoo.com and that was working too..
so the memio version is progressing for my hardware..


	-Phil.