Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 13 Jan 2010 11:46:47 -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:  <20100113194647.GO1228@michelle.cdnetworks.com>
In-Reply-To: <20100113192855.GN1228@michelle.cdnetworks.com>
References:  <a78074951001131045r62e72a82ncae9ad4dba0a90a@mail.gmail.com> <201001131902.o0DJ2AKQ013145@lurza.secnetix.de> <20100113192855.GN1228@michelle.cdnetworks.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 13, 2010 at 11:28:55AM -0800, Pyun YongHyeon wrote:
> 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.

Would you show me the output of "devinfo -rv | grep brgphy" and
"pciconf -lcv" for your bge(4) controller?



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100113194647.GO1228>