Between 3.12 and drm-intel-nightly, we loose coherency after resume. ring->get_seqno() = 0xffffeffe, but hws[0x20] = 0xfffff001 so the gpu is advancing and writing to the hws page, but the seqno is not visible by the CPU - the cache snooping is bust. For SNB+, we had a similar issue which required flushing the ring TLBs. Bisect in progress.
Bisect says bug does not exist. Grr :< Next guess it is a config option that changed recently.
Found it, CONFIG_DRM_I915_FBDEV.
(In reply to comment #2) > Found it, CONFIG_DRM_I915_FBDEV. Weird stuff. Daniel introduced that sucker, so I'm throwing the bug in his direction.
On a hunch I expect the bios to stomp on the lower end of the gtt/stolen. Can you please test what happens - with Jesse's fb takeover patches (pls double-check that we indeed wrap the fb correctly) - and when disabling stolen if the fb wrap patches don't help. Finally is the bios somehow resuming the display hw for us already or are all pipes off on takeover from resume?
(In reply to comment #4) > On a hunch I expect the bios to stomp on the lower end of the gtt/stolen. > Can you please test what happens > - with Jesse's fb takeover patches (pls double-check that we indeed wrap the > fb correctly) They already were included. > - and when disabling stolen if the fb wrap patches don't help. There wasn't stolen available at the introduction of the bug. > Finally is the bios somehow resuming the display hw for us already or are > all pipes off on takeover from resume? Nope. Back to testing and this is gone on my latest ring init routines. I might get round to seeing if it was fixed in the meantime...
Chris, can we close this?
(In reply to Rodrigo Vivi from comment #6) > Chris, can we close this?
Very hard to say since the machine now lockups up entirely with !FBDEV...
Created attachment 116169 [details] /sys/class/drm/card0/error shortened
I have a similar problem here... GPU hangs after resume. [ 1710.007256] [drm] stuck on render ring [ 1710.008312] [drm] GPU HANG: ecode 0:0x772a3d58, in Xorg [1560], reason: Ring hung, action: reset [ 1710.008316] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace. [ 1710.008317] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel [ 1710.008320] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue. [ 1710.008322] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it. [ 1710.008323] [drm] GPU crash dump saved to /sys/class/drm/card0/error This is happening on a Mint Linux with cinnamon. I'm not sure if this is still in the current version a problem but it accrues in 2:2.99.910-0ubuntu1.6 of xserver-xorg-video-intel. Constantin
(In reply to Constantin Zankl from comment #10) > I have a similar problem here... GPU hangs after resume. Similar but very unlikely to have FBDEV disabled, so please please file a new bug with an error state.
Ah. New lead. init_bios() doesn't take a pin for the info->screen.base mapping and so on resume the fbcon is no longer present and the memset(info->screen.base, 0, info->screen.size) tramples over random buffers. Oops, oops, oops.
Hmm, or sadly that is not this bug, just another one.
Is this still an issue? There have been no updates for about 8 months.
I actually suspect I've finally fixed it with "avoid ringbuffers at offset 0". Just don't regularly do non-default testing on my pnv.
(In reply to Chris Wilson from comment #15) > I actually suspect I've finally fixed it with "avoid ringbuffers at offset > 0". Just don't regularly do non-default testing on my pnv. Can you please confirm so we can change the status? Thanks!
Chris I will close this bug and if the problem still exist open a new bug
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.