Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec
fsl,ifc-nand 7e800000.nand: Controller is not responding main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l (detected by 1, t=2102 jiffies, g=7729, q=754) task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000 [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2) [<8064bb01>] (schedule) from [<8064dacd>] [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>] [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>] [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>] [<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
Signed-off-by: Ronald Monthero debug.penguin32@gmail.com --- drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c index 20bb1e0cb5eb..42f8ea46b6a8 100644 --- a/drivers/mtd/nand/raw/fsl_ifc_nand.c +++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c @@ -21,7 +21,7 @@
#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */ -#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum number of mSecs to wait for IFC NAND Machine */
struct fsl_ifc_ctrl;
Hi,
Thanks for your patch.
FYI: kernel test robot notices the stable kernel rule is not satisfied.
The check is based on https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#opti...
Rule: add the tag "Cc: stable@vger.kernel.org" in the sign-off area to have the patch automatically included in the stable tree. Subject: [PATCH v2] mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response Link: https://lore.kernel.org/stable/20231113155354.620298-1-debug.penguin32%40gma...
You are too quick with v2, below my comments (new and old).
On Tue, Nov 14, 2023 at 01:53:51AM +1000, Ronald Monthero wrote:
Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec
Missing period at the end?
fsl,ifc-nand 7e800000.nand: Controller is not responding
main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l (detected by 1, t=2102 jiffies, g=7729, q=754) task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000 [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2) [<8064bb01>] (schedule) from [<8064dacd>] [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>] [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>] [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>]
At least above 9 lines are not important and may be removed.
[<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
...
-#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum number of mSecs to wait for IFC NAND Machine */
While at it, you may improve the comment, e.g.,
"Maximum timeout to wait for IPC NAND Machine"
Hi Andy, Thanks for the feedback, I had not seen your response by then. I will modify and send it again.
BR, Ron
On Tue, Nov 14, 2023 at 2:04 AM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
You are too quick with v2, below my comments (new and old).
On Tue, Nov 14, 2023 at 01:53:51AM +1000, Ronald Monthero wrote:
Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec
Missing period at the end?
fsl,ifc-nand 7e800000.nand: Controller is not responding
main/smp_fsm.c:1884 <inrcu: rcu_preempt detected stalls on CPUs/tasks: rcu: Tasks blocked on level-0 rcu_node (CPUs 0-1): P116/2:b..l (detected by 1, t=2102 jiffies, g=7729, q=754) task:irq/31-arm-irq1 state:D stack: 0 pid: 116 ppid: 2 flags:0x00000000 [<8064b97f>] (__schedule) from [<8064bb01>] (schedule+0x8d/0xc2) [<8064bb01>] (schedule) from [<8064dacd>] [<8064dacd>] (rt_mutex_slowlock_block.constprop.0) from [<8064db57>] [<8064db57>] (__rt_mutex_slowlock.constprop.0) from [<8064dbf7>] [<8064dbf7>] (rt_mutex_slowlock.constprop.0) from [<804b2047>]
At least above 9 lines are not important and may be removed.
[<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
...
-#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum number of mSecs to wait for IFC NAND Machine */
While at it, you may improve the comment, e.g.,
"Maximum timeout to wait for IPC NAND Machine"
-- With Best Regards, Andy Shevchenko
Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec.
fsl,ifc-nand 7e800000.nand: Controller is not responding
[<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
Cc: stable@vger.kernel.org Signed-off-by: Ronald Monthero debug.penguin32@gmail.com --- drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c index 20bb1e0cb5eb..f0e2318ce088 100644 --- a/drivers/mtd/nand/raw/fsl_ifc_nand.c +++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c @@ -21,7 +21,7 @@
#define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */ -#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum timeout to wait for IFC NAND Machine */
struct fsl_ifc_ctrl;
Hi Ronald,
debug.penguin32@gmail.com wrote on Tue, 14 Nov 2023 03:32:49 +1000:
Under heavy load it is likely that the controller is done with its own task but the thread unlocking the wait is not scheduled in time. Increasing IFC_TIMEOUT_MSECS allows the controller to respond within allowable timeslice of 1 sec.
fsl,ifc-nand 7e800000.nand: Controller is not responding
[<804b2047>] (nand_get_device) from [<804b5335>] (nand_write_oob+0x1b/0x4a) [<804b5335>] (nand_write_oob) from [<804a3585>] (mtd_write+0x41/0x5c) [<804a3585>] (mtd_write) from [<804c1d47>] (ubi_io_write+0x17f/0x22c) [<804c1d47>] (ubi_io_write) from [<804c047b>] (ubi_eba_write_leb+0x5b/0x1d0)
Cc: stable@vger.kernel.org
I believe the Fixes tag is the latest missing piece?
Signed-off-by: Ronald Monthero debug.penguin32@gmail.com
drivers/mtd/nand/raw/fsl_ifc_nand.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/raw/fsl_ifc_nand.c b/drivers/mtd/nand/raw/fsl_ifc_nand.c index 20bb1e0cb5eb..f0e2318ce088 100644 --- a/drivers/mtd/nand/raw/fsl_ifc_nand.c +++ b/drivers/mtd/nand/raw/fsl_ifc_nand.c @@ -21,7 +21,7 @@ #define ERR_BYTE 0xFF /* Value returned for read bytes when read failed */ -#define IFC_TIMEOUT_MSECS 500 /* Maximum number of mSecs to wait +#define IFC_TIMEOUT_MSECS 1000 /* Maximum timeout to wait for IFC NAND Machine */ struct fsl_ifc_ctrl;
Thanks, Miquèl
linux-stable-mirror@lists.linaro.org
-
Andy Shevchenko -
kernel test robot -
Miquel Raynal -
Ronald Monthero