BCM57780 Network Adapter Link Lights - Pfsense 2.0.3 (8.1 release)

B

bishoptf

I have been building a few HP thin clients (HP t5720, t5730 and t5740) and turning them into pfSense routers. I like the form factor and performance while being light on the power usage. I have a new batch of thin clients HP t5740 that I was loading up and I noticed one odd thing, I usually have the built-in NIC be the WAN port and on this new group when the WAN configuration is coming up it turns off the link lights, both of them, link and activity.

The card appears to be a BCM57780 card and from what I can tell is functional, pulls a DHCP address and I can ping and move data, ifconfig shows that it is active and up. The only issue is the link light and activity light they are both out, they work up to the point that the interface comes up then they go out.

I have tried the latest version of pfSense 2.1 (based on 8.3) but it exhibits the same symptom, I was going to try a FreeBSD livecd but have not had the chance yet to test it.

I'm a Linux guy so I have to learn the commands to do stuff, but if anyone has any suggestions that might get the lights back on that would be great, I have posted to the pfSense forums and Broadcom and have not found an answer yet, thanks. :)
 
SirDice said:
[thread=7290]PC-BSD, DesktopBSD, FreeNAS, NAS4Free, m0N0WALL, pfSense, ArchBSD, kFreeBSD topics[/thread]

Also, FreeBSD 8.1 has been end-of-life since July 2012 and is not supported any more.

http://www.freebsd.org/security/unsupported.html
Click to expand...

I thought I put in my original post that I have posted both to the pfSense forums and Broadcom forums, both have yielded no additional information. I am just looking for any additional help that might allow me to get the lights working, I also stated that this is not working in the pfSense 2.1 release candidate which is based on freebsd FreeBSD 8.3-RELEASE-p5.

I would assume that maybe my best tact would be to try live CD and see if it experiences the same issue and then open a bug against an upstream version.

I was just hoping that there was some commands that would just turn the lights on, since everything else appears to be working.
 
bishoptf said:
I was just hoping that there was some commands that would just turn the lights on, since everything else appears to be working.
Click to expand...
As far as I know those LEDs are controlled by the hardware. I think you're only able to read the status but not set them.

As I understood it the link LED is off even though there's an active connection? I do have a switch (the network kind) that has a switch (the physical on/off kind) to turn the link and activity LEDs completely on or off. A power-saving feature I guess. Maybe these have something similar that can be controlled via the driver?
 
SirDice said:
As far as I know those LEDs are controlled by the hardware. I think you're only able to read the status but not set them.

As I understood it the link LED is off even though there's an active connection? I do have a switch (the network kind) that has a switch (the physical on/off kind) to turn the link and activity LEDs completely on or off. A power-saving feature I guess. Maybe these have something similar that can be controlled via the driver?
Click to expand...

The connection is active when booting, link and activity lights are lit and correct for connection type, in this case gigabit. When the link is configured and is brought up both lights go out, activity and link, no lights are on at all. However the link appears to be fully operational, at least from my limited testing, it pulls an DHCP address, pings and appears to pass traffic, ifconfig shows the connection up and active.

I was also guessing power saving since when I shut down after running the link light will come on in a solid amber state, no activity light just the link light. If I pull the power and reset it then it will light the link and activity lights like I would normally think it should work.

I was hoping if it was something like a powersaving feature then there might be some /switches that I might be able to tweak to enable them again. If not what is the proper way to notify upstream, after of course testing later versions.
 
bishoptf said:
I was hoping if it was something like a powersaving feature then there might be some /switches that I might be able to tweak to enable them again.
Click to expand...
If there are any they're most likely a sysctl(8). I couldn't find any on my system but then again I don't have interfaces that have that behaviour.

If not what is the proper way to notify upstream, after of course testing later versions.
Click to expand...
In that case please submit a PR. If you submit a PR make sure you tested it with a full FreeBSD. PfSense may have tweaked some bits we don't know about.
 
SirDice said:
If there are any they're most likely a sysctl(8). I couldn't find any on my system but then again I don't have interfaces that have that behaviour.


In that case please submit a PR. If you submit a PR make sure you tested it with a full FreeBSD. PfSense may have tweaked some bits we don't know about.
Click to expand...

Thanks, I was intending to test on a newer FreeBSD version, which would be the better choice 8.4 or 9.1?

Being new to FreeBSD I am not sure I understand the different tracks so I need to read up on that also.
 
bishoptf said:
Thanks, I was intending to test on a newer FreeBSD version, which would be the better choice 8.4 or 9.1?
Click to expand...
Both would be much appreciated but either one would do.

Being new to FreeBSD I am not sure I understand the different tracks so I need to read up on that also.
Click to expand...

Yes, that can be tricky at first. -CURRENT is where it all happens right now, new stuff gets tested, new functionality, features, redesigns, that sort of thing. At some point a new X.0-RELEASE is made from that. This also produces a new X-STABLE (maybe the -STABLE comes before -RELEASE but you get the idea). New features and bug fixes are added to -STABLE while keeping the ABI stable (hence the name). At certain points an X.Y-RELEASE is made from the X-STABLE. Every X.Y-RELEASE is supported with security patches (-p1, -p2, etc) for about two years except .0 which expires as soon as .1 becomes available.
 
yongari@ said:
Recently I fixed the non-working traffic LED on BCM57780. The fix would be available with the upcoming 9.2-RELEASE. Note, I didn't merge the change to stable/9 or stable/8 yet. But I guess you can manually apply the patch from the following URL: http://svnweb.freebsd.org/base/head/sys/dev/bge/if_bge.c?r1=251733&r2=252227
Click to expand...

Awesome I never got around to opening a PR but was on my to-do list, now I just need to figure out how to get the patch into the pfSense development team hands, thanks again. :)
 
yongari@ said:
Recently I fixed the non-working traffic LED on BCM57780. The fix would be available with the upcoming 9.2-RELEASE. Note, I didn't merge the change to stable/9 or stable/8 yet. But I guess you can manually apply the patch from the following URL: http://svnweb.freebsd.org/base/head/sys/dev/bge/if_bge.c?r1=251733&r2=252227
Click to expand...

I’ve opened a bug with patch in pfSense tools’ bugtracker but it looks like I’ll have to push for an MFC in FreeBSD as the bug isn’t moving along :|

Opened a PR here a while back: http://freebsd.org/cgi/query-pr.cgi?pr=180948
 
You must log in or register to reply here.
Back
Top