bge(4), 5715S, IBM BladeCenter, no carrier

[Pyun YongHyeon]

On Thu, Jan 14, 2010 at 05:04:31PM +0100, Oliver Fromme wrote:
> Pyun YongHyeon wrote:
>  > 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:
>  > > > 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.
> 
> You were right, it didn't help.
> 
>  > > 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.
>  > > [...]
>  > > 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?
> 
> Ok, I've got more information.
> 
> As a reminder, this is a 8-stable snapshot from December,
> with if_bge and brgphy from 9-current as of today.
> (In fact I just copied the whole mii directory, not just
> brgphy.)
> 
> The result is that there is no brgphy found at all, so
> devinfo doesn't list it either.
> 
> Next thing I did was to apply the patch from PR 122551
> because the problem description sounds somewhat similar
> to what I have (though not identical).
> 
> The result:  Now a brgphy is found, but it lists only
> copper media, not 1000baseSX.  I'm pretty sure this is
> a fiber PHY, though.  So, still "no carrier".  :-(
> 
> Here's the information you requested (with the patch
> from PR 122551) ...
> 
> devinfo -rv:
> 
>    bge0 pnpinfo vendor=0x14e4 device=0x1679 subvendor=0x1014 subdevice=0x0367 class=0x020000 at slot=4 function=0
>        Interrupt request lines:
>            256
>        I/O memory addresses:
>            0x97a00000-0x97a0ffff
>      miibus0
>        brgphy0 pnpinfo oui=0x818 model=0x34 rev=0x0 at phyno=1
> 
> pciconf -lcv:
> 
> bge0 at pci0:22:4:0: class=0x020000 card=0x03671014 chip=0x167914e4 rev=0xa3 hdr=0x00
>     vendor     = 'Broadcom Corporation'
>     device     = 'NetXtreme 5715S Gigabit Ethernet'
>     class      = network
>     subclass   = ethernet
>     cap 07[40] = PCI-X 64-bit supports 133MHz, 2048 burst read, 1 split transaction
>     cap 01[48] = powerspec 2  supports D0 D3  current D0
>     cap 03[50] = VPD
>     cap 05[58] = MSI supports 8 messages, 64 bit enabled with 1 message
> 
> dmesg (verbose boot):
> 
> 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
> miibus0: <MII bus> on bge0
> brgphy0: <BCM5714 10/100/1000baseTX PHY> PHY 1 on miibus0
> brgphy0: OUI 0x000818, model 0x0034, rev. 0
> brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
> bge0: bpf attached
> bge0: Ethernet address: 00:21:5e:4c:07:22
> bge0: [MPSAFE]
> bge0: [ITHREAD]
> 
> ifconfig -m:
> 
> bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> 	options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
> 	capabilities=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
> 	ether 00:21:5e:4c:07:22
> 	inet xx.xx.xx.xx netmask 0xffffff00 broadcast xx.xx.xx.255
> 	media: Ethernet autoselect (none)
> 	status: no carrier
> 	supported media:
> 		media autoselect
> 		media 1000baseT mediaopt full-duplex
> 		media 1000baseT
> 		media 100baseTX mediaopt full-duplex
> 		media 100baseTX
> 		media 10baseT/UTP mediaopt full-duplex
> 		media 10baseT/UTP
> 		media none
> 

Thanks for the information. Would you try attached patch?
If the patch still reports 10/100/1000 copper PHY, try adding
'sc->mii_flags |= MIIF_HAVEFIBER' to force setting MIIF_HAVEFIBER
flag in brgphy.c:brgphy_attach.

> Actually, the blade (its an IBM BladeCenter HS22) contains
> four NICs:  two bge(4) and two bce(4).  All of them are
> fiber (1000baseSX).  None of them work.  I can open a new
> thread for the bce(4) issue, but first I would prefer to
> get the bge(4) interfaces working.
> 

Ok, let's fix bge(4) first.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bge.BCM5715S.diff
Type: text/x-diff
Size: 3189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20100114/d22a1e8f/bge.BCM5715S.bin