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@xxxxxxxxx>
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@xxxxxxxxx>
Signed-off-by: Chris Ball <cjb@xxxxxxxxxx>
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>
>
