Bug 147684 - [nfe] nVidia MCP55 driver blocks IPMI LAN on load
Summary: [nfe] nVidia MCP55 driver blocks IPMI LAN on load
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.0-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Pyun YongHyeon
Depends on:
Reported: 2010-06-08 11:30 UTC by Alex Forencich
Modified: 2018-05-28 19:48 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alex Forencich 2010-06-08 11:30:02 UTC
Running on a dual AMD opteron system, Supermicro H8DME motherboard with
AOC-SIMLC IPMI card.  Card works fine when system is first powered, before
FreeBSD is allowed to start.  Also works fine under solaris, as the cards
were accessible when solaris was running on the system in question before
I decided to switch to FreeBSD.  As soon as FreeBSD starts, the IPMI card
is no longer accessible over the internal nVidia MCP55 NIC.  The card is
visible to ipmitool after FreeBSD starts, and it shows the IP address that
it should be responding to in the output of 'ipmitool lan print 1'.  Before
you ask, it is NOT an IP address conflict.  Since this bug renders the IPMI
card completely useless for all remote management procedures, I have marked

I found a fix that looked promising that involved placing hw.bge.allow
asf in /boot/loader.conf, but that fix is only for broadcom (em) cards
and my card is an nvidia (nfe) card.


None known at this time.  Only fix to get IPMI card accessible over network
again is to completely remove power from computer.  However, once FreeBSD
starts, the card is once again rendered utterly useless.
How-To-Repeat: Plug in network and power, don't allow server to start, wait for IPMI card
to start.  Ping the card (success).  Log in to IPMI card over network.
Power on server via IPMI web interface or via front panel.  Once FreeBSD
starts, try connecting to IMPI card again - connection times out.  Pinging
the card now fails.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-06-09 01:19:24 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-net

Over to maintainer(s).
Comment 2 Andre Oppermann freebsd_committer 2010-08-23 15:31:33 UTC
Responsible Changed
From-To: freebsd-net->yongari

Over to expert
Comment 3 Pyun YongHyeon freebsd_committer 2010-10-26 00:31:27 UTC
State Changed
From-To: open->feedback

So far NVIDIA didn't release any data sheet for MCP controllers to 
open source developers. If you see SVN/CVS logs of nfe(4) how the 
driver was written you would be surprised with its history. The 
driver is fruit of many BSD developers hard work and came from 
numerous trial and errors. Ironically the driver is actually much 
more stable than vendor's broken binary blob. It's shame that 
NVIDIA still does not release data sheet for their controller. All 
major ethernet controller vendors opened it and they even actively 
maintain/support their driver. 

The IPMI is one of area that is not covered by nfe(4). It seems 
Linux has some support code but I'm not sure how well it works. If 
Linux can successfully use IPMI we can guess required register 
access patterns to make IPMI work MCP55. So would you boot off 
Linux LiveCD and see whether it works? If it works, I'm willing to 
start working on it. Because I don't have the hardware in question 
I need remote hardware access. Please see the following URL and let 
me know your opinions. 
Comment 4 Pyun YongHyeon freebsd_committer 2011-01-20 02:57:33 UTC
State Changed
From-To: feedback->suspended

Feedback timeout. 
Put it into suspended until I get access to the controller.
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:48:48 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
- Untouched since 2018-01-01.
- Affects Base System OR Documentation


Reset to open status.

I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.