Date: Thu, 6 Mar 2008 10:09:50 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Phil Oleson <oz@nixil.net> Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) Message-ID: <20080306010950.GA87113@cdnetworks.co.kr> In-Reply-To: <47CE271A.9080209@nixil.net> References: <20080217112104.X80805@fledge.watson.org> <200803011655.m21GtcMU078673@lava.sentex.ca> <20080303013142.GE72895@cdnetworks.co.kr> <200803031010.28087.freebsd-current@dino.sk> <20080303104140.GA74947@cdnetworks.co.kr> <47CC2F0F.2000808@nixil.net> <20080304023108.GA78525@cdnetworks.co.kr> <47CE271A.9080209@nixil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Tue, Mar 04, 2008 at 09:52:42PM -0700, Phil Oleson wrote:
> 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'
Ah...I think this is regression. Please try attached patch.
Thanks for testing!
>
> 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..
>
This version was broken, your ethernet hardware address is wrong.
> 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..
>
I have to think again what can be done for memory mapped access.
after committing working version.
Thanks for testing.
--
Regards,
Pyun YongHyeon
--envbJBWh7q8WU6mo
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="vr.link.patch"
--- if_vr.c.orig 2008-03-06 10:02:05.000000000 +0900
+++ if_vr.c 2008-03-06 10:01:29.000000000 +0900
@@ -1995,6 +1995,7 @@
{
struct ifnet *ifp;
struct mii_data *mii;
+ struct mii_softc *miisc;
bus_addr_t addr;
int i;
@@ -2102,6 +2103,12 @@
CSR_WRITE_2(sc, VR_MII_IMR, 0);
sc->vr_link = 0;
+ /*
+ * It seems that some revisions require PHY reset to
+ * establish valid link with link partner.
+ */
+ LIST_FOREACH(miisc, &mii->mii_phys, mii_list)
+ mii_phy_reset(miisc);
mii_mediachg(mii);
ifp->if_drv_flags |= IFF_DRV_RUNNING;
--envbJBWh7q8WU6mo--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080306010950.GA87113>