DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD Installation and Upgrading

FreeBSD Installation and Upgrading Installing and upgrading FreeBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 23rd June 2009
hansivers hansivers is offline
Real Name: Hans Ivers
Port Guard
 
Join Date: Jun 2008
Location: Quebec City, Canada
Posts: 20
Thanked 0 Times in 0 Posts
Default How to investigate non-working onboard lan?

Hi everybody,

For the last 10 days, I've investigated (part-time!) why the onboard lan ports of my main file server have stop working. I'm now completely clueless so any suggestions about new strategies to resolve this puzzling problem will be sincerly welcome..

PROBLEM


Mainboard : MSI K8D Master3-FA4R, with two Gigabit Onboard Lan (Broadcom BCM5704C LAN controller,
64-bit/100MHz PCI-X bus, Dual ports)
http://www.msicomputer.com/product/p...D_Master3-FA4R

The lan ports were working perfectly in the initial setup (tower case). I've moved this board to a new rackmount case and reinstall FreeBSD 7.1 (lan driver = bge). The onboard lan stopped working from that moment. Specifically, the green light on the port is on, suggesting connectivity,but there is no blinking.
I'm able to ping 127.0.0.1 and the onboard lan port IP (192.168.1.150) but not the router or any computers on this subnet.

INVESTIGATIONS

- The ethernet cable has been checked and is working perfectly
- The router and the switch are working perfectly
- When I plug a PCI LAN card (driver = dc) and configure it, everything is working as expected.
This finding pretty ruled out problems of cable, switch, freebsd network settings (resolv.conf, etc.)
- I've removed all PCI cards = not working (no conflict with PCI attributed to onboard lan)
- I've boot with ACPI enabled or disabled = not working
- I've moved cable and networking settings (rc.conf) to the second onboard lan port = not working (the problem is with BOTH lan ports)
- I've powered off for 12hrs the motherboard to clear any data left in RAM/ROM = not working
- I've boot the server with a live Linux rescue CD = onboard lan still not working

QUESTIONS

At this point, my hypothesis is that there is a hardware problem with the Broadcom controller, not the ports.
However, if the controller has been damaged when the motherboard was moved between cases,
why is it detected at boot time and i'm able to ping it (127.0.0.1 and its IP)?

- So, any ideas/hypotheses about what happened to the onboard lan?
- Any suggestions for further investigations to help me find a solution to this puzzling problem?

FREEBSD SETTINGS

Code:
$ uname -a
FreeBSD MYBOX.MYDOMAIN.ORG 7.1-RELEASE-p6 FreeBSD 7.1-RELEASE-p6 #0: Tue Jun  9 16:26:47 UTC 2009
root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

$ ifconfig -a
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:11:09:15:1c:14
        inet 192.168.1.150 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
bge1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
        ether 00:11:09:15:1c:ba
        media: Ethernet autoselect (none)
        status: no carrier
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST,NEEDSGIANT> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000

$ netstat -i
Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll
bge0   1500 <Link#1>      00:11:09:15:1c:14       22 1048576        0 1048576     0
bge0   1500 192.168.1.0   hserver                 22     -       25     -     -
bge1*  1500 <Link#2>      00:11:09:15:1c:ba        0     0        0     0     0
plip0  1500 <Link#3>                               0     0        0     0     0
lo0   16384 <Link#4>                               8     0        8     0     0
lo0   16384 fe80:4::1     fe80:4::1                0     -        0     -     -
lo0   16384 localhost     ::1                      4     -        4     -     -
lo0   16384 your-net      localhost                4     -        4     -     -

$ pciconf -lv
bge0@pci0:3:2:0:	class=0x020000 card=0x16101462 chip=0x164814e4 rev=0x03 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'BCM5704 NetXtreme Dual Gigabit Adapter'
    class      = network
    subclass   = ethernet
bge1@pci0:3:2:1:	class=0x020000 card=0x16101462 chip=0x164814e4 rev=0x03 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'BCM5704 NetXtreme Dual Gigabit Adapter'
    class      = network
    subclass   = ethernet

$ dmesg (short version. See attachment for the complete version)
bge0: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x2003>
mem 0xfe010000-0xfe01ffff,0xfe000000-0xfe00ffff irq 29 at device 2.0 on pci3
miibus0: <MII bus> on bge0
brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge0: Ethernet address: 00:11:09:15:1c:14
bge0: [ITHREAD]
bge1: <Broadcom NetXtreme Gigabit Ethernet Controller, ASIC rev. 0x2003> 
mem 0xfe030000-0xfe03ffff,0xfe020000-0xfe02ffff irq 30 at device 2.1 on pci3
miibus1: <MII bus> on bge1
brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge1: Ethernet address: 00:11:09:15:1c:ba
bge1: [ITHREAD]
bge0: link state changed to UP
bge1: link state changed to DOWN
Attached Files
File Type: txt dmesg.txt (6.3 KB, 10 views)
Reply With Quote
  #2   (View Single Post)  
Old 23rd June 2009
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,135
Thanked 182 Times in 149 Posts
Default

You can ping 127.0.0.1 even when there is no NIC, or when not connected to a switch/router. Being able to ping the IP address is also not a reliable indicator because 'lo0', 127.0.0.1 is the interface being used.

I would try a longer network cable.
You also could run tcpdump which puts the NIC into promiscuous mode, and see whether that makes a difference.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 23rd June 2009
DrJ DrJ is offline
ISO Quartermaster
 
Join Date: Apr 2008
Location: Gold Country, CA
Posts: 506
Thanked 39 Times in 39 Posts
Default

This may be a long shot, but have you updated your kernel and world a few times without using mergemaster?

I was sloppy with updating for a while, and some of the files were not changed (i.e., no mergemaster). After some cycles of this, my em interface stopped working. It was no big deal, since the board also has an fxp on it.

Later, when I updated more carefully, lo! and behold! em started working again.

Moral: use of mergemaster is strongly recommended.
Reply With Quote
  #4   (View Single Post)  
Old 24th June 2009
hansivers hansivers is offline
Real Name: Hans Ivers
Port Guard
 
Join Date: Jun 2008
Location: Quebec City, Canada
Posts: 20
Thanked 0 Times in 0 Posts
Default

@J65nko :

My testing included a 6' and a 50' ethernet CAT5 cables, which were carefully checked with a cable tester before testing.

I'm not familiar with TCPDUMP. What kind of errors should I search for?

@DrJ :

It a fresh new 7.1 installation, followed by a binary freebsd-update to the latest standard kernel.
Reply With Quote
  #5   (View Single Post)  
Old 24th June 2009
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,135
Thanked 182 Times in 149 Posts
Default

RE:tcpdump
You don't have to look for errors. tcpdump configures the NIC to be in promiscuous mode. See http://en.wikipedia.org/wiki/Promiscuous_mode

I once tested a FreeBSD snapshot, and had connectivity problems with the 're' NIC . To diagnose the issue I ran tcpdump on that 're' NIC''. Mysteriously with tcpdump running, the connectivity problems (no working arp) went away..
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #6   (View Single Post)  
Old 24th June 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

I have some ideas..
  • Try bringing the interface up: % sudo ifconfig bge0 up
  • Switch over to the presumably unused bge1 interface, i.e: physically disconnect the cable and try the other port.
  • Use a different cable, as instructed by J65nko.. it may be of poor quality.
  • Upgrade to a newer version of FreeBSD, like 7.2 perhaps.
I hope that helps..
Reply With Quote
  #7   (View Single Post)  
Old 26th June 2009
fbsduser fbsduser is offline
Shell Scout
 
Join Date: Aug 2008
Posts: 103
Thanked 4 Times in 4 Posts
Default

One thing you probably overlooked is that the OP tried a linux liveCD and the NIC didn't work neither. This rules out configuration issues and makes it clear that the onboard NIC passed out.
Reply With Quote
  #8   (View Single Post)  
Old 28th June 2009
robbak's Avatar
robbak robbak is offline
Real Name: Robert Backhaus
VPN Cryptographer
 
Join Date: May 2008
Location: North Queensland, Australia
Posts: 366
Thanked 40 Times in 39 Posts
Default

You didn't mention whether you had looked into your bios settings - Onboard ethernet interfaces can be turned off in the BIOS. No idea how this might happen accidentally, though.
Unless you have important customised BIOS settings, reset the CMOS using the jumper.

Also, make sure you don't have an unused metal motherboard support shorting something out on the underside of the motherboard. I've seen it done....
__________________
The only dumb question is a question not asked.
The only dumb answer is an answer not given.
Reply With Quote
  #9   (View Single Post)  
Old 28th June 2009
Carpetsmoker's Avatar
Carpetsmoker Carpetsmoker is offline
Real Name: Martin
Old man from scene 24
 
Join Date: Apr 2008
Location: Eindhoven, Netherlands
Posts: 2,062
Thanked 198 Times in 156 Posts
Default

If the NIC (Or any other device) is turned of in the BIOS then it would be like the device doesn't even exist as far as the OS is concerned, the driver would not load, nothing would show up with pciconf.

Two possibilities first come to my mind:
o The board is placed incorrectly and short-circuiting somewhere, common reason is a spacer in the wrong place or some casings that use very wide spacers don't work with all boards.
o The NIC broke.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Reply With Quote
Old 28th June 2009
BSDfan666 BSDfan666 is offline
Real Name: N/A, this is the interweb.
Helpful companion
 
Join Date: Apr 2008
Location: Ontario, Canada
Posts: 2,223
Thanked 193 Times in 184 Posts
Default

It could even be silicon error, solar flares.. stellar alignment.. gremlins.. all possible causes of hardware failure.

Or you could have shorted something accidentally, perahps some sort of power surge left things in an inconsistent state.. like the devices firmware may have been corrupted somehow.

Either way, this is just a guessing game.. if you've tried switching cables.. trying other OS's.. then the issue is most likely hardware related.

Consider going into the BIOS, disabling Ethernet.. and obtaining a replacement PCI/PCI-E card.

Good luck.
Reply With Quote
Old 28th June 2009
hansivers hansivers is offline
Real Name: Hans Ivers
Port Guard
 
Join Date: Jun 2008
Location: Quebec City, Canada
Posts: 20
Thanked 0 Times in 0 Posts
Default

Hi guys,

I really appreciate your suggestions!

I've already checked the BIOS settings and the onboard lan is enabled. In fact, as part of my testing, I've resetted BIOS to default values, without any success.

The only new information came from a utility called Broadcom Networking Boot Utility, which appears after BIOS boot. I entered this utility and there is a command (CTRL-F6) which enable LAN blicking. When activated, I noticed that only the second lan port (bge1) is blinking (no change whether cable is plugged in the first or second lan port).

I must admit this issue _really_ looks as a hardware problem and, as BSDFan666 suggested, I'm on the verge of disabling onboard lan and buying a PCI dual port lan card for server on Ebay.

The only testing left is a careful inspection of the motherboard for short circuit... No real hope there of finding a satisfactory solution!

Thanks again for your time and suggestions..
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Working with CVS? Zmyrgel OpenBSD General 15 6th October 2009 01:32 PM
x11 forwarding over ssh not working kasse OpenBSD General 14 23rd December 2008 02:21 PM
Intel ATOM D945GCLF onboard LAN driver-card problem mona FreeBSD Installation and Upgrading 7 17th December 2008 04:50 PM
USB not working after suspend stukov Other BSD and UNIX/UNIX-like 5 11th August 2008 06:48 PM
Crontab not working beandip FreeBSD General 6 6th August 2008 08:33 PM


All times are GMT. The time now is 12:30 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick