Date: Thu, 3 Feb 2011 04:50:12 GMT From: Robert Clemens <robert@solidsolutions.net> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze Message-ID: <201102030450.p134oCD8093377@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/141413; it has been noted by GNATS.
From: Robert Clemens <robert@solidsolutions.net>
To: bug-followup@FreeBSD.org, bkyoung74q9@yahoo.com, avg@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.
Now for the setup for replication (I would love someone to verify this
on another similar system):
Make sure you setup the SMDC card with username/password/ip/etc.
Make sure you enable remote access in BIOS. There are a few settings.
You will need to find them all and bind it to NIC48 (bge0).
FreeBSD tyan.solidsolutions.net 8.2-RC2 FreeBSD 8.2-RC2 #0: Wed Jan 12
17:02:35 UTC 2011
root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
// nothing in dmesg..
[root@tyan ~]# dmesg |grep ipmi
[root@tyan ~]#
// i do have ipmi module loaded in loader.conf
[root@tyan ~]# kldstat
Id Refs Address Size Name
1 23 0xffffffff80100000 da04a0 kernel
2 1 0xffffffff80ea1000 21068 geom_mirror.ko
3 1 0xffffffff80ec3000 4d0a0 pf.ko
4 1 0xffffffff80f11000 15e0 accf_http.ko
5 1 0xffffffff80f13000 fba8 ipmi.ko
6 4 0xffffffff80f23000 24c0 smbus.ko
7 1 0xffffffff80f26000 2d48 smb.ko
8 1 0xffffffff80f29000 3e00 amdsmb.ko
9 1 0xffffffff80f2d000 ba60 if_lagg.ko
[root@tyan ~]#
// i added a line to /etc/ttys for console redirection (com2 19200 baud
vt100 emulation)
ttyu1 "/usr/libexec/getty std.19200" vt100 on secure
// 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.
lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
ether 00:e0:81:2d:b1:5c
inet 192.168.1.131 netmask 0xffffff00 broadcast 192.168.1.255
inet 192.168.1.90 netmask 0xffffffff broadcast 192.168.1.90
inet 192.168.1.91 netmask 0xffffffff broadcast 192.168.1.91
inet 192.168.1.92 netmask 0xffffffff broadcast 192.168.1.92
inet 192.168.1.93 netmask 0xffffffff broadcast 192.168.1.93
inet 192.168.1.94 netmask 0xffffffff broadcast 192.168.1.94
inet 192.168.1.95 netmask 0xffffffff broadcast 192.168.1.95
inet 192.168.1.96 netmask 0xffffffff broadcast 192.168.1.96
inet 192.168.1.97 netmask 0xffffffff broadcast 192.168.1.97
inet 192.168.1.98 netmask 0xffffffff broadcast 192.168.1.98
inet 192.168.1.199 netmask 0xffffffff broadcast 192.168.1.199
media: Ethernet autoselect
status: active
laggproto failover
laggport: bge1 flags=0<>
laggport: bge0 flags=5<MASTER,ACTIVE>
// i used ipmitool several times over and over again with the below command
// to make sure i have active response. if your information is correct
you should
// get a clear sign that it is working
ipmitool -I lan -H 192.168.1.199 -UAdministrator -Ppassword chassis status
System Power : on
Power Overload : false
Power Interlock : inactive
Main Power Fault : false
Power Control Fault : false
Power Restore Policy : always-off
Last Power Event : command
Chassis Intrusion : inactive
Front-Panel Lockout : inactive
Drive Fault : false
Cooling/Fan Fault : false
//The big surprise was that I could do this even after the system had
finished booting into FreeBSD!!!!!
// and lastly I used ipmitool from another linux box on the network to
connect
ipmitool -I lan -H 192.168.1.199 -UAdministrator -Ppassword tsol
[Starting SOL with receiving address 192.168.1.100:6230]
[SOL Session operational. Use ~? for help]
FreeBSD/amd64 (tyan.solidsolutions.net) (ttyu1)
login:
//A login prompt via ttyu1 (com2) !!!!!!
//And after logging in with my credentials you can see below that I am
root on ttyu1!
[root@tyan ~]# w
4:33PM up 22 mins, 2 users, load averages: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE WHAT
root u1 - 4:18PM - -tcsh (tcsh)
robert pts/0 mystique 4:12PM - w
[root@tyan ~]#
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.
--
Robert Clemens
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102030450.p134oCD8093377>