amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze

Thu Feb 3 15:43:22 UTC 2011

On Thu, Feb 3, 2011 at 6:42 AM, John Baldwin <jhb at freebsd.org> wrote:

> On Wednesday, February 02, 2011 11:50:12 pm Robert Clemens wrote:
> > The following reply was made to PR amd64/141413; it has been noted by
> GNATS.
> >
> > From: Robert Clemens <robert at solidsolutions.net>
> > To: bug-followup at FreeBSD.org, bkyoung74q9 at yahoo.com, avg at freebsd.org
> > Cc:
> > Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
> > Date: Wed, 02 Feb 2011 22:42:42 -0600
> >
> >  I apologize for the length of this followup but wanted to detail this as
> >  much as possible for future readers and
> >  what I believe to be the closing of PR141413 now that it appears to be
> >  resolved. With the documentation I have
> >  provided I feel this is easily duplicated.
> >
> >  I pulled out the old trusty dev box (exact specs listed for this PR).
> >      Tyan s2881 motherboard with m3289 SMDC card.
> >
> >  FreeBSD 8.2-RC2 works great with remote ipmi management while power is
> >  off, during bootup, and during normal
> >  operational init multiuser conditions.
> >
> >  I last tried this for FreeBSD 8.1-RELEASE. I can't speak for when this
> >  started working but it was after 8.1-REL and sometime during 8.2-RCx.
> >
> >  One thing I did notice is I no longer see ipmi0 dev or ipmi information
> >  from dmesg as I used to. I'm not exactly sure the intended functionality
> >  of the ipmi0 disappearance.
> >  This results in the inability to use ipmitool to connect locally from
> >  the machine in question as was once possible -- actually this was the
> >  only way previous to use the ipmi
> >  functionality before 8.2-RCx. That may still result in an open issue but
> >  as far as I'm concerned, I'm quite ecstatic to see a working console
> >  login via com2 over lan.
>
> Can you get the ipmi lines from an older dmesg when it worked?  The output
> of
> dmidecode may also be useful.
>

This is from another server I have running.
FreeBSD abyss.solidsolutions.net 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov
21 15:02:08 UTC 2009
root at mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
 amd64

[root at abyss /var/run]# cat dmesg.boot |grep ipmi
ipmi0: <IPMI System Interface> on isa0
ipmi0: KCS mode found at io 0xca2 alignment 0x1 on isa
ipmi0: IPMI device rev. 1, firmware rev. 1.81, version 1.5
ipmi0: Number of channels 1
ipmi0: Attached watchdog
[root at abyss /var/run]#

Handle 0x003B, DMI type 38, 16 bytes
IPMI Device Information
        Interface Type: KCS (Keyboard Control Style)
        Specification Version: 1.5
        I2C Slave Address: 0x10
        NV Storage Device: Not Present
        Base Address: 0x0000000000000CA2 (I/O)

> >  // i also needed to bind the ip for the smdc to my network interface.
> >  // i used 192.168.1.199 on the smdc firmware. i added this as an alias
> >  to my network interface.
> >  // notice i am using lagg0 but you would likely just be using bge0
> >  // the only thing below of concern is that you can indeed see that
> >  192.168.1.199 is active on my (pseudo-)NIC.
>
> That is very odd.  In general with a BMC, the packets never make it to the
> OS,
> so you shouldn't need to do this.  Perhaps the BMC is not responding to ARP
> so
> by putting the IP in the host OS you cause the host OS to respond to ARP
> requests but the BMC then sniffs the IP traffic?  Can you verify that this
> step is required for you, and if so can you run a tcpdump of ARP packets on
> bge0 while doing a remote ipmitool command to see if you see ARP requests
> for
> the BMC IP in the host OS?
>

I'll verify the host OS IP binding when I get a chance and respond to the
PR.
I do believe this has been a bge(4) issue all along and as bge(4) changes
have
been made there has been a series of progressions on this matter.

I also previously neglected to mention that I did sysctl hw.bge.allow_asf=1

The IPMI card shares the bge0 interface with the host and does not have an
interface
of its own.

> >  Let me know if I missed something or need to clarify. It's hard to have
> >  amazing formatting in an email so it is a little sloppy.
>
> The general issue from the PR sounds very much like a problem with bge(4)
> and
> not specific to the IPMI or amd64 support.  We use IPMI with igb(4) parts
> at
> work without any issues, and we do not add the BMC IP as an alias on our
> igb
> interfaces.
>

Agreed. I'll provide more details when I get time tonight to test around on
my dev server.
Appreciate the follow-up.

>
> --
> John Baldwin
>