Created attachment 96065 [details] error state Unlike with #75736 here the system works mostly fine after the initial hesitation (gpu reset?), only visible thing is corrupt or missing text on the lightdm login screen. Restarting lightdm makes it look fine, and there is no new hang either. drm-intel-next at e19b91371429
The bug looks familiar. ACTHD is garbage, nowhere near where MI_BATCH_BUFFER_START should have sent it, which is very much like bug 75477. Maybe try i915.enable_ppgtt=0 (Ben says it currently is in his bdw branch).
with i915.enable_ppgtt=0 I don't get a hang and texts on lightdm greeter looks fine. weird thing is that a backport module for 3.13 based on the same branch doesn't see this issue.. I need to double-check the kernels used
verified that it happens with a mainline build from http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-intel-next/2014-03-19-trusty/ and doesn't with i915.enable_ppgtt=0
You can also try Section "Device" Option "VSync" "off" EndSection to test whether it is the use of secure-batches.
with that option and without i915.enable_ppgtt=0 I get a gpu reset but texts look good on lightdm.
drm/i915: Broadwell expands ACTHD to 64bit on top of dinq fixes the text corruption
so I'm just confused about the corruption, I guess it got fixed in dinq at some point.. I don't have a 'clean' build of it available, but RC6 + the ACTHD patch added and it's not there. anyway, will attach a new error state from this kernel
Created attachment 96164 [details] error state v2
Chris, does the junk after the MI_BATCH_BUFFER_END make sense to you?
Yup, it's just an embedded vertex buffer and surface state, all checks out as being self-consistent.
(In reply to comment #10) > Yup, it's just an embedded vertex buffer and surface state, all checks out > as being self-consistent. So where is the final MI_NOOP? I thought we always need one of those.
No.
Timo, is this with RC6 patches?
it happens with or without, the trace is from a kernel with RC6 patches I believe
Can you please get an error state without RC6, just to make certain. There are some oddities here which I want to make sure aren't related to RC6. Also Damien did post a fix that can prevent hangs today. It should be merged to -next with Cc: stable, if you want to try.
it's fine on bdw-backports at least, no gpu hang. I'll test dinq again later..
Created attachment 97334 [details] error state v3 this is from 3.15-rc1, default boot options
same with rc3, and logging in the unity session doesn't finish since compiz fails to start due to this
Created attachment 98771 [details] error state with a patch on top of bdw-backports this is with the latest patch to fix 77587 on bdw-backports
I don't get that hang with v3.15-rc4 if ppgtt is disabled (=0). Also, Ben's 'broadwell' branch doesn't suffer from this.
disabling ppgtt doesn't work for bdw-backports though
So this works fine on current drm-intel-next-queued and is resolved after cherry-picking 9d0a6fa6c5e618bd978d625a215dc4a240ba3b3c to 3.15-rc5. It doesn't do the trick on bdw-backports though, so I'll just give up on that and rebase..
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.