Summary: | [PowerPC64] IPMI driver will attach, but ipmitool and commands sent to the device fail. | ||
---|---|---|---|
Product: | Base System | Reporter: | Sean Bruno <sbruno> |
Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed Unable to Reproduce | ||
Severity: | Affects Some People | CC: | alfredo, jhb, jhibbits, kbowling, luporl, mmacy, nwhitehorn |
Priority: | --- | ||
Version: | CURRENT | ||
Hardware: | powerpc | ||
OS: | Any |
Description
Sean Bruno
2018-10-22 23:15:41 UTC
Well, maybe its not BE as this appears to be loading the opal_ipmi interface on boot. opalcons0: <OPAL Consoles> on opal0 uart0: <OPAL Serial Port> on opalcons0 uart0: console ipmi0: <OPAL IPMI System Interface> on opal0 opalsens0: <OPAL Sensors> on opal0 Let me just see if I got it right: - I assume that using ipmitool from another OS/platform (e.g. Linux or FreeBSD on x86) to Tyan PPC hosts works, right? - The problem happens when issuing IPMI commands from Tyan PPC FreeBSD hosts to other Tyan PPC hosts, right? (In reply to Leandro Lupori from comment #2) Using ipmitool to connect to a remote Tyan PPC host works just fine. It how you power on and grab the console of these things. These errors are generated locally on a Tyan PPC host to query the local BMC. e.g. ipmitool lan print when the ipmi driver is loaded. It looks like petitboot can talk to the ipmi controller, most of the time. So, the linux kernel definitely has the code to do this. Sean, as a temporary workaround, aren't you able to use IPMI through the network? Commands like the following work fine for me: ipmitool -I lanplus -H 10.0.0.2 -P password sol activate (In reply to Leandro Lupori from comment #5) Yes. I am currently using IPMI as the console and power control for the freebsd.org machines. Remotely accessing IPMI over the network works just fine. Can you provide more details about how IPMI over OPAL works? Is it using one of the backends (KCS, SMIC, etc.) from the IPMI spec? If it is using the 'BT' backend, I don't think that I've ever seen that in the wild on x86 (and I didn't think we even supported it). Hmm, looks like it's an entirely separate thing just done via a single opal_call. Are those 'BT:' messages from the OPAL console? (In reply to John Baldwin from comment #7) The BT messages appear on the console of the machine. In this case its on the serial port. THe BT messages are from OPAL. The problem is that the IPMI send queue fills up, and never flushes. The queue is supposed to be ratcheted (processed and removed) when calling OPAL_HANDLE_INTERRUPT and OPAL_POLL_EVENTS, but that doesn't seem to be happening, and I don't understand why. Tyan PPC hosts were retired, so closing. |