I suggest to keep the bug still open for quite some time.
We all know (and my stress-testing underlines that) that this is a duct-tape
and not a real fix.
I am still planning to spend some more time on this.
If you hate having this bug assigned to Intel as you believe there's not
much that you c
(In reply to comment #95)
> No more failures on boot or resume here so far, using Jiri's one-liner. Will
> see if this is consistent.
>
> Thanks all! :-)
Thanks for testing. Please bear in mind though that this is a workaround
that makes the bug less likely to happen, but it's still possible that
I'll be having the affected notebook with me next week in Chicago on
Kernel Summit in case it'd help you with debugging ... ?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1339939
Title:
(In reply to comment #86)
> It's still very strange that HEAD starts to move once we've initialized the
> ring. So it seems like we can properly reset it, but then it goes banas ...
>
> More dmesgs from different machines with that frob+debug patch definitely
> appreciated.
I will provide you wit
(In reply to comment #85)
> The intel_ring_setup_status_page() does a posting read anyway, so it is not
> an ordering issue. So this is back in the magic read territory, can you try
> with a msleep(10) instead of the read just to confirm that it is the read
> doing the trick and not an extra delay?
(In reply to comment #90)
> Jiri, can you please submit your patch from commment #83 to upstream? It's
> not perfect, but ducttape is good, so I'll merge it as an interim solution.
I can definitely do that if that's your preferred course of action.
This will mean that smaller number of people wil
(In reply to comment #92)
> Created attachment 104227 [details] [review]
> head start before enabling
>
> Another crazy idea. Looking at logs and Jiri's patch, the critical step
> seems to be when we set the valid bit. Let's see what happens if we give the
> ring a headstart, hopefully catching th
Created attachment 104226
dmesg with the frob+debug patch from comment #80 showing the issue
Finally after many suspend-resume cycles, the issue triggered also with
Daniel's frob+debug patch from comment #80.
Resulting dmesg attached.
--
You received this bug notification because you are a memb
Okay, after 31 suspend-resume cycles, the problem appeared again (while
without the patch, it triggers with 100% reliability) with patch from comment
#83 applied.
So it's not a complete fix, it just makes the problem much less likely
to happen.
--
You received this bug notification because y
Created attachment 104224
[PATCH] drm/i915: read HEAD register back in init_ring_common() to enforce
ordering
Ok, this is the minimal change that reliably makes my system behave
properly again finally (woohoo!).
Chris, Daniel, what do you think?
--
You received this bug notification because yo
Created attachment 104216
dmesg of 3.16 + patch from comment #80
Woohooo! Daniel, your patch from comment #80 seems to make the bug go
away!
Attached is dmesg from 3.16 + patch from comment #80. No more ring
initialization errors in dmesg, everything working properly.
I'll do a couple more suspe
Created attachment 104212
dmesg with patch from comment #80
Here is a dmesg from two suspend-resume cycles with Daniel's patch from
comment #80 (applied on top of all previous patches from Chris).
There seems to be a change in behavior!
Interestingly, I am not seeing
[drm:init_ring_common]
3.16 still doesn't work for me exactly the same way as before.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1339939
Title:
[Lenovo ThinkPad T400] intel graphics fail after suspend with
13 matches
Mail list logo
