From owner-freebsd-net@FreeBSD.ORG Tue Oct 11 22:51:26 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E272106564A; Tue, 11 Oct 2011 22:51:26 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 61A738FC08; Tue, 11 Oct 2011 22:51:24 +0000 (UTC) Received: by wwe3 with SMTP id 3so126935wwe.31 for ; Tue, 11 Oct 2011 15:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=3gdZtiuUzw4LMhUxivperYXApxgW/5yhzz3npcC1wns=; b=DP0ygX1nqrMypLVxwn4/K4IhxKcuisVdyEtIJlSKMNP8cbbCmwcle+OTf4cWmdLFr/ 9CXSarYjjjazIo2amjk3mTMSOQXdQmskMOJ2QviPexgeOABhz7PLa855EOQfhjAkzuNv +qm3LfXAZ3bIDmGI7SkD6tLUhmK1oXJo3IZXs= Received: by 10.216.133.160 with SMTP id q32mr1447983wei.108.1318373482995; Tue, 11 Oct 2011 15:51:22 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id j18sm244052wbo.6.2011.10.11.15.51.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 11 Oct 2011 15:51:21 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 11 Oct 2011 15:49:35 -0700 From: YongHyeon PYUN Date: Tue, 11 Oct 2011 15:49:35 -0700 To: Sean Bruno Message-ID: <20111011224935.GC5661@michelle.cdnetworks.com> References: <1318264942.1236.6.camel@hitfishpass-lx.corp.yahoo.com> <20111010174749.GA1781@michelle.cdnetworks.com> <1318271046.1236.11.camel@hitfishpass-lx.corp.yahoo.com> <20111010190609.GB1781@michelle.cdnetworks.com> <1318278905.1236.18.camel@hitfishpass-lx.corp.yahoo.com> <20111010204456.GD1781@michelle.cdnetworks.com> <5D267A3F22FD854F8F48B3D2B523819385F3669A7D@IRVEXCHCCR01.corp.ad.broadcom.com> <1318356030.2724.11.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , David Christensen , "davidch@freebsd.org" , Pyun YongHyeon Subject: Re: bce(4) with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 22:51:26 -0000 On Tue, Oct 11, 2011 at 12:52:25PM -0700, Sean Bruno wrote: > > > > > The Broadcom MFW is configured to load/not load through an NVRAM > > > > option that is likely not affected by the iDRAC BIOS settings. > > > > To disable MFW you'd need to run the user diagnostic utility > > > > (UXDIAG.EXE) with the following command line: > > > > > > > > C:\>uxdiag -mfw 0 > > > > > > > > To turn it back on run the following: > > > > > > > > C:\>uxdiag -mfw 1 > > > > > > > > You can find a bootable CD with the user diagnostic here: > > > > http://www.broadcom.com/support/license.php?file=NXII/Xdiag-5.2.2.iso > > > > > > > > Dave > > > > > > > > > > Ah, ok. > > > > > > > > > Pyun: > > > > > > Should I do this on a host and validate your changes? > > > > > > > That would be great if you can. Because some part of code is not > > executed in my patch when firmware is not running. Previously > > bce(4) executed that code regardless of firmware running state. > > > > > Sean > > > > > > > > > Ran this on my Dell R410. I can clearly see that the tool is > "disabling" the MFW bit, and that the dell bios interface to the IPMI > controller/DRAC is impaired, however ... > > The system still thinks that the MFW bit is "ON" and proceeds normally > in this case. The code still fails to detect that MFW is disabled. > > In addition, the IPMI driver attaches to "something" and I can poke at > it via ipmitool. So, from the driver perspective, the attempt to detect > MFW enabled doesn't work as the chipset still thinks that its "on". > My patch relied on existing bce(4)'s logic for management firmware state since public data sheet does not mention anything about that. Probably David can give us more information. > I've commented out the code block that we're trying to work around in > the yahoo code base for now. > > Sean >