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

[John Baldwin]

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.

>  // 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?

>  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.

-- 
John Baldwin