Date: Sat, 17 Mar 2012 18:12:30 +0100 From: Paul Guyot <paulguyot@ieee.org> To: pyunyh@gmail.com Cc: freebsd-stable@freebsd.org Subject: Re: Changes brought to bce(4) disabling ipmi access during boot Message-ID: <39F5CD97-A7DF-4815-9F18-507E411844FA@ieee.org> In-Reply-To: <20120318003838.GC1660@michelle.cdnetworks.com> References: <8D3993D8-074E-45E6-8AF7-DB51369F33BD@ieee.org> <20120315171018.GA3295@michelle.cdnetworks.com> <3D1680C7-39A2-47B9-BD40-A987238886EB@ieee.org> <20120316170650.GA6841@michelle.cdnetworks.com> <F6D0F5AE-D31E-42D7-B641-ADDCC39E4169@ieee.org> <20120318003838.GC1660@michelle.cdnetworks.com>
index | next in thread | previous in thread | raw e-mail
Le 18 mars 2012 à 01:38, YongHyeon PYUN a écrit : >> From what I understand, both new conditions that may return early are true ((ifp->if_drv_flags & IFF_DRV_RUNNING) == 0 and later (mii->mii_media_status & IFM_ACTIVE) != IFM_ACTIVE), which yields bce_link_up to be FALSE. Yet I am confused by the role of actually writing to BCE_EMAC_MODE in order to keep the iDRAC link up, and wether the issue would not come from another part of the change. >> > > Because there is no publicly available documentation for ASF/IPMI > link handling it's not clear what steps should be taken whenever > its link state is changed. Previously bce(4) seems to drive > bce_tick regardless of driver running state. > New patch attached. It still does not work :( I tried to additionally comment lines as in: http://lists.freebsd.org/pipermail/freebsd-net/2011-September/029915.html but without success. Unfortunately, adding log messages is only an option if the boot succeeds to be able to dmesg later on. Paul -- Semiocast http://semiocast.com/ +33.183627948 - 20 rue Lacaze, 75014 Parishelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?39F5CD97-A7DF-4815-9F18-507E411844FA>