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>
if some board don't use a real fuel gauge, set virtual_power
in dts, the battery driver will report virtural soc to user space
Signed-off-by: Andy Yan <yxj@rock-chips.com>
Signed-off-by: Jianhong Chen <chenjh@rock-chips.com>
The following commit introduced a bug when checking for zero length extent
5946d08 ext4: check for overlapping extents in ext4_valid_extent_entries()
Zero length extent could pass the check if lblock is zero.
Adding the explicit check for zero length back.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: stable@vger.kernel.org
bug in previous commit, auto-freq flag disable in all the
platform.
raise freq to 600MHz when 4k avc video decode, could not
get the 500 MHz frequency from current clock pll.
Signed-off-by: Alpha Lin <alpha.lin@rock-chips.com>
