mmc: sunxi: mask all Response Timeout error messages

PATCH In review Icenowy Zheng 2 participants 6 messages Mar 5, 2017 – Mar 7, 2017

Subsystems (2)

MMC, SD and SDIO Arm/Allwinner sunXi SoC support

lore

Share & tools

lore

Icenowy Zheng

author

2017-03-05 16:45 UTC #0 lore raw

PATCH 1/1 mmc: sunxi: mask all Response Timeout error messages

Response Timeout is very usual: it will happen when trying to run some commands that do not belong to the card; it will happen when some SDIO card transfer beyond its SDIO bandwidth; and when the MMC controller is set to poll the card with "broken-cd" property (the Lichee Pi series of boards do this), it will flood to the console and make the console unusable.

Mask all response-timeout-only error messages, only show it when another error happens.

Signed-off-by Icenowy Zheng <[email protected]>

---
 drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

drivers/mmc/host/sunxi-mmc.c +9 -4

index 6ffcd2838272..7828e1f57cf0 100644
@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host)
 	struct mmc_command *cmd = host->mrq->cmd;
 	struct mmc_data *data = host->mrq->data;
 
-	/* For some cmds timeout is normal with sd/mmc cards */
-	if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
-		SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND ||
-				      cmd->opcode == SD_IO_RW_DIRECT))
+	/*
+	 * Reading timeout is usually normal, especially when doing
+	 * card-polling with "broken-cd" in device tree.
+	 * If do not mask it, the RTO error message will flood the console
+	 * and even hide useful error messages.
+	 *
+	 * Some SDIO commands will also normally timeout with non-SDIO cards.
+	 */
+	if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT)
 		return;
 
 	dev_err(mmc_dev(host->mmc),

Signature · 1 line

2.11.1

Maxime Ripard

2017-03-06 10:04 UTC #1 lore raw

Hi,

Quoted 26 lines · Icenowy Zheng

Response Timeout is very usual: it will happen when trying to run some commands that do not belong to the card; it will happen when some SDIO card transfer beyond its SDIO bandwidth; and when the MMC controller is set to poll the card with "broken-cd" property (the Lichee Pi series of boards do this), it will flood to the console and make the console unusable.
Mask all response-timeout-only error messages, only show it when another error happens.
Signed-off-by Icenowy Zheng <[email protected]>
---
 drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/mmc/host/sunxi-mmc.c +0 -3
index 6ffcd2838272..7828e1f57cf0 100644
@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host)
 	struct mmc_command *cmd = host->mrq->cmd;
 	struct mmc_data *data = host->mrq->data;
 
-	/* For some cmds timeout is normal with sd/mmc cards */
-	if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
-		SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND ||

drivers/mmc/host/sunxi-mmc.c static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host) · line 494

Quoted 10 lines

drivers/mmc/host/sunxi-mmc.c +9 -1

-				      cmd->opcode == SD_IO_RW_DIRECT))
+	/*
+	 * Reading timeout is usually normal, especially when doing
+	 * card-polling with "broken-cd" in device tree.
+	 * If do not mask it, the RTO error message will flood the console
+	 * and even hide useful error messages.
+	 *
+	 * Some SDIO commands will also normally timeout with non-SDIO cards.
+	 */
+	if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT)

We really shouldn't silence legit errors.

The actual problem here is that we log them as error, we could probably reduce it to debug.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170306/5dbeee70/attachment.sig>

Icenowy Zheng

author

2017-03-06 10:32 UTC #2 lore raw

PATCH 1/1 mmc: sunxi: mask all Response Timeout error messages

06.03.2017, 18:04, "Maxime Ripard" <[email protected]>:

Quoted 40 lines

Hi,
Quoted 23 lines · Icenowy Zheng
?Response Timeout is very usual: it will happen when trying to run some ?commands that do not belong to the card; it will happen when some SDIO ?card transfer beyond its SDIO bandwidth; and when the MMC controller is ?set to poll the card with "broken-cd" property (the Lichee Pi series of ?boards do this), it will flood to the console and make the console ?unusable.
?Mask all response-timeout-only error messages, only show it when another ?error happens.
?Signed-off-by: Icenowy Zheng <[email protected]>
?---
??drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
??1 file changed, 9 insertions(+), 4 deletions(-)
?diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c ?index 6ffcd2838272..7828e1f57cf0 100644
?--- a/drivers/mmc/host/sunxi-mmc.c
?+++ b/drivers/mmc/host/sunxi-mmc.c
?@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host) ??????????struct mmc_command *cmd = host->mrq->cmd;
??????????struct mmc_data *data = host->mrq->data;
Quoted 13 lines
?- /* For some cmds timeout is normal with sd/mmc cards */ ?- if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
?- SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND || ?- cmd->opcode == SD_IO_RW_DIRECT))
?+ /*
?+ * Reading timeout is usually normal, especially when doing ?+ * card-polling with "broken-cd" in device tree.
?+ * If do not mask it, the RTO error message will flood the console ?+ * and even hide useful error messages.
?+ *
?+ * Some SDIO commands will also normally timeout with non-SDIO cards. ?+ */
?+ if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT)

Quoted 4 lines

We really shouldn't silence legit errors.
The actual problem here is that we log them as error, we could probably reduce it to debug.

Even if it's reduced to debug, it will still flush dmesg buffers.

Or make it only visible when "debug" parameter is present in kernel cmdline?

Quoted 7 lines

Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Maxime Ripard

2017-03-06 15:53 UTC #3 lore raw

Quoted 41 lines · Icenowy Zheng

06.03.2017, 18:04, "Maxime Ripard" <[email protected]>:
Quoted 40 lines
Hi,
Quoted 36 lines · Icenowy Zheng
?Response Timeout is very usual: it will happen when trying to run some ?commands that do not belong to the card; it will happen when some SDIO ?card transfer beyond its SDIO bandwidth; and when the MMC controller is ?set to poll the card with "broken-cd" property (the Lichee Pi series of ?boards do this), it will flood to the console and make the console ?unusable.
?Mask all response-timeout-only error messages, only show it when another ?error happens.
?Signed-off-by: Icenowy Zheng <[email protected]>
?---
??drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
??1 file changed, 9 insertions(+), 4 deletions(-)
?diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c ?index 6ffcd2838272..7828e1f57cf0 100644
?--- a/drivers/mmc/host/sunxi-mmc.c
?+++ b/drivers/mmc/host/sunxi-mmc.c
?@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host) ??????????struct mmc_command *cmd = host->mrq->cmd;
??????????struct mmc_data *data = host->mrq->data;
?- /* For some cmds timeout is normal with sd/mmc cards */ ?- if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
?- SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND || ?- cmd->opcode == SD_IO_RW_DIRECT))
?+ /*
?+ * Reading timeout is usually normal, especially when doing ?+ * card-polling with "broken-cd" in device tree.
?+ * If do not mask it, the RTO error message will flood the console ?+ * and even hide useful error messages.
?+ *
?+ * Some SDIO commands will also normally timeout with non-SDIO cards. ?+ */
?+ if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT)

Quoted 6 lines

Quoted 4 lines
We really shouldn't silence legit errors.
The actual problem here is that we log them as error, we could probably reduce it to debug.
Even if it's reduced to debug, it will still flush dmesg buffers.

No, it will not even be compiled by default.

Quoted 2 lines

Or make it only visible when "debug" parameter is present in kernel cmdline?

debug messages are visible in dmesg only if DEBUG is defined, which is only happening if CONFIG_MMC_DEBUG is set. This won't affect the general case in any way.

And it is output only if loglevel is set higher than 7.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170306/f0cd5a6a/attachment-0001.sig>

Icenowy Zheng

author

2017-03-06 17:28 UTC #4 lore raw

PATCH 1/1 mmc: sunxi: mask all Response Timeout error messages

06.03.2017, 23:53, "Maxime Ripard" <[email protected]>:

Quoted 51 lines · Icenowy Zheng

Quoted 46 lines
?06.03.2017, 18:04, "Maxime Ripard" <[email protected]>:
?> Hi,
?>
?> On Mon, Mar 06, 2017 at 12:45:35AM +0800, Icenowy Zheng wrote:
?>> ?Response Timeout is very usual: it will happen when trying to run some ?>> ?commands that do not belong to the card; it will happen when some SDIO ?>> ?card transfer beyond its SDIO bandwidth; and when the MMC controller is ?>> ?set to poll the card with "broken-cd" property (the Lichee Pi series of ?>> ?boards do this), it will flood to the console and make the console
?>> ?unusable.
?>>
?>> ?Mask all response-timeout-only error messages, only show it when another ?>> ?error happens.
?>>
?>> ?Signed-off-by: Icenowy Zheng <[email protected]>
?>> ?---
?>> ??drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
?>> ??1 file changed, 9 insertions(+), 4 deletions(-)
?>>
?>> ?diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c ?>> ?index 6ffcd2838272..7828e1f57cf0 100644
?>> ?--- a/drivers/mmc/host/sunxi-mmc.c
?>> ?+++ b/drivers/mmc/host/sunxi-mmc.c
?>> ?@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host) ?>> ??????????struct mmc_command *cmd = host->mrq->cmd;
?>> ??????????struct mmc_data *data = host->mrq->data;
?>>
?>> ?- /* For some cmds timeout is normal with sd/mmc cards */
?>> ?- if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
?>> ?- SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND ||
?>> ?- cmd->opcode == SD_IO_RW_DIRECT))
?>> ?+ /*
?>> ?+ * Reading timeout is usually normal, especially when doing
?>> ?+ * card-polling with "broken-cd" in device tree.
?>> ?+ * If do not mask it, the RTO error message will flood the console ?>> ?+ * and even hide useful error messages.
?>> ?+ *
?>> ?+ * Some SDIO commands will also normally timeout with non-SDIO cards. ?>> ?+ */
?>> ?+ if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT) ?>
?> We really shouldn't silence legit errors.
?>
?> The actual problem here is that we log them as error, we could
?> probably reduce it to debug.
Quoted 1 line
?Even if it's reduced to debug, it will still flush dmesg buffers.
No, it will not even be compiled by default.

Quoted 8 lines

Quoted 2 lines
?Or make it only visible when "debug" parameter is present in kernel ?cmdline?
debug messages are visible in dmesg only if DEBUG is defined, which is only happening if CONFIG_MMC_DEBUG is set. This won't affect the general case in any way.
And it is output only if loglevel is set higher than 7.

Should I make all error messages debug level or only make "RTO"-only error to debug level like I currently do?

Quoted 7 lines

Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Maxime Ripard

2017-03-07 10:10 UTC #5 lore raw

Quoted 57 lines · Icenowy Zheng

06.03.2017, 23:53, "Maxime Ripard" <[email protected]>:
Quoted 54 lines · Icenowy Zheng
Quoted 46 lines
?06.03.2017, 18:04, "Maxime Ripard" <[email protected]>:
?> Hi,
?>
?> On Mon, Mar 06, 2017 at 12:45:35AM +0800, Icenowy Zheng wrote:
?>> ?Response Timeout is very usual: it will happen when trying to run some ?>> ?commands that do not belong to the card; it will happen when some SDIO ?>> ?card transfer beyond its SDIO bandwidth; and when the MMC controller is ?>> ?set to poll the card with "broken-cd" property (the Lichee Pi series of ?>> ?boards do this), it will flood to the console and make the console
?>> ?unusable.
?>>
?>> ?Mask all response-timeout-only error messages, only show it when another ?>> ?error happens.
?>>
?>> ?Signed-off-by: Icenowy Zheng <[email protected]>
?>> ?---
?>> ??drivers/mmc/host/sunxi-mmc.c | 13 +++++++++----
?>> ??1 file changed, 9 insertions(+), 4 deletions(-)
?>>
?>> ?diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c ?>> ?index 6ffcd2838272..7828e1f57cf0 100644
?>> ?--- a/drivers/mmc/host/sunxi-mmc.c
?>> ?+++ b/drivers/mmc/host/sunxi-mmc.c
?>> ?@@ -483,10 +483,15 @@ static void sunxi_mmc_dump_errinfo(struct sunxi_mmc_host *host) ?>> ??????????struct mmc_command *cmd = host->mrq->cmd;
?>> ??????????struct mmc_data *data = host->mrq->data;
?>>
?>> ?- /* For some cmds timeout is normal with sd/mmc cards */
?>> ?- if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) ==
?>> ?- SDXC_RESP_TIMEOUT && (cmd->opcode == SD_IO_SEND_OP_COND ||
?>> ?- cmd->opcode == SD_IO_RW_DIRECT))
?>> ?+ /*
?>> ?+ * Reading timeout is usually normal, especially when doing
?>> ?+ * card-polling with "broken-cd" in device tree.
?>> ?+ * If do not mask it, the RTO error message will flood the console ?>> ?+ * and even hide useful error messages.
?>> ?+ *
?>> ?+ * Some SDIO commands will also normally timeout with non-SDIO cards. ?>> ?+ */
?>> ?+ if ((host->int_sum & SDXC_INTERRUPT_ERROR_BIT) == SDXC_RESP_TIMEOUT) ?>
?> We really shouldn't silence legit errors.
?>
?> The actual problem here is that we log them as error, we could
?> probably reduce it to debug.
Quoted 1 line
?Even if it's reduced to debug, it will still flush dmesg buffers.
No, it will not even be compiled by default.
Quoted 2 lines
?Or make it only visible when "debug" parameter is present in kernel ?cmdline?

Quoted 8 lines

Quoted 5 lines
debug messages are visible in dmesg only if DEBUG is defined, which is only happening if CONFIG_MMC_DEBUG is set. This won't affect the general case in any way.
And it is output only if loglevel is set higher than 7.
Should I make all error messages debug level or only make "RTO"-only error to debug level like I currently do?

I'd say just change the level of the log of the line coming below that one. It doesn't provide any useful clue about what's going on anyway, there's nothing the user will be able to do to prevent that, and someone willing to debug it will have to turn on the debug options anway.

Maxime

Signature · 10 lines

Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170307/d71f2173/attachment.sig>