From owner-freebsd-current@FreeBSD.ORG Wed Jan 13 19:29:47 2010 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 82ADD1065693 for ; Wed, 13 Jan 2010 19:29:47 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.221.174]) by mx1.freebsd.org (Postfix) with ESMTP id 2342E8FC19 for ; Wed, 13 Jan 2010 19:29:46 +0000 (UTC) Received: by qyk4 with SMTP id 4so10938235qyk.7 for ; Wed, 13 Jan 2010 11:29:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=uoQ6Z7K+eXXtPWM7G35Ki0oXVvH710UjFbIS3TdlaPM=; b=xOUyggV7WijzPl1bE38NgiitgxdcNgmwQu46oewm+5XmFB6W60pWLymtlfRpZrNgYc bp9llRuL9AsNA1m0nP1NtHK8TSlT1TpGioiLlYSeJ5xREkoosPxSKiaUSpXOQFiEYP62 x6yvIUn3t/sTix6nvGmXclGOkRQGc09p9HKSg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aZGnO8JWI0MczwAb2PaKddreB5US3BQtj0gv0pOsc/Qk7St0DB9k/n1CmON5XI+5Lp uM3GmeILXDjU2lAInrmnLTuDqirRCq3mVUuk9pXt8E8ABkoY9znzth6jURDyfh8Z6cdy zYD2amSql5WCFzWdz+5Jr7+Gzs3RS+2qw1xl0= Received: by 10.224.117.145 with SMTP id r17mr1007257qaq.7.1263410977804; Wed, 13 Jan 2010 11:29:37 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 8sm4046335qwj.13.2010.01.13.11.29.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 13 Jan 2010 11:29:36 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 13 Jan 2010 11:28:55 -0800 From: Pyun YongHyeon Date: Wed, 13 Jan 2010 11:28:55 -0800 To: Oliver Fromme Message-ID: <20100113192855.GN1228@michelle.cdnetworks.com> References: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier 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: Wed, 13 Jan 2010 19:29:47 -0000 On Wed, Jan 13, 2010 at 08:02:10PM +0100, Oliver Fromme wrote: > Xin LI wrote: > > On Wed, Jan 13, 2010 at 10:38 AM, Oliver Fromme wrote: > > > [...] > > > Excerpt from dmesg -v: > > > > > > bge0: mem 0x97a00000-0x97a0ffff,0x97a10000-0x97a1ffff irq 24 at device 4.0 on pci22 > > > bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0x97a00000 > > > bge0: attempting to allocate 1 MSI vectors (8 supported) > > > msi: routing MSI IRQ 256 to local APIC 0 vector 56 > > > bge0: using IRQ 256 for MSI > > > bge0: CHIP ID 0x00009003; ASIC REV 0x09; CHIP REV 0x90; PCI-X > > > bge0: bpf attached > > > bge0: Ethernet address: 00:21:5e:4c:07:22 > > > bge0: [MPSAFE] > > > bge0: [ITHREAD] > > > > > > Actually this is an 8-stable snapshot from December, but > > > with if_bge.c and if_bgereg.h from 9-current as of today, > > > because I saw a bunch of commits to HEAD last week. > > > (That's why I'm posting this to -current.) > > > > Which PHY is attached to it? > > > > e.g. dmesg | grep miibus? > > Hmm. Interestingly, I don't see any PHY in the verbose dmesg > output from the 9-current driver. Maybe I should merge the > brgphy driver from 9-current to the 8-stable machine, too. > I'll try that tomorrow. I guess that wouldn't help. > (But shouldn't there be a warning message if bge attaches > without any PHY?) > If bge(4) think it have to directly handle PHY without using mii(4) it wouldn't use mii(4) such that you wouldn't see mii(4) related message. ATM bge(4) directly handles fiber PHYs under certain conditions as em(4) does. em(4) does not use mii(4) at all so that wouldn't be problem on em(4). But bge(4) also uses mii(4) so it only uses mii(4) under certain cases. I don't like that behavior and would like to remove that but it would require a lot of code to properly handle link state changes. I still didn't fully understand the complexity of link state handling used in driver. > In the (non-verbose) output using the 8-stable driver, the > following appears in dmesg: > > miibus0: on bge0 > brgphy0: PHY 1 on miibus0 > brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto > You said controller has fiber PHY, but brgphy(4) incorrectly think it has copper PHY. Maybe this is the real problem. I'll see what can be done.