Sometimes, when watching a video with MPlayer, my machine locks up hard so that I have to turn off power before I can use it again in any way. It doesn’t happen all the time, I have not yet found a way to reproduce it. Unfortunately, I don’t have any logfiles from that. Do you have any suggestions on how to gather logs in such a case? I’m using an Intel DH67GD mainboard with an Intel Core i7-2600K.
You can try netconsole, but using snb lockups so hard that even netconsole doesn't capture any dying whimpers. Are you using mplayer -vo gl or -vo xv? Have you tried with i915.i915_enable_rc6=0? Have you tried with Option "SwapbuffersWait" "false"?
(In reply to comment #1) > Are you using mplayer -vo gl or -vo xv? I am using -vo xv. > Have you tried with i915.i915_enable_rc6=0? I will try that when I reboot the next time (i.e. after the next hard lockup :)). > Have you tried with Option "SwapbuffersWait" "false"? I have enabled that option now. I’ll update this report as soon as the lockup occurs the next time, or if it doesn’t occur for a month or so.
(In reply to comment #2) > > Have you tried with Option "SwapbuffersWait" "false"? > I have enabled that option now. I’ll update this report as soon as the > lockup occurs the next time, or if it doesn’t occur for a month or so. With i915.i915_enable_rc6=0 _and_ Option "SwapbuffersWait" "false" I have not had a single lockup since more than two weeks. Unfortunately, I won’t have access to the box I have been testing this with for the next 2 months, so any further testing will have to wait.
(In reply to comment #3) > (In reply to comment #2) > > > Have you tried with Option "SwapbuffersWait" "false"? > > I have enabled that option now. I’ll update this report as soon as the > > lockup occurs the next time, or if it doesn’t occur for a month or so. > With i915.i915_enable_rc6=0 _and_ Option "SwapbuffersWait" "false" I have > not had a single lockup since more than two weeks. Presumably you still encountered a hard lockup with just Option "SwapbuffersWait" or was a reboot forced in the meantime?
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #2) > > > > Have you tried with Option "SwapbuffersWait" "false"? > > > I have enabled that option now. I’ll update this report as soon as the > > > lockup occurs the next time, or if it doesn’t occur for a month or so. > > With i915.i915_enable_rc6=0 _and_ Option "SwapbuffersWait" "false" I have > > not had a single lockup since more than two weeks. > > Presumably you still encountered a hard lockup with just Option > "SwapbuffersWait" or was a reboot forced in the meantime? Sorry for not being more explicit about this: I have not tried just using SwapbuffersWait extensively, a reboot was indeed forced.
Can you please try with this patch: https://patchwork.kernel.org/patch/2707341/ as it claims to fix some instability with rc6 on SandyBridge?
*** Bug 67856 has been marked as a duplicate of this bug. ***
Timeout. Michael, are you stills seeing the issue with later kernels? There seems to have been some back and forth with the patch referenced by Chris in comment #6 - please try 3.13-rc1 or later.
Nothing has changed. SNB can still randomly hard lock with rc6 and vsync.
Could you please retest with latest drm-intel-nightly?
Hm, another option might be to switch to timeout mode on SNB. With a long enough timeout, we could apply the "emit a primitive" workaround everytime we come out of rc6 and hopefully make things more stable...
I just saw today that there is a recommendation to toggle PMSI_CTL around WAIT_FOR_EVENT in the SNB bspec. That is probably worth trying...
Implemented the bspec recommendation: commit d247cb7d0cdb73736f31612157e47f166af68ba0 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Dec 8 10:07:25 2014 +0000 sna/gen6: Poke PSMI control around WAIT_FOR_EVENT to prevent idling The bspec recommends preventing the hardware from going to sleep around a WAIT_FOR_EVENT, and tells us to use disable sleep bit in PSMI control to accomplish this. References: https://bugs.freedesktop.org/show_bug.cgi?id=62373 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> It's worth another go...
*** Bug 87163 has been marked as a duplicate of this bug. ***
(In reply to Chris Wilson from comment #13) > Implemented the bspec recommendation: > > commit d247cb7d0cdb73736f31612157e47f166af68ba0 > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Mon Dec 8 10:07:25 2014 +0000 > > sna/gen6: Poke PSMI control around WAIT_FOR_EVENT to prevent idling > > The bspec recommends preventing the hardware from going to sleep around > a WAIT_FOR_EVENT, and tells us to use disable sleep bit in PSMI control > to accomplish this. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=62373 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > > It's worth another go... OK so not my bug but with a baytrail J1900N this does not prevent a vaapi hard lock (probably when de-interlacing h/w or s/w so fps = refresh) for me. I only recently started seeing locks - turns out that dri3 was OK for me, but of course it then got disabled by default and I started getting locks. This is with kodi - it seems they recommend 910 as the last stable driver - and I can lock with 311. This was tested with head on this commit, kernel nightly and mesa about a week old.
(In reply to Andy Furniss from comment #15) > I only recently started seeing locks - turns out that dri3 was OK for me, > but of course it then got disabled by default and I started getting locks. It seems I was a bit hasty in calling dri3 OK - I can lock if I try long enough, just that it takes about 20x longer than dri2.
(In reply to Andy Furniss from comment #16) > (In reply to Andy Furniss from comment #15) > > > I only recently started seeing locks - turns out that dri3 was OK for me, > > but of course it then got disabled by default and I started getting locks. > > It seems I was a bit hasty in calling dri3 OK - I can lock if I try long > enough, just that it takes about 20x longer than dri2. Looks like the locks were a mesa issue which is now fixed. I can't point to a commit, but the reason I suspect mesa is that I changed my test case to s/w decode no de-int fps < refresh and could lock/not lock depending on the level of gl output chosen in kodi. dri2 is still < dri3 - neither lock but 2 glitches occasionally. Anyway, I guess I am in the wrong bug, sorry for the noise.
(In reply to Andy Furniss from comment #17) > (In reply to Andy Furniss from comment #16) > > (In reply to Andy Furniss from comment #15) > > > > > I only recently started seeing locks - turns out that dri3 was OK for me, > > > but of course it then got disabled by default and I started getting locks. > > > > It seems I was a bit hasty in calling dri3 OK - I can lock if I try long > > enough, just that it takes about 20x longer than dri2. > > Looks like the locks were a mesa issue which is now fixed. Just for completeness - it wasn't mesa, it's just hard to call stable/not when even on unstable runs of 12 hrs are possible. Current thinking is Kernel > 3.16.x is unstable on baytrail, kodi developers also saying this, so not just me.
Waiting for feedback in order to change the status.
No feedback, closing
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.