diff options
author | Brian Norris <[email protected]> | 2016-03-04 17:19:23 -0800 |
---|---|---|
committer | Brian Norris <[email protected]> | 2016-03-07 13:51:11 -0800 |
commit | 9ebfdf5b18493f338237ef9861a555c2f79b0c17 (patch) | |
tree | 0e1c2041a5cad1919cca33f3153de9e932bec986 /tools/perf/scripts/python/call-graph-from-postgresql.py | |
parent | 3707b2c3d21f7c9f8c6aadba79ef012f0bbad10c (diff) |
mtd: nand: check status before reporting timeout
In commit b70af9bef49b ("mtd: nand: increase ready wait timeout and
report timeouts"), we increased the likelihood of scheduling during
nand_wait(). This makes us more likely to hit the time_before(...)
condition, since a lot of time may pass before we get scheduled again.
Now, the loop was already buggy, since we don't check if the NAND is
ready after exiting the loop; we simply print out a timeout warning. Fix
this by doing a final status check before printing a timeout message.
This isn't actually a critical bug, since the only effect is a false
warning print. But too many prints never hurt anyone, did they? :)
Side note: perhaps I'm not smart enough, but I'm not sure what the best
policy is for this kind of loop; do we busy loop (i.e., no
cond_resched()) to keep the lowest I/O latency (it's not great if the
resched is delaying Richard's system ~400ms)? Or do we allow
rescheduling, to play nice with the rest of the system (since some
operations can take quite a while)?
Reported-by: Richard Weinberger <[email protected]>
Signed-off-by: Brian Norris <[email protected]>
Reviewed-by: Boris Brezillon <[email protected]>
Reviewed-by: Richard Weinberger <[email protected]>
Reviewed-by: Harvey Hunt <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/call-graph-from-postgresql.py')
0 files changed, 0 insertions, 0 deletions