Date: Thu, 3 Feb 2011 15:50:10 GMT From: Robert Clemens <robert@solidsolutions.net> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze Message-ID: <201102031550.p13FoAJd037184@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: John Baldwin <jhb@freebsd.org>, bug-followup@freebsd.org
Cc: freebsd-amd64@freebsd.org
Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
Date: Thu, 3 Feb 2011 09:43:00 -0600
--0016e6de00edd1062e049b629e96
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Feb 3, 2011 at 6:42 AM, John Baldwin <jhb@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@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.
>
> 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@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
amd64
[root@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@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
>
--0016e6de00edd1062e049b629e96
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br><div class=3D"gmail_quote">On Thu, Feb 3, 2011 at 6:42 AM, John Bal=
dwin <span dir=3D"ltr"><<a href=3D"mailto:jhb@freebsd.org">jhb@freebsd.o=
rg</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5">On Wednesday, February 02, 2011 11:50:12 =
pm Robert Clemens wrote:<br>
> The following reply was made to PR amd64/141413; it has been noted by =
GNATS.<br>
><br>
> From: Robert Clemens <<a href=3D"mailto:robert@solidsolutions.net">=
robert@solidsolutions.net</a>><br>
> To: bug-followup@FreeBSD.org, <a href=3D"mailto:bkyoung74q9@yahoo.com"=
>bkyoung74q9@yahoo.com</a>, <a href=3D"mailto:avg@freebsd.org">avg@freebsd.=
org</a><br>
> Cc:<br>
> Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze<br>
> Date: Wed, 02 Feb 2011 22:42:42 -0600<br>
><br>
> =A0I apologize for the length of this followup but wanted to detail th=
is as<br>
> =A0much as possible for future readers and<br>
> =A0what I believe to be the closing of PR141413 now that it appears to=
be<br>
> =A0resolved. With the documentation I have<br>
> =A0provided I feel this is easily duplicated.<br>
><br>
> =A0I pulled out the old trusty dev box (exact specs listed for this PR=
).<br>
> =A0 =A0 =A0Tyan s2881 motherboard with m3289 SMDC card.<br>
><br>
> =A0FreeBSD 8.2-RC2 works great with remote ipmi management while power=
is<br>
> =A0off, during bootup, and during normal<br>
> =A0operational init multiuser conditions.<br>
><br>
> =A0I last tried this for FreeBSD 8.1-RELEASE. I can't speak for wh=
en this<br>
> =A0started working but it was after 8.1-REL and sometime during 8.2-RC=
x.<br>
><br>
> =A0One thing I did notice is I no longer see ipmi0 dev or ipmi informa=
tion<br>
> =A0from dmesg as I used to. I'm not exactly sure the intended func=
tionality<br>
> =A0of the ipmi0 disappearance.<br>
> =A0This results in the inability to use ipmitool to connect locally fr=
om<br>
> =A0the machine in question as was once possible -- actually this was t=
he<br>
> =A0only way previous to use the ipmi<br>
> =A0functionality before 8.2-RCx. That may still result in an open issu=
e but<br>
> =A0as far as I'm concerned, I'm quite ecstatic to see a workin=
g console<br>
> =A0login via com2 over lan.<br>
<br>
</div></div>Can you get the ipmi lines from an older dmesg when it worked? =
=A0The output of<br>
dmidecode may also be useful.<br></blockquote><div><br></div><div>This is f=
rom another server I have running.</div><div><div>FreeBSD <a href=3D"http:/=
/abyss.solidsolutions.net">abyss.solidsolutions.net</a> 8.0-RELEASE FreeBSD=
8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 =A0 =A0 root@mason.cse.buffal=
o.edu:/usr/obj/usr/src/sys/GENERIC =A0amd64</div>
</div><div><br></div><div>[root@abyss /var/run]# cat dmesg.boot |grep ipmi<=
/div><div>ipmi0: <IPMI System Interface> on isa0</div><div>ipmi0: KCS=
mode found at io 0xca2 alignment 0x1 on isa</div><div>ipmi0: IPMI device r=
ev. 1, firmware rev. 1.81, version 1.5</div>
<div>ipmi0: Number of channels 1</div><div>ipmi0: Attached watchdog</div><d=
iv>[root@abyss /var/run]#=A0=A0</div><div><br></div><div><div>Handle 0x003B=
, DMI type 38, 16 bytes</div><div>IPMI Device Information</div><div>=A0=A0 =
=A0 =A0 =A0Interface Type: KCS (Keyboard Control Style)</div>
<div>=A0=A0 =A0 =A0 =A0Specification Version: 1.5</div><div>=A0=A0 =A0 =A0 =
=A0I2C Slave Address: 0x10</div><div>=A0=A0 =A0 =A0 =A0NV Storage Device: N=
ot Present</div><div>=A0=A0 =A0 =A0 =A0Base Address: 0x0000000000000CA2 (I/=
O)</div></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
> =A0// i also needed to bind the ip for the smdc to my network interfac=
e.<br>
> =A0// i used 192.168.1.199 on the smdc firmware. i added this as an al=
ias<br>
> =A0to my network interface.<br>
> =A0// notice i am using lagg0 but you would likely just be using bge0<=
br>
> =A0// the only thing below of concern is that you can indeed see that<=
br>
> =A0192.168.1.199 is active on my (pseudo-)NIC.<br>
<br>
</div>That is very odd. =A0In general with a BMC, the packets never make it=
to the OS,<br>
so you shouldn't need to do this. =A0Perhaps the BMC is not responding =
to ARP so<br>
by putting the IP in the host OS you cause the host OS to respond to ARP<br=
>
requests but the BMC then sniffs the IP traffic? =A0Can you verify that thi=
s<br>
step is required for you, and if so can you run a tcpdump of ARP packets on=
<br>
bge0 while doing a remote ipmitool command to see if you see ARP requests f=
or<br>
the BMC IP in the host OS?<br></blockquote><div><br></div><div><br></div><d=
iv>I'll verify the host OS IP binding when I get a chance and respond t=
o the PR.=A0</div><div>I do believe this has been a bge(4) issue all along =
and as bge(4) changes have</div>
<div>been made there has been a series of progressions on this matter.</div=
><div><br></div><div>I also previously neglected to mention that I did sysc=
tl=A0hw.bge.allow_asf=3D1</div><div><br></div><div>The IPMI card shares the=
bge0 interface with the host and does not have an interface</div>
<div>of its own.=A0</div><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im"><br>
> =A0Let me know if I missed something or need to clarify. It's hard=
to have<br>
> =A0amazing formatting in an email so it is a little sloppy.<br>
<br>
</div>The general issue from the PR sounds very much like a problem with bg=
e(4) and<br>
not specific to the IPMI or amd64 support. =A0We use IPMI with igb(4) parts=
at<br>
work without any issues, and we do not add the BMC IP as an alias on our ig=
b<br>
interfaces.<br></blockquote><div><br></div><div>Agreed. I'll provide mo=
re details when I get time tonight to test around on my dev server.</div><d=
iv>Appreciate the follow-up.</div><div>=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<br>
--<br>
<font color=3D"#888888">John Baldwin<br>
</font></blockquote></div><br>
--0016e6de00edd1062e049b629e96--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102031550.p13FoAJd037184>