All of lore.kernel.org
 help / color / mirror / Atom feed
* [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-27 20:29 ` Vicente Bergas
  0 siblings, 0 replies; 14+ 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, Christoph Hellwig, Darrick J. Wong,
	Enzo Matsumiya, Evan Green, Martin K. Petersen, Xiao Ni,
	linux-block, linux-rockchip

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>

^ permalink raw reply	[flat|nested] 14+ messages in thread
* [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-27 20:29 ` Vicente Bergas
  0 siblings, 0 replies; 14+ 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] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
  2020-09-27 20:29 ` Vicente Bergas
@ 2020-09-28  3:15   ` Coly Li
  -1 siblings, 0 replies; 14+ messages in thread
From: Coly Li @ 2020-09-28  3:15 UTC (permalink / raw)
  To: Vicente Bergas
  Cc: Ming Lei, Hannes Reinecke, Jack Wang, Jens Axboe,
	Bart Van Assche, Christoph Hellwig, Darrick J. Wong,
	Enzo Matsumiya, Evan Green, Martin K. Petersen, Xiao Ni,
	linux-block, linux-rockchip

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>


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-28  3:15   ` Coly Li
  0 siblings, 0 replies; 14+ 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] 14+ 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
  -1 siblings, 0 replies; 14+ messages in thread
From: Coly Li @ 2020-09-28  5:02 UTC (permalink / raw)
  To: Vicente Bergas, adrian.hunter, cjb
  Cc: Ming Lei, Hannes Reinecke, Jens Axboe, Bart Van Assche,
	Christoph Hellwig, Darrick J. Wong, Martin K. Petersen,
	linux-block, linux-rockchip

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>
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-28  5:02     ` Coly Li
  0 siblings, 0 replies; 14+ 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] 14+ 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
  -1 siblings, 0 replies; 14+ messages in thread
From: Vicente Bergas @ 2020-09-30  0:07 UTC (permalink / raw)
  To: Coly Li
  Cc: adrian.hunter, cjb, Ming Lei, Hannes Reinecke, Jens Axboe,
	Bart Van Assche, Christoph Hellwig, Darrick J. Wong,
	Martin K. Petersen, linux-block, linux-rockchip

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
>
>
>>  ...
>
>
>


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-30  0:07       ` Vicente Bergas
  0 siblings, 0 replies; 14+ 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] 14+ 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
  -1 siblings, 0 replies; 14+ messages in thread
From: Coly Li @ 2020-09-30  1:58 UTC (permalink / raw)
  To: Vicente Bergas
  Cc: adrian.hunter, cjb, Ming Lei, Hannes Reinecke, Jens Axboe,
	Bart Van Assche, Christoph Hellwig, Darrick J. Wong,
	Martin K. Petersen, linux-block, linux-rockchip

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


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-30  1:58         ` Coly Li
  0 siblings, 0 replies; 14+ 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] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
  2020-09-28  5:02     ` Coly Li
@ 2020-09-30 10:48       ` Adrian Hunter
  -1 siblings, 0 replies; 14+ messages in thread
From: Adrian Hunter @ 2020-09-30 10:48 UTC (permalink / raw)
  To: Coly Li, Vicente Bergas, cjb
  Cc: Ming Lei, Hannes Reinecke, Jens Axboe, Bart Van Assche,
	Christoph Hellwig, Darrick J. Wong, Martin K. Petersen,
	linux-block, linux-rockchip

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>
>>
> 


^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-30 10:48       ` Adrian Hunter
  0 siblings, 0 replies; 14+ 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] 14+ 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
  -1 siblings, 0 replies; 14+ messages in thread
From: Coly Li @ 2020-09-30 11:06 UTC (permalink / raw)
  To: Adrian Hunter
  Cc: Vicente Bergas, cjb, Ming Lei, Hannes Reinecke, Jens Axboe,
	Bart Van Assche, Christoph Hellwig, Darrick J. Wong,
	Martin K. Petersen, linux-block, linux-rockchip

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

^ permalink raw reply	[flat|nested] 14+ messages in thread
* Re: [BUG] discard_granularity is 0 on rk3399-gru-kevin
@ 2020-09-30 11:06         ` Coly Li
  0 siblings, 0 replies; 14+ 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] 14+ messages in thread
end of thread, other threads:[~2020-09-30 11:06 UTC | newest]

Thread overview: 14+ 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-27 20:29 ` Vicente Bergas
2020-09-28  3:15 ` Coly Li
2020-09-28  3:15   ` Coly Li
2020-09-28  5:02   ` Coly Li
2020-09-28  5:02     ` Coly Li
2020-09-30  0:07     ` Vicente Bergas
2020-09-30  0:07       ` Vicente Bergas
2020-09-30  1:58       ` Coly Li
2020-09-30  1:58         ` Coly Li
2020-09-30 10:48     ` Adrian Hunter
2020-09-30 10:48       ` Adrian Hunter
2020-09-30 11:06       ` Coly Li
2020-09-30 11:06         ` Coly Li

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.