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 +0000, 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, which was probably 20 minutes). Even if I reboot the
> > machine,
> > the current screen state stays until the system powers off.
>
> As I mentioned earlier, a suspend/resume cycle unfreezes the screen.
>
> And I seem to remember that, if the gnome screen-locking eventually
> kicks in,
> unlocking the screen still works, as the screen then isn't frozen
> anymore.
>
> Thanks,
Thanks for all the information Paul.
Could test with the patch attached?
If the issue happens again could send the output of:
/sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status
/sys/kernel/debug/dri/0/i915_edp_psr_status
Thanks so much for all the help
>
>
> Paul Bolle
>
On Thu, 2019-07-11 at 23:28 +0000, 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 +0000, 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, which was probably 20 minutes). Even if I reboot
> > > the machine, the current screen state stays until the system
> > > powers off.
> >
> > As I mentioned earlier, a suspend/resume cycle unfreezes the
> > screen.
> >
> > And I seem to remember that, if the gnome screen-locking eventually
> > kicks in, unlocking the screen still works, as the screen then
> > isn't frozen anymore.
> >
> > Thanks,
>
> Thanks for all the information Paul.
>
> Could test with the patch attached?
Applied and running with it now.
> If the issue happens again could send the output of:
>
> /sys/kernel/debug/dri/0/eDP-1/i915_psr_sink_status
> /sys/kernel/debug/dri/0/i915_edp_psr_status
>
> Thanks so much for all the help
Sure,
James
On Thu, 2019-07-11 at 16:40 -0700, James Bottomley wrote:
> On Thu, 2019-07-11 at 23:28 +0000, 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 +0000, 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, which was probably 20 minutes). Even if I
> > > > reboot the machine, the current screen state stays until the
> > > > system powers off.
> > >
> > > As I mentioned earlier, a suspend/resume cycle unfreezes the
> > > screen.
> > >
> > > And I seem to remember that, if the gnome screen-locking
> > > eventually kicks in, unlocking the screen still works, as the
> > > screen then isn't frozen anymore.
> > >
> > > Thanks,
> >
> > Thanks for all the information Paul.
> >
> > Could test with the patch attached?
>
> Applied and running with it now.
It has survived 6h without manifesting the regression. Starting again
to try a whole day.
James
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 Bolle
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, 2019-07-12 at 16:28 +0200, Paul Bolle wrote:
> 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 Bolle
>
Hi Jose,
Souza, Jose schreef op ma 15-07-2019 om 21:03 [+0000]:
> 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 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.
Sure. On 5.1.17 I get:
Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: enabled [0x81f00626]
Source PSR status: IDLE [0x040b0001]
Busy frontbuffer bits: 0x00000000
And, in case you need it, on 5.2.1+hack I get:
Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: enabled [0x81f00626]
Source PSR status: IDLE [0x04030006]
Busy frontbuffer bits: 0x00000000
Hope this helps,
Paul
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 [+0000]:
> > 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 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.
>
> Sure. On 5.1.17 I get:
> Sink support: yes [0x01]
> PSR mode: PSR1 enabled
> Source PSR ctl: enabled [0x81f00626]
> Source PSR status: IDLE [0x040b0001]
> Busy frontbuffer bits: 0x00000000
>
> And, in case you need it, on 5.2.1+hack I get:
> Sink support: yes [0x01]
> PSR mode: PSR1 enabled
> Source PSR ctl: enabled [0x81f00626]
> Source PSR status: IDLE [0x04030006]
> Busy frontbuffer bits: 0x00000000
>
> Hope this helps,
>
>
> Paul
>
Hi Jose,
Souza, Jose schreef op di 16-07-2019 om 16:32 [+0000]:
> 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 a laptop.) Anyhow, no screen freezes occurred
during this day.
So feel free to add my Tested-by tag to your revert. But please don't forget
that James earned a Reported-by tag.
Thanks,
Paul Bolle
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 [+0000]:
> > 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 a laptop.) Anyhow, no
> screen freezes occurred during this day.
I'm afraid my status is that I'm in Tokyo doing conference
presentations (and kernel demos) so I'm a bit reluctant to mess with my
setup until I finish everything on Friday, but I will test it after
then, promise.
> So feel free to add my Tested-by tag to your revert. But please don't
> forget that James earned a Reported-by tag.
Thanks,
James
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 during this day.
>
> I'm afraid my status is that I'm in Tokyo doing conference
> presentations (and kernel demos) so I'm a bit reluctant to mess with my
> setup until I finish everything on Friday, but I will test it after
> then, promise.
By now I'm testing this for a week (currently on top of 5.2.2). Still no
freezes whatsoever.
So what's the status of this revert? Unless this is something pretty obscure
that for some odd reason only James and I are able to hit it would be nice to
get this into stable before the main distros switch over to 5.2.y.
Thanks,
Paul Bolle