drm/radeon/kms: increase lockup detection interval to 10 sec for r100-r500
One subtest of mesa/demos/gltestperf takes 9 seconds to complete, so to prevent an unnecessary gpu reset followed by a hardlock, I am increasing the interval to 10 seconds after which a GPU is considered in a locked-up state. This is on RV530. However, with a little slower GPU, we would surpass the interval easily, so this is not a good fix for gltestperf. Nevertheless, this commit also fixes hardlocks in the applications which render at speed of less than 1 frame per second, where the whole frame consists of only one command stream. The game Tiny & Big is an example. This bar is now lowered to 0.1 fps. Now the question comes down to whether we should (often unsuccessfully) reset the GPU at all? Once we have stable enough drivers, we won't have to. Has the time come already? If possible, this commit should go to stable as well. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
This commit is contained in:
parent
b741be82cf
commit
ec00efb72f
|
@ -2020,18 +2020,7 @@ bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup *l
|
|||
return false;
|
||||
}
|
||||
elapsed = jiffies_to_msecs(cjiffies - lockup->last_jiffies);
|
||||
if (elapsed >= 3000) {
|
||||
/* very likely the improbable case where current
|
||||
* rptr is equal to last recorded, a while ago, rptr
|
||||
* this is more likely a false positive update tracking
|
||||
* information which should force us to be recall at
|
||||
* latter point
|
||||
*/
|
||||
lockup->last_cp_rptr = cp->rptr;
|
||||
lockup->last_jiffies = jiffies;
|
||||
return false;
|
||||
}
|
||||
if (elapsed >= 1000) {
|
||||
if (elapsed >= 10000) {
|
||||
dev_err(rdev->dev, "GPU lockup CP stall for more than %lumsec\n", elapsed);
|
||||
return true;
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue