summaryrefslogtreecommitdiffstats
path: root/include/uapi/linux/ipmi_msgdefs.h
diff options
context:
space:
mode:
authorXianting Tian <tian.xianting@h3c.com>2020-09-15 15:18:17 +0800
committerCorey Minyard <cminyard@mvista.com>2020-09-15 09:57:45 -0500
commitf8910ffa81b085030dc54814c85d338c26a3157e (patch)
treea16d8a66419146bb10f939472e954144a1d5ed91 /include/uapi/linux/ipmi_msgdefs.h
parentc2b1e76d8c91166ca5f7aa8df02d67b619e24dc3 (diff)
downloadlinux-stable-f8910ffa81b085030dc54814c85d338c26a3157e.tar.gz
linux-stable-f8910ffa81b085030dc54814c85d338c26a3157e.tar.bz2
linux-stable-f8910ffa81b085030dc54814c85d338c26a3157e.zip
ipmi:msghandler: retry to get device id on an error
We fail to get the BMCS's device id with low probability when loading the ipmi driver and it causes BMC device registration failed. When this issue occurs we got below kernel prints: [Wed Sep 9 19:52:03 2020] ipmi_si IPI0001:00: IPMI message handler: device id demangle failed: -22 [Wed Sep 9 19:52:03 2020] IPMI BT: using default values [Wed Sep 9 19:52:03 2020] IPMI BT: req2rsp=5 secs retries=2 [Wed Sep 9 19:52:03 2020] ipmi_si IPI0001:00: Unable to get the device id: -5 [Wed Sep 9 19:52:04 2020] ipmi_si IPI0001:00: Unable to register device: error -5 When this issue happens, we want to manually unload the driver and try to load it again, but it can't be unloaded by 'rmmod' as it is already 'in use'. We add a print in handle_one_recv_msg(), when this issue happens, the msg we received is "Recv: 1c 01 d5", which means the data_len is 1, data[0] is 0xd5 (completion code), which means "bmc cannot execute command. Command, or request parameter(s), not supported in present state". Debug code: static int handle_one_recv_msg(struct ipmi_smi *intf, struct ipmi_smi_msg *msg) { printk("Recv: %*ph\n", msg->rsp_size, msg->rsp); ... ... } Then in ipmi_demangle_device_id(), it returned '-EINVAL' as 'data_len < 7' and 'data[0] != 0'. We created this patch to retry the get device id when this error happens. We reproduced this issue again and the retry succeed on the first retry, we finally got the correct msg and then all is ok: Recv: 1c 01 00 01 81 05 84 02 af db 07 00 01 00 b9 00 10 00 So use a retry machanism in this patch to give bmc more opportunity to correctly response kernel when we received specific completion codes. Signed-off-by: Xianting Tian <tian.xianting@h3c.com> Message-Id: <20200915071817.4484-1-tian.xianting@h3c.com> [Cleaned up the verbage a bit in the header and prints.] Signed-off-by: Corey Minyard <cminyard@mvista.com>
Diffstat (limited to 'include/uapi/linux/ipmi_msgdefs.h')
-rw-r--r--include/uapi/linux/ipmi_msgdefs.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/include/uapi/linux/ipmi_msgdefs.h b/include/uapi/linux/ipmi_msgdefs.h
index c2b23a9fdf3d..0934af3b8037 100644
--- a/include/uapi/linux/ipmi_msgdefs.h
+++ b/include/uapi/linux/ipmi_msgdefs.h
@@ -69,6 +69,8 @@
#define IPMI_ERR_MSG_TRUNCATED 0xc6
#define IPMI_REQ_LEN_INVALID_ERR 0xc7
#define IPMI_REQ_LEN_EXCEEDED_ERR 0xc8
+#define IPMI_DEVICE_IN_FW_UPDATE_ERR 0xd1
+#define IPMI_DEVICE_IN_INIT_ERR 0xd2
#define IPMI_NOT_IN_MY_STATE_ERR 0xd5 /* IPMI 2.0 */
#define IPMI_LOST_ARBITRATION_ERR 0x81
#define IPMI_BUS_ERR 0x82