Date: Thu, 17 Oct 2013 08:59:37 +0300 From: "Vladislav V. Prodan" <universite@ukr.net> To: freebsd-net@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 Message-ID: <525F7CC9.4000800@ukr.net> In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
16.04.2013 21:34, David Christensen wrote: >> | > Specifically, we've seen that newer (9 and higher) have issues with >> | > the doing initial setup and negotiation and that Dell did indeed >> | > release newer firmware to fix the issues. This requires a full >> | > reboot into Linux (probably centos6) to get the update to execute. >> | >> | I could be wrong but I *think* that the firmware is loaded on device >> | initialization, so there may be a chance that the driver can do it >> | when starting? Additionally, maybe one can leverage the kernel >> | firmware(9) framework so that the firmware can be more easily updated >> | by user? > > The 5706/5708/5709/5716 devices have a set of RISC processors. One is > loaded from NVRAM based firmware (MCP) while the others are loaded by > firmware embedded in the driver. The MCP firmware is loaded at device > power-on when the system is plugged into a socket in order to provide > pre-OS access to the system (think Dell DRAC). > I have a DELL PowerEdge 2950 server (3rd generation). There is a network card with chipset bce BCM5708. If a ready algorithm for getting rid of interface resetting / watchdog timeout? Thanks. > There's a chicken and egg problem with your suggestion for firmware(9) > support of the MCP firmware. Not only does MCP firmware provide pre-OS > services but it also provides FreeBSD driver services. There are shared > resources on the device which require synchronization between multiple > FreeBSD driver instances and the MCP acts as an arbitrator for them. > > Additionally, I have some security concerns about making NVRAM write > functionality easily accessible through the driver since it would be fairly > easy to take down a system and require a motherboard swap to fix the > problem. There's always a concern that a power-event could interrupt > an NVRAM upgrade and make the system unusable so I think it's > important to have the system administrator's blessings before making > any NVRAM changes to firmware. Not sure how to accomplish that > without making the driver load process interactive. > -- Vladislav V. Prodan System & Network Administrator http://support.od.ua +380 67 4584408, +380 99 4060508 VVP88-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?525F7CC9.4000800>