Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
Synopsis: [hang] Tyan 2881 m3289 SMDC freeze State-Changed-From-To: feedback-patched State-Changed-By: jh State-Changed-When: Sun Dec 11 09:47:23 UTC 2011 State-Changed-Why: Change the state according to submitter suggestion. http://www.freebsd.org/cgi/query-pr.cgi?pr=141413 ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
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 rob...@solidsolutions.net To: bug-follo...@freebsd.org, bkyoung7...@yahoo.com, a...@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 ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
The following reply was made to PR amd64/141413; it has been noted by GNATS. From: Robert Clemens rob...@solidsolutions.net To: John Baldwin j...@freebsd.org, bug-follo...@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 j...@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 rob...@solidsolutions.net To: bug-follo...@freebsd.org, bkyoung7...@yahoo.com, a...@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 r...@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: 0x0CA2 (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
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
On Thursday, February 03, 2011 10:43:00 am Robert Clemens wrote: On Thu, Feb 3, 2011 at 6:42 AM, John Baldwin j...@freebsd.org wrote: 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 r...@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: 0x0CA2 (I/O) Does the server running 8.2 have identical dmidecode output? -- John Baldwin ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
On 2/3/2011 10:57 AM, John Baldwin wrote: On Thursday, February 03, 2011 10:43:00 am Robert Clemens wrote: On Thu, Feb 3, 2011 at 6:42 AM, John Baldwinj...@freebsd.org wrote: 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 r...@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: 0x0CA2 (I/O) Does the server running 8.2 have identical dmidecode output? This is from the 8.2-RC2 server. So yes it is identical. 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: 0x0CA2 (I/O) ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
On 12/5/2010 8:10 AM, Andriy Gapon wrote: The following reply was made to PR amd64/141413; it has been noted by GNATS. From: Andriy Gapona...@freebsd.org To: bug-follo...@freebsd.org, bkyoung7...@yahoo.com Cc: Subject: Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze Date: Sun, 05 Dec 2010 16:08:44 +0200 Is this still an issue? The problem looks related to network code. It would be useful to discuss this on net@. It would be useful if you could get a stack trace of the hang. -- Andriy Gapon I've yet to see the problem subside so I imagine this is still an issue. I follow this PR as I still have this card and Freebsd in production and would love to see a resolution to this. I do believe I have a dev box with this setup and could probably get it operational to test around on this. -- Robert Clemens ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
Re: amd64/141413: [hang] Tyan 2881 m3289 SMDC freeze
Synopsis: [hang] Tyan 2881 m3289 SMDC freeze State-Changed-From-To: open-feedback State-Changed-By: linimon State-Changed-When: Thu Feb 3 07:11:36 UTC 2011 State-Changed-Why: To submitter: based on the most recent feedback, do you agree that this case can be closed? http://www.freebsd.org/cgi/query-pr.cgi?pr=141413 ___ freebsd-amd64@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
