hibernate random memory corruption, workaround i915.modeset=0

Stanislaw Gruszka sgruszka at redhat.com
Wed Mar 21 08:14:49 PDT 2012


On Mon, Mar 19, 2012 at 10:21:28AM -0700, Keith Packard wrote:
> <#part sign=pgpmime>
> On Mon, 19 Mar 2012 15:53:54 +0100, Stanislaw Gruszka <sgruszka at redhat.com> wrote:
> 
> > Keith, is there a chance that this bug can be fixed by i915 team?
> 
> Yes, I'm working on figuring out how to actually reproduce this and then
> work on a few work-arounds.

This must be hardware dependent then, yesterday and today I tried to
reproduce on Lenovo T60 with:

00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03)

and there is no sign of corruption, I double checked if slab poisoning
is enabled.

> > If not, can we disable hibernate on i915 with modeset=1 and add
> > module option, which enable it for those who want to risk?
> 
> I'd love to know if disabling modeset on just the booting kernel helps;
> leaving the resuming kernel with modeset=1. I haven't been able to
> reproduce this locally yet to test this theory though.

On Lenovo T500 with:

00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07)

that is the case. Script attached on previous email trigger corruption
with modeset=1 (on various older and newer kernels) in less then 20
iterations. There is no corruption after 100 iterations if
i915.modeset=0 parameter is used. Some users on RH bugzilla confirmed
that workaround as well.

If you want list of more i915 adapters where the problem happens, I can
check in our bugzilla and provide it.

Thanks
Stanislaw 


More information about the dri-devel mailing list