Date: Sat, 6 May 2006 10:43:47 -0700 (PDT) From: Doug Ambrisko <ambrisko@ambrisko.com> To: Oleg Bulyzhin <oleg@freebsd.org> Cc: freebsd-net@freebsd.org, Robert Wojciechowski <robertw@ssginnovations.com> Subject: Re: IPMI and bge (again) Message-ID: <200605061743.k46HhlLK027788@ambrisko.com> In-Reply-To: <20060506082120.GA27842@lath.rinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
Oleg Bulyzhin writes: | On Wed, May 03, 2006 at 08:54:09PM -0700, Doug Ambrisko wrote: | > Robert Wojciechowski writes: | > | > Could you try this latest version. It incorporates Oleg | > | > change sort-of. It was a good hint. The issue is that | > | > we can't move the detection after the "reset" dance. Since | > | > it needs to know if ASF is active. What we can do is just | > | > do the bge_reset, look for ASF and then do the dance. This | > | > works really well and I makes the PHY probe work without the | > | > one remaining hack that I had left and I was able to get rid | > | > of a couple more hacks. | > | > | > | > This applies to RELENG_6. | > | > | > | > Please let me know how this works. I'd like to commit | > | > this. Please pay attention to if IPMI works before the | > | > NIC is UP/or has an IP and then when it is ifconfig down | > | > then up again. The PHY should be detected at brgphy | > | > and not the generic one. It should also have all of the | > | > proper speeds. It should work with and without PXE boot. | > | > Finally non-IPMI ones should work. | > | > | > | > So far it works on the variants I have. | > | | > | Doug, | > | | > | I tried your patch (as well as one from you on 1/13/2006) on FreeBSD | > | 6.1-RC2 but experienced hard lockups. It happens during startup right | > | after setting the hostname, right before it would normally bring up the | > | interface I believe. | > | > Could you try: | > http://www.ambrisko.com/doug/bge_ipmi_2.patch | > | > | This is on four different servers, all Supermicro motherboards (H8DAR | > | and H8DAE) based on the Broadcom BCM5704 chip. | > | | > | Here is the pciconf -lv: | > | | > | bge0@pci2:3:0: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class = network | > | subclass = ethernet | > | bge1@pci2:3:1: class=0x020000 card=0x164815d9 chip=0x164814e4 rev=0x10 | > | hdr=0x00 | > | vendor = 'Broadcom Corporation' | > | device = 'BCM5704 NetXtreme Dual Gigabit Adapter' | > | class = network | > | subclass = Ethernet | > | | > | Any ideas? If you need any more information or have other patches I can | > | test for you, let me know! | > | > Try this version. If this has trouble we can try to add some debug | > stuff to it. | > | > Thanks, | > | > Doug A. | | I've tested your new patch on hp proliant dl145g2 server with bcm5721 on board | chips: | bge1: <Broadcom BCM5721 Gigabit Ethernet, ASIC rev. 0x4101> mem 0xca100000-0xca10ffff irq 19 at device 0.0 on pci3 | | It does work but i've found some problems: | | minor ones: | 1) IPMI stop working for a few seconds while ifconfig bge1 up/down or driver | initialization (perhaps this happens when bge_reset() is called) This is expected and happens under Linux etc. If it didn't happen then we wouldn't need driver support for it! | 2) IPMI interface (bound to brgphy1) is unreachable from bge1 itself. I guess | it's due to simplex nature of bge. I'm not sure this can be fixed. Correct, if you have a routable connect then you can talk back to your self. | major one: | Driver is unable to detect link loss. Problematic code is in bge_tick_locked: | | /* Don't mess with the PHY in IPMI/ASF mode */ | if (!((sc->bge_asf_mode & ASF_STACKUP) && (sc->bge_link))) | mii_tick(mii); | | what purpose of this check? mii_tick() call is necessary for updating phy's | link status. In IPMI enabled we can't read the PHY much since the ASF firmware is also reading it. This can result in lock ups of the firmware :-( Both the driver and the ASF part stops working. So I only allow reads until we have link. I used to be able to detect if IPMI was enabled on the chip and then only prevent the poll in that case. Since your chip needed the reset first we lose that state info. So now I have to assume it on if the chip is capable :-( Linux goes a step further and never reads from the PHY. I've got it so I can read okay during initialization. If I could talk to chip reliably to read the asf stack up state then things would be better on machines that have multiple of these NIC's. Intel doesn't have as much issues. The new bce seems better, however, in DDB is seems IPMI stops working on the bce driver. The doc's don't really go into great detail and we found one chip (5704C) that barf's on: bge_writemem_ind(sc, BGE_SOFTWARE_GENCOMM, BGE_MAGIC_NUMBER); in bge_sig_pre_reset. I'm thinking we might want to try a sysctl to enable IPMI or only do this stuff for IPMI capable chips. Slowly things are getting better. Doug A.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200605061743.k46HhlLK027788>