From owner-freebsd-current@FreeBSD.ORG Thu Mar 6 01:09:59 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A98F1065672 for ; Thu, 6 Mar 2008 01:09:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.238]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2AB8FC15 for ; Thu, 6 Mar 2008 01:09:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by wx-out-0506.google.com with SMTP id i29so2294630wxd.7 for ; Wed, 05 Mar 2008 17:09:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; bh=ZDKZQOVzwH7ynjv9yvy1FMVFbJYz+W8exeYX2plV/vs=; b=Ras0iI2/B9iuP1R5NcFkdd+DU71a/xnHzIrGX/JD40hOm/6z3zT9QF7FlleXR5xVvnKY/YdXX2WSdZySdVjrsNM0iImzOMUjgl3taBD6GEaBBSVeSjR64zT54akVNpEA4gH3QRv/1dQLEIpzmNdXgFC0tn5dtAVTnXe2yegKhyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=uPGSpnnnWG0BK/1BHTfhc+DW1OZvJLRbh+n6/zqmpG/Og543IeYyfJzD6cCsFP9P8b+qr4jVYOtBb9d+UlzbnwtR+Hi97VBLyPCL0ZZkVtq1HsHnRnftSiKmDaNki/2NUeDdz06iDOH6C1zmGq/bLpgj3yDur2Ks1FFDgZtPngw= Received: by 10.100.254.18 with SMTP id b18mr1859736ani.106.1204765798483; Wed, 05 Mar 2008 17:09:58 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id 34sm2545100wra.20.2008.03.05.17.09.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Mar 2008 17:09:57 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id m2619pn0087498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Mar 2008 10:09:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m2619pUC087497; Thu, 6 Mar 2008 10:09:51 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 6 Mar 2008 10:09:50 +0900 From: Pyun YongHyeon To: Phil Oleson Message-ID: <20080306010950.GA87113@cdnetworks.co.kr> 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> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <47CE271A.9080209@nixil.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: CFT: vr(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2008 01:09:59 -0000 --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: port 0x9c00-0x9cff mem > > > > > 0xfceff000-0xfceff0ff irq 18 at device 8.0 on pci3 > > > > > vr0: Quirks: 0x6 > > > > > vr0: Revision: 0x96 > > > > > miibus1: on vr0 > > > > > ukphy0: 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: 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: > > vr0: port 0xe800-0xe8ff mem > 0xe3004000-0xe30040ff irq 10 at device 18.0 on pci0 > vr0: Quirks: 0x0 > vr0: Revision: 0x70 > miibus0: on vr0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > vr0: Ethernet address: 00:50:2c:02:1e:e6 > > > #ifconfig > vr0: flags=8843 mtu 1500 > options=8 > 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 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 mtu 1500 > options=8 > inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:50:2c:02:1e:e6 > media: Ethernet 100baseTX > 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: > > vr0: port 0xe800-0xe8ff mem > 0xe3004000-0xe300 > 40ff irq 10 at device 18.0 on pci0 > vr0: Quirks: 0x0 > vr0: Revision: 0x70 > miibus0: on vr0 > ukphy0: on miibus0 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > > better... > > #ifconfig > vr0: flags=8843 mtu 1500 > options=8 > 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 mtu 1500 > options=8 > inet 192.168.1.69 netmask 0xffffff00 broadcast 192.168.1.255 > ether 00:00:00:00:00:00 > media: Ethernet 100baseTX > status: active > lo0: flags=8049 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--