From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 05:59:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 29A58E99 for ; Thu, 17 Oct 2013 05:59:48 +0000 (UTC) (envelope-from universite@ukr.net) Received: from otrada.od.ua (universite-1-pt.tunnel.tserv24.sto1.ipv6.he.net [IPv6:2001:470:27:140::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73456240A for ; Thu, 17 Oct 2013 05:59:47 +0000 (UTC) Received: from [10.0.0.10] ([10.0.0.10]) (authenticated bits=0) by otrada.od.ua (8.14.4/8.14.5) with ESMTP id r9H5xf5V015667 for ; Thu, 17 Oct 2013 08:59:42 +0300 (EEST) (envelope-from universite@ukr.net) Message-ID: <525F7CC9.4000800@ukr.net> Date: Thu, 17 Oct 2013 08:59:37 +0300 From: "Vladislav V. Prodan" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: bce(4) on the Dell PE 2950 References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> In-Reply-To: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (otrada.od.ua [89.209.81.54]); Thu, 17 Oct 2013 08:59:42 +0300 (EEST) X-Spam-Status: No, score=-101.0 required=5.0 tests=ALL_TRUSTED, FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL, USER_IN_WHITELIST autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mary-teresa.otrada.od.ua X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 05:59:48 -0000 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