On a system with large pages (64k in my case), the following BUG is
triggered in MMC core:
[ 2.338023] BUG: failure at drivers/mmc/core/core.c:221/mmc_start_request()!
[ 2.338102] Kernel panic - not syncing: BUG!
[ 2.338155] Call trace:
[ 2.338228] [<
ffffffc00008635c>] dump_backtrace+0x0/0x120
[ 2.338317] [<
ffffffc0003365ec>] dump_stack+0x14/0x1c
[ 2.338403] [<
ffffffc000336990>] panic+0xbc/0x1f0
[ 2.338498] [<
ffffffc00027a494>] mmc_start_request+0x154/0x184
[ 2.338600] [<
ffffffc00027abdc>] mmc_start_req+0x110/0x140
[ 2.338701] [<
ffffffc00028604c>] mmc_blk_issue_rw_rq+0x7c/0x39c
[ 2.338804] [<
ffffffc00028652c>] mmc_blk_issue_rq+0x1c0/0x468
[ 2.338905] [<
ffffffc000287564>] mmc_queue_thread+0x68/0x118
[ 2.338995] [<
ffffffc0000bc308>] kthread+0x84/0x8c
This is because of a 64k request with a max_req_size of 64k-1 bytes.
The following patch fixes the problem by limiting the max_blk_count
such that max_blk_count * max_blk_size == max_req_size. I couldn't
pursuade the compiler to emit a shift instead of a div without encoding
the shift explicitly.
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
/*
* Block size can be up to 2048 bytes, but must be a power of two.
*/
- mmc->max_blk_size = 2048;
+ mmc->max_blk_size = 1 << 11;
/*
- * No limit on the number of blocks transferred.
+ * Limit the number of blocks transferred so that we don't overflow
+ * the maximum request size.
*/
- mmc->max_blk_count = mmc->max_req_size;
+ mmc->max_blk_count = mmc->max_req_size >> 11;
spin_lock_init(&host->lock);