We set wrong discard timeout limitation for erase event
which exceed that block layer does. And jbd warning
can be observed like blow:
INFO: task update_binary:151 blocked for more than 10 seconds.
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
update_binary D ffffffc000085674 0 151 134 0x00400008
Call trace:
[<ffffffc000085674>] __switch_to+0x80/0x8c
[<ffffffc00082cb28>] __schedule+0x4e0/0x6f4
[<ffffffc00082cda0>] schedule+0x64/0x70
[<ffffffc00082aea0>] schedule_timeout+0x28/0x250
[<ffffffc00082d2ac>] io_schedule_timeout+0x6c/0xa8
[<ffffffc00082d37c>] wait_for_common_io.constprop.111+0x94/0x114
[<ffffffc00082d41c>] wait_for_completion_io+0xc/0x18
[<ffffffc0002ffb08>] blkdev_issue_discard+0x1e0/0x214
[<ffffffc000300630>] blkdev_ioctl+0x2d0/0x708
[<ffffffc00030d52c>] compat_blkdev_ioctl+0x464/0x5ec
[<ffffffc0001bdf0c>] compat_sys_ioctl+0x104/0x1e8
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Use kernel.h macro definition.
Thanks to Julia Lawall for Coccinelle scripting support.
Signed-off-by: Fabian Frederick <fabf@skynet.be>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Rockchips' platform contain ridiculous and closely
w/o maintained macro in pcl to pave the bumpy way for
other drivers to distinguish VALUE_PULL_UPDOWN_DISABLE
from VALUE_PULL_DISABLE.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Xiao Yao <xiaoyao@rock-chips.com>
Tested-by: Xiao Yao <xiaoyao@rock-chips.com>
Cc: Roger Hu <roger.hu@rock-chips.com>
Communication scenario definitely should fail during
tuning procedure. Already does it reset controller, so
we don't need executing recovery for that case.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
The current handler of MMC_BLK_CMD_ERR in mmc_blk_issue_rw_rq function
may cause new coming request permanent missing when the ongoing
request (previoulsy started) complete end.
The problem scenario is as follows:
(1) Request A is ongoing;
(2) Request B arrived, and finally mmc_blk_issue_rw_rq() is called;
(3) Request A encounters the MMC_BLK_CMD_ERR error;
(4) In the error handling of MMC_BLK_CMD_ERR, suppose mmc_blk_cmd_err()
end request A completed and return zero. Continue the error handling,
suppose mmc_blk_reset() reset device success;
(5) Continue the execution, while loop completed because variable ret
is zero now;
(6) Finally, mmc_blk_issue_rw_rq() return without processing request B.
The process related to the missing request may wait that IO request
complete forever, possibly crashing the application or hanging the system.
Fix this issue by starting new request when reset success.
Signed-off-by: Ding Wang <justin.wang@spreadtrum.com>
Fixes: 67716327ee ("mmc: block: add eMMC hardware reset support")
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
After dequeue a rq from blk and a accidental rq missing makes
bq->queue fails to fetch blk_rq again since !rq w/o been done.
Whatsoever was that, MUST ensure a schedule mechanisam to break
the dead loop, and issue the missing one again. We observe this
problem, all processes calling aio page writeback or commiting
journal were confined in io_schedule waiting for previous blk rq
to be completed, and cause os stucked.
page:c1337420 count:3 mapcount:0 mapping:dc8fdc34 index:0x502
page flags: 0x4000286c(referenced|uptodate|lru|active|private|writeback)
sleep_on_page: inode: dc8fdb58, 119091
CPU: 3 PID: 199 Comm: abc Not tainted 3.10.0 #298
[<c0013e44>] (unwind_backtrace+0x0/0xe0) from [<c001175c>] (show_stack+0x10/0x14)
[<c001175c>] (show_stack+0x10/0x14) from [<c00cadb8>] (sleep_on_page+0x6c/0x8c)
[<c00cadb8>] (sleep_on_page+0x6c/0x8c) from [<c0769a80>] (__wait_on_bit+0x54/0xa0)
[<c0769a80>] (__wait_on_bit+0x54/0xa0) from [<c00ca88c>] (wait_on_page_bit+0x8c/0x9c)
[<c00ca88c>] (wait_on_page_bit+0x8c/0x9c) from [<c00ca954>] (filemap_fdatawait_range+0x6c/0x110)
[<c00ca954>] (filemap_fdatawait_range+0x6c/0x110) from [<c00cbd8c>] (filemap_write_and_wait_range+0x54/0x78)
[<c00cbd8c>] (filemap_write_and_wait_range+0x54/0x78) from [<c0182e14>] (ext4_sync_file+0xdc/0x308)
[<c0182e14>] (ext4_sync_file+0xdc/0x308) from [<c01305f8>] (vfs_fsync_range+0x34/0x44)
[<c01305f8>] (vfs_fsync_range+0x34/0x44) from [<c01306b0>] (generic_write_sync+0x80/0x88)
[<c01306b0>] (generic_write_sync+0x80/0x88) from [<c00cc3fc>] (generic_file_aio_write+0xa0/0xb0)
[<c00cc3fc>] (generic_file_aio_write+0xa0/0xb0) from [<c0109198>] (do_sync_write+0x74/0x98)
[<c0109198>] (do_sync_write+0x74/0x98) from [<c0109ab8>] (vfs_write+0xd4/0x16c)
[<c0109ab8>] (vfs_write+0xd4/0x16c) from [<c0109df8>] (SyS_write+0x3c/0x60)
[<c0109df8>] (SyS_write+0x3c/0x60) from [<c000da00>] (ret_fast_syscall+0x0/0x30)
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Tested-by: Meiyou Chen <cmy@rock-chips.com>
This commit comes from community but not upstreram.
We cannot wait for picking up such a great movement without
upstream admit it. We just take a light way to merge it and
minimize the change.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: xiaoyao <xiaoyao@rock-chips.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Totally new tuning policy for rockchip mhsc
merging from upstream and sustainable experiments
conducted by massive test using tier one customers's board.
This fine ajustment might be more durable and readable.
Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
Signed-off-by: Xiao Yao <xiaoyao@rock-chips.com>
Test-by: Xiao Yao <xiaoyao@rock-chips.com>
if the system boot with charger online, use it
as init state for power_supply_register
Signed-off-by: Andy Yan <yxj@rock-chips.com>
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
rk81x battery may get invalid value when resume from suspend,
if the voltage get from adc is lower than INVALID_VOL_THRESD,
we consider it as invalid and filter it
Signed-off-by: Andy Yan <yxj@rock-chips.com>
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
