Date: Wed, 13 Jan 2010 11:28:55 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Oliver Fromme <olli@lurza.secnetix.de> Cc: freebsd-current@freebsd.org Subject: Re: bge(4), 5715S, IBM BladeCenter, no carrier Message-ID: <20100113192855.GN1228@michelle.cdnetworks.com> In-Reply-To: <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> References: <a78074951001131045r62e72a82ncae9ad4dba0a90a@mail.gmail.com> <201001131902.o0DJ2AKQ013145@lurza.secnetix.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <olli@lurza.secnetix.de> wrote: > > > [...] > > > Excerpt from dmesg -v: > > > > > > bge0: <Broadcom NetXtreme Gigabit Fiber Controller, ASIC rev. 0x009003> 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: <MII bus> on bge0 > brgphy0: <BCM5714 10/100/1000baseTX PHY> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100113192855.GN1228>