* [BUG] discard_granularity is 0 on rk3399-gru-kevin @ 2020-09-27 20:29 Vicente Bergas 2020-09-28 3:15 ` Coly Li 0 siblings, 1 reply; 7+ messages in thread From: Vicente Bergas @ 2020-09-27 20:29 UTC (permalink / raw) To: Coly Li, Ming Lei, Hannes Reinecke, Jack Wang, Jens Axboe Cc: Bart Van Assche, Martin K. Petersen, Darrick J. Wong, Evan Green, linux-block, linux-rockchip, Xiao Ni, Enzo Matsumiya, Christoph Hellwig Hi, since recently the rk3399-gru-kevin is reporting the trace below. The issue has been uncovered by b35fd7422c2f8e04496f5a770bd4e1a205414b3f block: check queue's limits.discard_granularity in __blkdev_issue_discard() Regards, Vicente. WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 Hardware name: Google Kevin (DT) pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) pc : __blkdev_issue_discard+0x200/0x294 lr : __blkdev_issue_discard+0x54/0x294 sp : ffff800011dd3b10 x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: __blkdev_issue_discard+0x200/0x294 __submit_discard_cmd+0x128/0x374 __issue_discard_cmd_orderly+0x188/0x244 __issue_discard_cmd+0x2e8/0x33c issue_discard_thread+0xe8/0x2f0 kthread+0x11c/0x120 ret_from_fork+0x10/0x1c ---[ end trace e4c8023d33dfe77a ]--- mmcblk1p2: Error: discard_granularity is 0. mmcblk1p2: Error: discard_granularity is 0. <last message repeated multiple times> _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-27 20:29 [BUG] discard_granularity is 0 on rk3399-gru-kevin Vicente Bergas @ 2020-09-28 3:15 ` Coly Li 2020-09-28 5:02 ` Coly Li 0 siblings, 1 reply; 7+ messages in thread From: Coly Li @ 2020-09-28 3:15 UTC (permalink / raw) To: Vicente Bergas Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, Evan Green, Ming Lei, linux-block, linux-rockchip, Xiao Ni, Hannes Reinecke, Jack Wang, Christoph Hellwig, Enzo Matsumiya On 2020/9/28 04:29, Vicente Bergas wrote: > Hi, > since recently the rk3399-gru-kevin is reporting the trace below. > The issue has been uncovered by > b35fd7422c2f8e04496f5a770bd4e1a205414b3f > block: check queue's limits.discard_granularity in > __blkdev_issue_discard() Hi Vicente, Thanks for the information. It seems the device with f2fs declares to support DISCARD but don't initialize discard_granularity for its queue. Can I know which block driver is under f2fs ? Thanks. Coly Li > > WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 > CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 > Hardware name: Google Kevin (DT) > pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) > pc : __blkdev_issue_discard+0x200/0x294 > lr : __blkdev_issue_discard+0x54/0x294 > sp : ffff800011dd3b10 > x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: > ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: > ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: > 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: > 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: > 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: > 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : > 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : > ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : > 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: > __blkdev_issue_discard+0x200/0x294 > __submit_discard_cmd+0x128/0x374 > __issue_discard_cmd_orderly+0x188/0x244 > __issue_discard_cmd+0x2e8/0x33c > issue_discard_thread+0xe8/0x2f0 > kthread+0x11c/0x120 > ret_from_fork+0x10/0x1c > ---[ end trace e4c8023d33dfe77a ]--- > mmcblk1p2: Error: discard_granularity is 0. > mmcblk1p2: Error: discard_granularity is 0. > <last message repeated multiple times> _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-28 3:15 ` Coly Li @ 2020-09-28 5:02 ` Coly Li 2020-09-30 0:07 ` Vicente Bergas 2020-09-30 10:48 ` Adrian Hunter 0 siblings, 2 replies; 7+ messages in thread From: Coly Li @ 2020-09-28 5:02 UTC (permalink / raw) To: Vicente Bergas, adrian.hunter, cjb Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, Ming Lei, linux-block, linux-rockchip, Hannes Reinecke, Christoph Hellwig On 2020/9/28 11:15, Coly Li wrote: > On 2020/9/28 04:29, Vicente Bergas wrote: >> Hi, >> since recently the rk3399-gru-kevin is reporting the trace below. >> The issue has been uncovered by >> b35fd7422c2f8e04496f5a770bd4e1a205414b3f >> block: check queue's limits.discard_granularity in >> __blkdev_issue_discard() > > Hi Vicente, > > Thanks for the information. It seems the device with f2fs declares to > support DISCARD but don't initialize discard_granularity for its queue. > > Can I know which block driver is under f2fs ? Maybe it is the mmc driver. A zero value discard_granularity is from the following commit: commit e056a1b5b67b4e4bfad00bf143ab14f634777705 Author: Adrian Hunter <adrian.hunter@intel.com> Date: Tue Jun 28 17:16:02 2011 +0300 mmc: queue: let host controllers specify maximum discard timeout Some host controllers will not operate without a hardware timeout that is limited in value. However large discards require large timeouts, so there needs to be a way to specify the maximum discard size. A host controller driver may now specify the maximum discard timeout possible so that max_discard_sectors can be calculated. However, for eMMC when the High Capacity Erase Group Size is not in use, the timeout calculation depends on clock rate which may change. For that case Preferred Erase Size is used instead. Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> Signed-off-by: Chris Ball <cjb@laptop.org> Hi Adrian and Chris, I am not familiar with mmc driver, therefore I won't provide a quick fix like this (which might probably wrong), --- a/drivers/mmc/core/queue.c +++ b/drivers/mmc/core/queue.c @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct request_queue *q, q->limits.discard_granularity = card->pref_erase << 9; /* granularity must not be greater than max. discard */ if (card->pref_erase > max_discard) - q->limits.discard_granularity = 0; + q->limits.discard_granularity = SECTOR_SIZE; if (mmc_can_secure_erase_trim(card)) blk_queue_flag_set(QUEUE_FLAG_SECERASE, q); } It is improper for a device driver to declare to support DISCARD but set queue's discard_granularity as 0. Could you please to take a look for mmc_queue_setup_discard() ? Thanks in advance. Coly Li > >> >> WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 >> CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 >> Hardware name: Google Kevin (DT) >> pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) >> pc : __blkdev_issue_discard+0x200/0x294 >> lr : __blkdev_issue_discard+0x54/0x294 >> sp : ffff800011dd3b10 >> x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: >> ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: >> ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: >> 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: >> 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: >> 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: >> 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : >> 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : >> ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : >> 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: >> __blkdev_issue_discard+0x200/0x294 >> __submit_discard_cmd+0x128/0x374 >> __issue_discard_cmd_orderly+0x188/0x244 >> __issue_discard_cmd+0x2e8/0x33c >> issue_discard_thread+0xe8/0x2f0 >> kthread+0x11c/0x120 >> ret_from_fork+0x10/0x1c >> ---[ end trace e4c8023d33dfe77a ]--- >> mmcblk1p2: Error: discard_granularity is 0. >> mmcblk1p2: Error: discard_granularity is 0. >> <last message repeated multiple times> > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-28 5:02 ` Coly Li @ 2020-09-30 0:07 ` Vicente Bergas 2020-09-30 1:58 ` Coly Li 2020-09-30 10:48 ` Adrian Hunter 1 sibling, 1 reply; 7+ messages in thread From: Vicente Bergas @ 2020-09-30 0:07 UTC (permalink / raw) To: Coly Li Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, adrian.hunter, Ming Lei, linux-block, linux-rockchip, Hannes Reinecke, cjb, Christoph Hellwig On Monday, September 28, 2020 7:02:00 AM CEST, Coly Li wrote: > On 2020/9/28 11:15, Coly Li wrote: >> On 2020/9/28 04:29, Vicente Bergas wrote: >>> Hi, >>> since recently the rk3399-gru-kevin is reporting the trace below. >>> The issue has been uncovered by >>> b35fd7422c2f8e04496f5a770bd4e1a205414b3f >>> block: check queue's limits.discard_granularity in ... >> >> Hi Vicente, >> >> Thanks for the information. It seems the device with f2fs declares to >> support DISCARD but don't initialize discard_granularity for its queue. >> >> Can I know which block driver is under f2fs ? Hi Coly, yes, i confirm it is the mmc driver. Regards, Vicente. > Maybe it is the mmc driver. A zero value discard_granularity is from the > following commit: > > commit e056a1b5b67b4e4bfad00bf143ab14f634777705 > Author: Adrian Hunter <adrian.hunter@intel.com> > Date: Tue Jun 28 17:16:02 2011 +0300 > > mmc: queue: let host controllers specify maximum discard timeout > > Some host controllers will not operate without a hardware > timeout that is limited in value. However large discards > require large timeouts, so there needs to be a way to > specify the maximum discard size. > > A host controller driver may now specify the maximum discard > timeout possible so that max_discard_sectors can be calculated. > > However, for eMMC when the High Capacity Erase Group Size > is not in use, the timeout calculation depends on clock > rate which may change. For that case Preferred Erase Size > is used instead. > > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> > Signed-off-by: Chris Ball <cjb@laptop.org> > > > Hi Adrian and Chris, > > I am not familiar with mmc driver, therefore I won't provide a quick fix > like this (which might probably wrong), > --- a/drivers/mmc/core/queue.c > +++ b/drivers/mmc/core/queue.c > @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct > request_queue *q, > q->limits.discard_granularity = card->pref_erase << 9; > /* granularity must not be greater than max. discard */ > if (card->pref_erase > max_discard) > - q->limits.discard_granularity = 0; > + q->limits.discard_granularity = SECTOR_SIZE; > if (mmc_can_secure_erase_trim(card)) > blk_queue_flag_set(QUEUE_FLAG_SECERASE, q); > } > > > It is improper for a device driver to declare to support DISCARD but set > queue's discard_granularity as 0. > > Could you please to take a look for mmc_queue_setup_discard() ? > > Thanks in advance. > > Coly Li > > >> ... > > > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-30 0:07 ` Vicente Bergas @ 2020-09-30 1:58 ` Coly Li 0 siblings, 0 replies; 7+ messages in thread From: Coly Li @ 2020-09-30 1:58 UTC (permalink / raw) To: Vicente Bergas Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, adrian.hunter, Ming Lei, linux-block, linux-rockchip, Hannes Reinecke, cjb, Christoph Hellwig On 2020/9/30 08:07, Vicente Bergas wrote: > On Monday, September 28, 2020 7:02:00 AM CEST, Coly Li wrote: >> On 2020/9/28 11:15, Coly Li wrote: >>> On 2020/9/28 04:29, Vicente Bergas wrote: >>>> Hi, >>>> since recently the rk3399-gru-kevin is reporting the trace below. >>>> The issue has been uncovered by >>>> b35fd7422c2f8e04496f5a770bd4e1a205414b3f >>>> block: check queue's limits.discard_granularity in ... >>> >>> Hi Vicente, >>> >>> Thanks for the information. It seems the device with f2fs declares to >>> support DISCARD but don't initialize discard_granularity for its queue. >>> >>> Can I know which block driver is under f2fs ? > > Hi Coly, yes, i confirm it is the mmc driver. Let's wait for MMC developers to response firstly. Thanks. Coly Li > >> Maybe it is the mmc driver. A zero value discard_granularity is from the >> following commit: >> >> commit e056a1b5b67b4e4bfad00bf143ab14f634777705 >> Author: Adrian Hunter <adrian.hunter@intel.com> >> Date: Tue Jun 28 17:16:02 2011 +0300 >> >> mmc: queue: let host controllers specify maximum discard timeout >> >> Some host controllers will not operate without a hardware >> timeout that is limited in value. However large discards >> require large timeouts, so there needs to be a way to >> specify the maximum discard size. >> >> A host controller driver may now specify the maximum discard >> timeout possible so that max_discard_sectors can be calculated. >> >> However, for eMMC when the High Capacity Erase Group Size >> is not in use, the timeout calculation depends on clock >> rate which may change. For that case Preferred Erase Size >> is used instead. >> >> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> >> Signed-off-by: Chris Ball <cjb@laptop.org> >> >> >> Hi Adrian and Chris, >> >> I am not familiar with mmc driver, therefore I won't provide a quick fix >> like this (which might probably wrong), >> --- a/drivers/mmc/core/queue.c >> +++ b/drivers/mmc/core/queue.c >> @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct >> request_queue *q, >> q->limits.discard_granularity = card->pref_erase << 9; >> /* granularity must not be greater than max. discard */ >> if (card->pref_erase > max_discard) >> - q->limits.discard_granularity = 0; >> + q->limits.discard_granularity = SECTOR_SIZE; >> if (mmc_can_secure_erase_trim(card)) >> blk_queue_flag_set(QUEUE_FLAG_SECERASE, q); >> } >> >> >> It is improper for a device driver to declare to support DISCARD but set >> queue's discard_granularity as 0. >> >> Could you please to take a look for mmc_queue_setup_discard() ? >> >> Thanks in advance. >> >> Coly Li _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-28 5:02 ` Coly Li 2020-09-30 0:07 ` Vicente Bergas @ 2020-09-30 10:48 ` Adrian Hunter 2020-09-30 11:06 ` Coly Li 1 sibling, 1 reply; 7+ messages in thread From: Adrian Hunter @ 2020-09-30 10:48 UTC (permalink / raw) To: Coly Li, Vicente Bergas, cjb Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, Ming Lei, linux-block, linux-rockchip, Hannes Reinecke, Christoph Hellwig On 28/09/20 8:02 am, Coly Li wrote: > On 2020/9/28 11:15, Coly Li wrote: >> On 2020/9/28 04:29, Vicente Bergas wrote: >>> Hi, >>> since recently the rk3399-gru-kevin is reporting the trace below. >>> The issue has been uncovered by >>> b35fd7422c2f8e04496f5a770bd4e1a205414b3f >>> block: check queue's limits.discard_granularity in >>> __blkdev_issue_discard() >> >> Hi Vicente, >> >> Thanks for the information. It seems the device with f2fs declares to >> support DISCARD but don't initialize discard_granularity for its queue. >> >> Can I know which block driver is under f2fs ? > > Maybe it is the mmc driver. A zero value discard_granularity is from the > following commit: > > commit e056a1b5b67b4e4bfad00bf143ab14f634777705 > Author: Adrian Hunter <adrian.hunter@intel.com> > Date: Tue Jun 28 17:16:02 2011 +0300 > > mmc: queue: let host controllers specify maximum discard timeout > > Some host controllers will not operate without a hardware > timeout that is limited in value. However large discards > require large timeouts, so there needs to be a way to > specify the maximum discard size. > > A host controller driver may now specify the maximum discard > timeout possible so that max_discard_sectors can be calculated. > > However, for eMMC when the High Capacity Erase Group Size > is not in use, the timeout calculation depends on clock > rate which may change. For that case Preferred Erase Size > is used instead. > > Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> > Signed-off-by: Chris Ball <cjb@laptop.org> > > > Hi Adrian and Chris, > > I am not familiar with mmc driver, therefore I won't provide a quick fix > like this (which might probably wrong), > --- a/drivers/mmc/core/queue.c > +++ b/drivers/mmc/core/queue.c > @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct > request_queue *q, > q->limits.discard_granularity = card->pref_erase << 9; > /* granularity must not be greater than max. discard */ > if (card->pref_erase > max_discard) > - q->limits.discard_granularity = 0; > + q->limits.discard_granularity = SECTOR_SIZE; > if (mmc_can_secure_erase_trim(card)) > blk_queue_flag_set(QUEUE_FLAG_SECERASE, q); > } > > > It is improper for a device driver to declare to support DISCARD but set > queue's discard_granularity as 0. > > Could you please to take a look for mmc_queue_setup_discard() ? This should be OK. > > Thanks in advance. > > Coly Li > > >> >>> >>> WARNING: CPU: 0 PID: 135 at __blkdev_issue_discard+0x200/0x294 >>> CPU: 0 PID: 135 Comm: f2fs_discard-17 Not tainted 5.9.0-rc6 #1 >>> Hardware name: Google Kevin (DT) >>> pstate: 00000005 (nzcv daif -PAN -UAO BTYPE=--) >>> pc : __blkdev_issue_discard+0x200/0x294 >>> lr : __blkdev_issue_discard+0x54/0x294 >>> sp : ffff800011dd3b10 >>> x29: ffff800011dd3b10 x28: 0000000000000000 x27: ffff800011dd3cc4 x26: >>> ffff800011dd3e18 x25: 000000000004e69b x24: 0000000000000c40 x23: >>> ffff0000f1deaaf0 x22: ffff0000f2849200 x21: 00000000002734d8 x20: >>> 0000000000000008 x19: 0000000000000000 x18: 0000000000000000 x17: >>> 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: >>> 0000000000000394 x13: 0000000000000000 x12: 0000000000000000 x11: >>> 0000000000000000 x10: 00000000000008b0 x9 : ffff800011dd3cb0 x8 : >>> 000000000004e69b x7 : 0000000000000000 x6 : ffff0000f1926400 x5 : >>> ffff0000f1940800 x4 : 0000000000000000 x3 : 0000000000000c40 x2 : >>> 0000000000000008 x1 : 00000000002734d8 x0 : 0000000000000000 Call trace: >>> __blkdev_issue_discard+0x200/0x294 >>> __submit_discard_cmd+0x128/0x374 >>> __issue_discard_cmd_orderly+0x188/0x244 >>> __issue_discard_cmd+0x2e8/0x33c >>> issue_discard_thread+0xe8/0x2f0 >>> kthread+0x11c/0x120 >>> ret_from_fork+0x10/0x1c >>> ---[ end trace e4c8023d33dfe77a ]--- >>> mmcblk1p2: Error: discard_granularity is 0. >>> mmcblk1p2: Error: discard_granularity is 0. >>> <last message repeated multiple times> >> > _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin 2020-09-30 10:48 ` Adrian Hunter @ 2020-09-30 11:06 ` Coly Li 0 siblings, 0 replies; 7+ messages in thread From: Coly Li @ 2020-09-30 11:06 UTC (permalink / raw) To: Adrian Hunter Cc: Jens Axboe, Bart Van Assche, Martin K. Petersen, Darrick J. Wong, Vicente Bergas, Ming Lei, linux-block, linux-rockchip, Hannes Reinecke, cjb, Christoph Hellwig On 2020/9/30 18:48, Adrian Hunter wrote: > On 28/09/20 8:02 am, Coly Li wrote: >> On 2020/9/28 11:15, Coly Li wrote: >>> On 2020/9/28 04:29, Vicente Bergas wrote: >>>> Hi, >>>> since recently the rk3399-gru-kevin is reporting the trace below. >>>> The issue has been uncovered by >>>> b35fd7422c2f8e04496f5a770bd4e1a205414b3f >>>> block: check queue's limits.discard_granularity in >>>> __blkdev_issue_discard() >>> >>> Hi Vicente, >>> >>> Thanks for the information. It seems the device with f2fs declares to >>> support DISCARD but don't initialize discard_granularity for its queue. >>> >>> Can I know which block driver is under f2fs ? >> >> Maybe it is the mmc driver. A zero value discard_granularity is from the >> following commit: >> >> commit e056a1b5b67b4e4bfad00bf143ab14f634777705 >> Author: Adrian Hunter <adrian.hunter@intel.com> >> Date: Tue Jun 28 17:16:02 2011 +0300 >> >> mmc: queue: let host controllers specify maximum discard timeout >> >> Some host controllers will not operate without a hardware >> timeout that is limited in value. However large discards >> require large timeouts, so there needs to be a way to >> specify the maximum discard size. >> >> A host controller driver may now specify the maximum discard >> timeout possible so that max_discard_sectors can be calculated. >> >> However, for eMMC when the High Capacity Erase Group Size >> is not in use, the timeout calculation depends on clock >> rate which may change. For that case Preferred Erase Size >> is used instead. >> >> Signed-off-by: Adrian Hunter <adrian.hunter@intel.com> >> Signed-off-by: Chris Ball <cjb@laptop.org> >> >> >> Hi Adrian and Chris, >> >> I am not familiar with mmc driver, therefore I won't provide a quick fix >> like this (which might probably wrong), >> --- a/drivers/mmc/core/queue.c >> +++ b/drivers/mmc/core/queue.c >> @@ -190,7 +190,7 @@ static void mmc_queue_setup_discard(struct >> request_queue *q, >> q->limits.discard_granularity = card->pref_erase << 9; >> /* granularity must not be greater than max. discard */ >> if (card->pref_erase > max_discard) >> - q->limits.discard_granularity = 0; >> + q->limits.discard_granularity = SECTOR_SIZE; >> if (mmc_can_secure_erase_trim(card)) >> blk_queue_flag_set(QUEUE_FLAG_SECERASE, q); >> } >> >> >> It is improper for a device driver to declare to support DISCARD but set >> queue's discard_granularity as 0. >> >> Could you please to take a look for mmc_queue_setup_discard() ? > > This should be OK. OK Then I will post a fix and CC you. Thank for the review. Coly Li _______________________________________________ Linux-rockchip mailing list Linux-rockchip@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-rockchip ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-09-30 11:06 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-09-27 20:29 [BUG] discard_granularity is 0 on rk3399-gru-kevin Vicente Bergas 2020-09-28 3:15 ` Coly Li 2020-09-28 5:02 ` Coly Li 2020-09-30 0:07 ` Vicente Bergas 2020-09-30 1:58 ` Coly Li 2020-09-30 10:48 ` Adrian Hunter 2020-09-30 11:06 ` Coly Li
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).