On Tue, 29 May 2012 19:41:37 -0700, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Mon, May 28, 2012 at 12:06 AM, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: > > > > No, the i915_error_state had everything I needed to see. It is the old > > ddx bug that was hardcoding a maximum relocation address that never > > corresponded with an actual hw limit. As soon we try to use memory above > > that value, the GPU decides not to listen to us any more. > > > > Fixed in xf86-video-intel 2.14.901 > > I really don't think that's the case. > > I have run the F14 X server for a *long* time without these issues on > this machine, and today I now got a second GPU hang with the current > git tree. I was in the middle of just writing an email in chrome, > nothing fancy going on at all. > > So please please *please* take a second look. Because I think it's > triggered by the i915 changes, or you undid a workaround that used to > work fine. >From the error-state: 0x0314e050: 0x61010006: STATE_BASE_ADDRESS 0x0314e054: 0x00000001: general state base address 0x00000000 0x0314e058: 0x00000001: surface state base address 0x00000000 0x0314e05c: 0x00000001: indirect state base address 0x00000000 0x0314e060: 0x00000001: instruction state base address 0x00000000 0x0314e064: 0x10000001: general state upper bound 0x10000000 0x0314e068: 0x10000001: indirect state upper bound 0x10000000 0x0314e06c: 0x10000001: instruction state upper bound 0x10000000 And if we look at some of the other auxiliary instructions buffers sent along with the batch: 0314e000 16384 0048 0000 000ab700 dirty purgeable render uncached ... 11e30000 4096 0011 0000 000ab700 purgeable render uncached 11e2b000 4096 0011 0000 000ab700 purgeable render uncached 10e43000 4096 0011 0000 000ab700 render uncached 10e44000 4096 0011 0000 000ab700 purgeable render uncached 0x10 being the instruction domain for a total of about 20 instruction buffers referenced from that batch above the upper bound (and in particular appears to have been the first batch to use addresses above 256M). This batch fits the modus operandi of the bug that was fixed in 2.14.901, it would seem sensible to address the known issue first. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
