| Message ID | 1490283150-24000-1-git-send-email-okaya@codeaurora.org (mailing list archive) |
|---|---|
| State | Accepted, archived |
| Headers | show |
Why would a timeout for a message be expected? The BMC should at least respond with an error for an incorrect message. -corey On 03/23/2017 10:32 AM, Sinan Kaya wrote: > Getting timeout message from BMC when trying to read from a non-existent > FRU. This is expected but warning is not. > > Let's reduce the warning to debug. > > Signed-off-by: Sinan Kaya <okaya@codeaurora.org> > --- > drivers/acpi/acpi_ipmi.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c > index 747c2ba..1b64419 100644 > --- a/drivers/acpi/acpi_ipmi.c > +++ b/drivers/acpi/acpi_ipmi.c > @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data) > if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE && > msg->msg.data_len == 1) { > if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) { > - dev_WARN_ONCE(dev, true, > - "Unexpected response (timeout).\n"); > + dev_dbg_once(dev, "Unexpected response (timeout).\n"); > tx_msg->msg_done = ACPI_IPMI_TIMEOUT; > } > goto out_comp; -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 3/24/2017 10:55 PM, Corey Minyard wrote: > Why would a timeout for a message be expected? The BMC should > at least respond with an error for an incorrect message. Let me add some more context... In this particular case, the FRU ID that I was trying to access was correct. Platform supports PCIe hotplug. The FRU is embedded into the HW that is being removed. That's what I mean by non-existent. When the device is ejected and a FRU command is executed, BMC times out reaching to the FRU on the device. When the device is inserted, everything works as expected. > > -corey > > On 03/23/2017 10:32 AM, Sinan Kaya wrote: >> Getting timeout message from BMC when trying to read from a non-existent >> FRU. This is expected but warning is not. >> >> Let's reduce the warning to debug. >> >> Signed-off-by: Sinan Kaya <okaya@codeaurora.org> >> --- >> drivers/acpi/acpi_ipmi.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c >> index 747c2ba..1b64419 100644 >> --- a/drivers/acpi/acpi_ipmi.c >> +++ b/drivers/acpi/acpi_ipmi.c >> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data) >> if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE && >> msg->msg.data_len == 1) { >> if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) { >> - dev_WARN_ONCE(dev, true, >> - "Unexpected response (timeout).\n"); >> + dev_dbg_once(dev, "Unexpected response (timeout).\n"); >> tx_msg->msg_done = ACPI_IPMI_TIMEOUT; >> } >> goto out_comp; > > >
On 03/25/2017 09:08 AM, Sinan Kaya wrote: > On 3/24/2017 10:55 PM, Corey Minyard wrote: >> Why would a timeout for a message be expected? The BMC should >> at least respond with an error for an incorrect message. > Let me add some more context... > > In this particular case, the FRU ID that I was trying to access was > correct. > > Platform supports PCIe hotplug. The FRU is embedded into the HW that > is being removed. That's what I mean by non-existent. > > When the device is ejected and a FRU command is executed, BMC times out > reaching to the FRU on the device. > > When the device is inserted, everything works as expected. I haven't added this yet. Someone who knows more about the ACPI side of IPMI should probably comment. So I've added Lv Zheng. This is ok with me, though. If you remove a management controller, a timeout is expected. However, if the management controller is still present, a timeout is probably not the best error code, "destination unavailable" is probably a better choice. So: Acked-by: Corey Minyard <cminyard@mvista.com> -corey > >> -corey >> >> On 03/23/2017 10:32 AM, Sinan Kaya wrote: >>> Getting timeout message from BMC when trying to read from a non-existent >>> FRU. This is expected but warning is not. >>> >>> Let's reduce the warning to debug. >>> >>> Signed-off-by: Sinan Kaya <okaya@codeaurora.org> >>> --- >>> drivers/acpi/acpi_ipmi.c | 3 +-- >>> 1 file changed, 1 insertion(+), 2 deletions(-) >>> >>> diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c >>> index 747c2ba..1b64419 100644 >>> --- a/drivers/acpi/acpi_ipmi.c >>> +++ b/drivers/acpi/acpi_ipmi.c >>> @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data) >>> if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE && >>> msg->msg.data_len == 1) { >>> if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) { >>> - dev_WARN_ONCE(dev, true, >>> - "Unexpected response (timeout).\n"); >>> + dev_dbg_once(dev, "Unexpected response (timeout).\n"); >>> tx_msg->msg_done = ACPI_IPMI_TIMEOUT; >>> } >>> goto out_comp; >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote: > On 03/25/2017 09:08 AM, Sinan Kaya wrote: >> >> On 3/24/2017 10:55 PM, Corey Minyard wrote: >>> >>> Why would a timeout for a message be expected? The BMC should >>> at least respond with an error for an incorrect message. >> >> Let me add some more context... >> >> In this particular case, the FRU ID that I was trying to access was >> correct. >> >> Platform supports PCIe hotplug. The FRU is embedded into the HW that >> is being removed. That's what I mean by non-existent. >> >> When the device is ejected and a FRU command is executed, BMC times out >> reaching to the FRU on the device. >> >> When the device is inserted, everything works as expected. > > > I haven't added this yet. Someone who knows more about the ACPI side of > IPMI > should probably comment. So I've added Lv Zheng. > > This is ok with me, though. If you remove a management controller, a > timeout is > expected. However, if the management controller is still present, a timeout > is > probably not the best error code, "destination unavailable" is probably a > better > choice. > > So: > > Acked-by: Corey Minyard <cminyard@mvista.com> > > -corey FWIW, this change is fine by me, so please feel free to route this through the IPMI tree along with the other patch from Sinan. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/28/2017 05:06 PM, Rafael J. Wysocki wrote: > On Tue, Mar 28, 2017 at 10:01 PM, Corey Minyard <minyard@acm.org> wrote: >> On 03/25/2017 09:08 AM, Sinan Kaya wrote: >>> On 3/24/2017 10:55 PM, Corey Minyard wrote: >>>> Why would a timeout for a message be expected? The BMC should >>>> at least respond with an error for an incorrect message. >>> Let me add some more context... >>> >>> In this particular case, the FRU ID that I was trying to access was >>> correct. >>> >>> Platform supports PCIe hotplug. The FRU is embedded into the HW that >>> is being removed. That's what I mean by non-existent. >>> >>> When the device is ejected and a FRU command is executed, BMC times out >>> reaching to the FRU on the device. >>> >>> When the device is inserted, everything works as expected. >> >> I haven't added this yet. Someone who knows more about the ACPI side of >> IPMI >> should probably comment. So I've added Lv Zheng. >> >> This is ok with me, though. If you remove a management controller, a >> timeout is >> expected. However, if the management controller is still present, a timeout >> is >> probably not the best error code, "destination unavailable" is probably a >> better >> choice. >> >> So: >> >> Acked-by: Corey Minyard <cminyard@mvista.com> >> >> -corey > FWIW, this change is fine by me, so please feel free to route this > through the IPMI tree along with the other patch from Sinan. Ok, done, with your ack added. Thanks, -corey > Thanks, > Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/acpi/acpi_ipmi.c b/drivers/acpi/acpi_ipmi.c index 747c2ba..1b64419 100644 --- a/drivers/acpi/acpi_ipmi.c +++ b/drivers/acpi/acpi_ipmi.c @@ -429,8 +429,7 @@ static void ipmi_msg_handler(struct ipmi_recv_msg *msg, void *user_msg_data) if (msg->recv_type == IPMI_RESPONSE_RECV_TYPE && msg->msg.data_len == 1) { if (msg->msg.data[0] == IPMI_TIMEOUT_COMPLETION_CODE) { - dev_WARN_ONCE(dev, true, - "Unexpected response (timeout).\n"); + dev_dbg_once(dev, "Unexpected response (timeout).\n"); tx_msg->msg_done = ACPI_IPMI_TIMEOUT; } goto out_comp;
Getting timeout message from BMC when trying to read from a non-existent FRU. This is expected but warning is not. Let's reduce the warning to debug. Signed-off-by: Sinan Kaya <okaya@codeaurora.org> --- drivers/acpi/acpi_ipmi.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)