| Message ID | 20231113155354.620298-1-debug.penguin32@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] mtd: rawnand: Increment IFC_TIMEOUT_MSECS for nand controller response | expand |
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 > >
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;
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(-)