From owner-freebsd-current@FreeBSD.ORG Tue Mar 4 02:31:18 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 81D1F106566B for ; Tue, 4 Mar 2008 02:31:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 401EA8FC17 for ; Tue, 4 Mar 2008 02:31:18 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by an-out-0708.google.com with SMTP id c14so134433anc.13 for ; Mon, 03 Mar 2008 18:31:17 -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=G1DO5qFzjto2CA/toxMpWjeZJ7rRFRy5HyVeHWPoBGE=; b=LSZpStgshizcfO3PZXk2HQeg9NIFz92i+QNGEv8miCN2dZoSG9oJ+Qva/xr1wENx/q2S00LRbpTxD6G2PDFBM4sd2BvFLNqJ9LmlR43QGLs0G+gfAHbM9sb2A3LhKkIkeZyddch/gnqMWDVGg/Z6hViHOA3ZeaZL/MP1C+9XVPo= 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=W2Z5nBeb6E53yYSYdeK1LqWcW3PfSKNEKqjp3dgjj9iwUsZ7ylGMXgd+NXtQtyorzSNwsvFObYrz4X2Pt4z6yp/4wCCtPTc1o1T/4TXq/AcY69ptnmZn7WnKrZkVx51wmOOUuxhf7UVqewv9kZorrFoLtzWXqLHzvbHUWpHFPbI= Received: by 10.100.13.2 with SMTP id 2mr886742anm.29.1204597877303; Mon, 03 Mar 2008 18:31:17 -0800 (PST) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.google.com with ESMTPS id i51sm1697400rne.7.2008.03.03.18.31.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Mar 2008 18:31:16 -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 m242VAeJ078546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Mar 2008 11:31:10 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id m242V9d3078545; Tue, 4 Mar 2008 11:31:09 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 4 Mar 2008 11:31:09 +0900 From: Pyun YongHyeon To: Phil Oleson Message-ID: <20080304023108.GA78525@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47CC2F0F.2000808@nixil.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Milan Obuch 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: Tue, 04 Mar 2008 02:31:18 -0000 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. -- Regards, Pyun YongHyeon