Date: Tue, 4 Mar 2008 11:31:09 +0900 From: Pyun YongHyeon <pyunyh@gmail.com> To: Phil Oleson <oz@nixil.net> Cc: freebsd-current@freebsd.org, Milan Obuch <freebsd-current@dino.sk> Subject: Re: CFT: vr(4) Message-ID: <20080304023108.GA78525@cdnetworks.co.kr> In-Reply-To: <47CC2F0F.2000808@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- Regards, Pyun YongHyeon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080304023108.GA78525>