Souza, Jose schreef op vr 09-08-2019 om 17:16 [+]:
> Fix released on Linux 5.2.8
Linux 5.2.8 doesn't have the pretty obvious freezes so this fix works for me
too. Thanks for letting me know!
Paul Bolle
Fix released on Linux 5.2.8
On Wed, 2019-07-24 at 22:39 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op wo 24-07-2019 om 20:27 [+]:
> > We fixed the patch instead of revert it, it is merged on drm-tip
> > and on
> > his way to linux-stable.
>
> That should be (drm-tip) commit
On Wed, 2019-07-24 at 22:39 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op wo 24-07-2019 om 20:27 [+]:
> > We fixed the patch instead of revert it, it is merged on drm-tip
> > and on
> > his way to linux-stable.
>
> That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt:
Hi Jose,
Souza, Jose schreef op wo 24-07-2019 om 20:27 [+]:
> We fixed the patch instead of revert it, it is merged on drm-tip and on
> his way to linux-stable.
That should be (drm-tip) commit b5ea9c933700 ("drm/i915/vbt: Fix VBT parsing
for the PSR section"). Correct?
> Huge thanks again
Hi Paul
We fixed the patch instead of revert it, it is merged on drm-tip and on
his way to linux-stable.
Huge thanks again
On Wed, 2019-07-24 at 21:23 +0200, Paul Bolle wrote:
> Hi Jose,
>
> James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]:
> > On Wed, 2019-07-17 at 23:27 +0200, Paul
Hi Jose,
James Bottomley schreef op do 18-07-2019 om 06:29 [+0900]:
> On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> > I've just reached a day of uptime with your revert. (The proper
> > uptime is just a fraction of a day, this being a laptop.) Anyhow, no
> > screen freezes occurred
On Wed, 2019-07-17 at 23:27 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op di 16-07-2019 om 16:32 [+]:
> > Paul and James could you test this final solution(at least for
> > 5.2)? Please revert the hack patch and apply this one.
>
> I've just reached a day of uptime with your
Hi Jose,
Souza, Jose schreef op di 16-07-2019 om 16:32 [+]:
> Paul and James could you test this final solution(at least for 5.2)?
> Please revert the hack patch and apply this one.
I've just reached a day of uptime with your revert. (The proper uptime is just
a fraction of a day, this being
Thanks Paul
Paul and James could you test this final solution(at least for 5.2)?
Please revert the hack patch and apply this one.
Thanks
On Mon, 2019-07-15 at 23:34 +0200, Paul Bolle wrote:
> Hi Jose,
>
> Souza, Jose schreef op ma 15-07-2019 om 21:03 [+]:
> > So the issue did not happened
Hi Jose,
Souza, Jose schreef op ma 15-07-2019 om 21:03 [+]:
> So the issue did not happened again with the patch applied?
Not in the three days that I've been running 5.2 kernels with the hack applied
(so that should be about twelve hours of proper uptime).
> If you still have the kernel
Hi James and Paul
So the issue did not happened again with the patch applied?
If you still have the kernel 5.1 installed could you share your
/sys/kernel/debug/dri/0/i915_edp_psr_status with the older kernel?
We want to check if training values changed between kernel versions.
On Fri,
James Bottomley schreef op vr 12-07-2019 om 07:19 [-0700]:
> It has survived 6h without manifesting the regression. Starting again
> to try a whole day.
And I'm currently at four hours without a screen freeze. Which is much, much
longer than I was able to achieve without the hack applied.
Paul
On Thu, 2019-07-11 at 16:40 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 23:28 +, Souza, Jose wrote:
> > On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote:
> > > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> > > > On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote:
Paul Bolle schreef op do 11-07-2019 om 13:20 [+0200]:
> Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]:
> > Temporary workaround would be to set i915.enable_psr=0
>
> That workaround seems to work for me. Over an hour of uptime without any
> screen freezes.
May or may not be related: 24
On Thu, 2019-07-11 at 23:28 +, Souza, Jose wrote:
> On Fri, 2019-07-12 at 01:03 +0200, Paul Bolle wrote:
> > James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> > > On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote:
> > > > It eventually comes back from screen freeze? Like moving
James Bottomley schreef op do 11-07-2019 om 15:38 [-0700]:
> On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote:
> > It eventually comes back from screen freeze? Like moving the mouse or
> > typing brings it back?
>
> No, it seems to be frozen for all time (at least until I got bored
> waiting,
On Thu, 2019-07-11 at 22:26 +, Souza, Jose wrote:
> On Thu, 2019-07-11 at 14:57 -0700, James Bottomley wrote:
> > On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote:
> > > I've also updated to the released 5.2 kernel and am running with
> > > the
> > > debug parameters you requested ...
On Thu, 2019-07-11 at 14:57 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 13:28 -0700, James Bottomley wrote:
> > I've also updated to the released 5.2 kernel and am running with
> > the
> > debug parameters you requested ... but so far no reproduction.
>
> OK, it's happened. I've
On Thu, 2019-07-11 at 20:25 +, Souza, Jose wrote:
> On Thu, 2019-07-11 at 13:11 -0700, James Bottomley wrote:
> > On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> > > Quoting James Bottomley (2019-06-29 19:56:52)
> > > > The symptoms are really weird: the screen image is locked in
> >
On Thu, 2019-07-11 at 13:11 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> > Quoting James Bottomley (2019-06-29 19:56:52)
> > > The symptoms are really weird: the screen image is locked in
> > > place. The machine is still functional and if I log in over
On Thu, 2019-07-11 at 10:29 +0100, Chris Wilson wrote:
> Quoting James Bottomley (2019-06-29 19:56:52)
> > The symptoms are really weird: the screen image is locked in
> > place. The machine is still functional and if I log in over the
> > network can do anything I like, including killing the X
Hi James and Paul
Could you share a dmesg output of your system after the bug occur with
this kernel parameters "drm.debug=0x1e log_buf_len=4M"? Also the output
of /sys/kernel/debug/dri/0/i915_edp_psr_status
Thanks
On Wed, 2019-07-10 at 15:18 -0700, James Bottomley wrote:
> On Wed, 2019-07-10
Chris Wilson schreef op do 11-07-2019 om 10:29 [+0100]:
> Temporary workaround would be to set i915.enable_psr=0
That workaround seems to work for me. Over an hour of uptime without any
screen freezes.
(I first tried fiddling with /sys/module/i915/parameters/enable_psr at
runtime, but that
Quoting James Bottomley (2019-06-29 19:56:52)
> The symptoms are really weird: the screen image is locked in place.
> The machine is still functional and if I log in over the network I can
> do anything I like, including killing the X server and the display will
> never alter. It also seems that
On Wed, 2019-07-10 at 23:59 +0200, Paul Bolle wrote:
> James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]:
> > I can get back to it this afternoon, when I'm done with the meeting
> > requirements and doing other dev stuff.
>
> I've started bisecting using your suggestion of that drm merge:
James Bottomley schreef op wo 10-07-2019 om 10:35 [-0700]:
> I can get back to it this afternoon, when I'm done with the meeting
> requirements and doing other dev stuff.
I've started bisecting using your suggestion of that drm merge:
$ git bisect log
git bisect start
# good:
On Wed, 2019-07-10 at 18:45 +0200, Paul Bolle wrote:
> James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]:
> > You seem to be getting it to happen much more often than I can.
> > Last
> > night, on the below pull request it took me a good hour to see the
> > freeze.
>
> Yes. Sometimes
James Bottomley schreef op wo 10-07-2019 om 09:32 [-0700]:
> You seem to be getting it to happen much more often than I can. Last
> night, on the below pull request it took me a good hour to see the
> freeze.
Yes. Sometimes within a minute of resuming. Typing stuff into evolution seems
to help
On Wed, 2019-07-10 at 18:16 +0200, Paul Bolle wrote:
> Hi James,
>
> James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]:
> > I've confirmed that 5.1 doesn't have the regression and I'm now
> > trying to bisect the 5.2 merge window, but since the problem takes
> > quite a while to manifest
Hi James,
James Bottomley schreef op wo 10-07-2019 om 08:01 [-0700]:
> I've confirmed that 5.1 doesn't have the regression and I'm now trying
> to bisect the 5.2 merge window, but since the problem takes quite a
> while to manifest this will take some time. Any hints about specific
> patches
On Sat, 2019-06-29 at 11:56 -0700, James Bottomley wrote:
> The symptoms are really weird: the screen image is locked in place.
> The machine is still functional and if I log in over the network I
> can do anything I like, including killing the X server and the
> display will never alter. It
Hi James,
James Bottomley schreef op za 29-06-2019 om 11:56 [-0700]:
> The symptoms are really weird: the screen image is locked in place.
> The machine is still functional and if I log in over the network I can
> do anything I like, including killing the X server and the display will
> never
The symptoms are really weird: the screen image is locked in place.
The machine is still functional and if I log in over the network I can
do anything I like, including killing the X server and the display will
never alter. It also seems that the system is accepting keyboard input
because when
33 matches
Mail list logo
