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 it freezes I can cat information to a file (if the mouse
was over an xterm) and verify over the network the file contents.
Nothing unusual appears in dmesg when the lockup happens.
The last kernel I booted successfully on the system was 5.0, so I'll
try compiling 5.1 to narrow down the changes.
James
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 alter. It also seems that the system is accepting keyboard input
> because when it freezes I can cat information to a file (if the mouse
> was over an xterm) and verify over the network the file contents.
> Nothing unusual appears in dmesg when the lockup happens.
>
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.
Upgrading to 5.2 (from 5.1.y) on a "Dell XPS 13 9350" (is that a skylake too?)
showed similar symptoms. There's no pattern to the freezes that I can see.
They're rather frequent too (think every few minutes). Eg, two freezes while
composing this message!
My totally silly workaround is suspending (via Fn + Insert) and resuming.
Did you manage to narrow this any further?
Thanks,
Paul Bolle
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 also seems that the system is accepting
> keyboard input because when it freezes I can cat information to a
> file (if the mouse was over an xterm) and verify over the network the
> file contents. Nothing unusual appears in dmesg when the lockup
> happens.
>
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.
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 that might be the problem would be welcome.
James
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 that might be the problem would be welcome.
(Perhaps my message of yesterday never reached you.)
It seems I hit this problem quite easily. Bisecting v5.1..v5.2 could be a real
chore, so perhaps we could coordinate efforts (off-list)?
Thanks,
Paul Bolle
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 this will take some time. Any hints
> > about specific patches that might be the problem would be welcome.
>
> (Perhaps my message of yesterday never reached you.)
No, sorry, if the list is followup to list, I'm not subscribed. I see
it now I look in the archives, though.
---
> Upgrading to 5.2 (from 5.1.y) on a "Dell XPS 13 9350" (is that a
> skylake too?)
I believe so. My laptop is a 9350. I believe they're the earliest
skylake produced.
> showed similar symptoms. There's no pattern to the freezes that I
> can see. They're rather frequent too (think every few minutes). Eg,
> two freezes while composing this message!
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.
---
> It seems I hit this problem quite easily. Bisecting v5.1..v5.2 could
> be a real chore, so perhaps we could coordinate efforts (off-list)?
Sure, my current testing indicates it's somewhere inside this pull
request:
Merge: 89c3b37af87e eb85d03e01c3
Author: Linus Torvalds <[email protected]>
Date: Wed May 8 21:35:19 2019 -0700
Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
Pull drm updates from Dave Airlie:
So I was about to test out the i915 changes in that but since my laptop
is what I use for daily work, it's a bit hard (can't freeze up on video
calls for instance).
James
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 with triggering this. It's all a bit mysterious, but this message
alone frooze my laptop a few times. Seriously!
> Sure, my current testing indicates it's somewhere inside this pull
> request:
>
> Merge: 89c3b37af87e eb85d03e01c3
> Author: Linus Torvalds <[email protected]>
> Date: Wed May 8 21:35:19 2019 -0700
>
> Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
>
> Pull drm updates from Dave Airlie:
Lazy question: how does one determine the first and last commit inside a merge
request? Can I simply do
good a2d635decbfa9c1e4ae15cb05b68b2559f7f827c^
bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
for git bisect?
> So I was about to test out the i915 changes in that but since my laptop
> is what I use for daily work, it's a bit hard (can't freeze up on video
> calls for instance).
I usually use one of the ThinkPads from my embarrassing pile of outdated
hardware to do nasty bisects, but I'm not about to loose any income if my much
appreciated XPS 13 is out of order for a while.
Thanks,
Paul Bolle
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 within a minute of resuming. Typing stuff into
> evolution seems to help with triggering this. It's all a bit
> mysterious, but this message alone frooze my laptop a few times.
> Seriously!
>
> > Sure, my current testing indicates it's somewhere inside this pull
> > request:
> >
> > Merge: 89c3b37af87e eb85d03e01c3
> > Author: Linus Torvalds <[email protected]>
> > Date: Wed May 8 21:35:19 2019 -0700
> >
> > Merge tag 'drm-next-2019-05-09' of
> > git://anongit.freedesktop.org/drm/drm
> >
> > Pull drm updates from Dave Airlie:
>
> Lazy question: how does one determine the first and last commit
> inside a merge request? Can I simply do
> good a2d635decbfa9c1e4ae15cb05b68b2559f7f827c^
> bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
>
> for git bisect?
I think so. I actually did
bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
good 89c3b37af87ec183b666d83428cb28cc421671a6
But I think ^ steps down in the main branch. Note, I've only done a
couple of hours run on what I think is the good commit ... and actually
I'd already marked a2d635decbfa9c1e4ae15cb05b68b2559f7f827c as good
until the screen froze just after I'd built the new bisect kernel, so
there's still some chance 89c3b37af87ec183b666d83428cb28cc421671a6 is
bad.
> > So I was about to test out the i915 changes in that but since my
> > laptop is what I use for daily work, it's a bit hard (can't freeze
> > up on video calls for instance).
>
> I usually use one of the ThinkPads from my embarrassing pile of
> outdated hardware to do nasty bisects, but I'm not about to loose any
> income if my much appreciated XPS 13 is out of order for a while.
I can get back to it this afternoon, when I'm done with the meeting
requirements and doing other dev stuff.
James
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: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
# bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
# bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915: Update DRIVER_DATE to 20190417
git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217
Git told me I have nine steps after this. So at two hours per step I might
pinpoint the offending commit by Friday the 12th. If I'm lucky. (There are
other things to do than bisecting this issue.)
If you find that commit before I do, I'll be all ears.
Thanks,
Paul Bolle
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:
> $ git bisect log
> git bisect start
> # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
> git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
> # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag 'drm-
> next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
> git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
> # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915:
> Update DRIVER_DATE to 20190417
> git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217
>
> Git told me I have nine steps after this. So at two hours per step I
> might
> pinpoint the offending commit by Friday the 12th. If I'm lucky.
> (There are
> other things to do than bisecting this issue.)
>
> If you find that commit before I do, I'll be all ears.
Sure ... I'm doing the holistic thing and looking at the tree in that
branch. It seems to consist of 7 i915 updates
c09d39166d8a3f3788680b32dbb0a40a70de32e2 DRIVER_DATE to 20190207
47ed55a9bb9e284d46d6f2489e32a53b59152809 DRIVER_DATE to 20190220
f4ecb8ae70de86710e85138ce49af5c689951953 DRIVER_DATE to 20190311
1284ec985572232ace4817476baeb2d82b60be7a DRIVER_DATE to 20190320
a01b2c6f47d86c7d1a9fa822b3b91ec233b61784 DRIVER_DATE to 20190328
28d618e9ab86f26a31af0b235ced55beb3e343c8 DRIVER_DATE to 20190404
ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217 DRIVER_DATE to 20190417
So I figured I'd see if I can locate the problem by bisection of those
plus inspection.
James
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 the system is accepting keyboard input
> because when it freezes I can cat information to a file (if the mouse
> was over an xterm) and verify over the network the file contents.
> Nothing unusual appears in dmesg when the lockup happens.
>
> The last kernel I booted successfully on the system was 5.0, so I'll
> try compiling 5.1 to narrow down the changes.
It's likely this is panel self-refresh going haywire.
commit 8f6e87d6d561f10cfa48a687345512419839b6d8
Author: José Roberto de Souza <[email protected]>
Date: Thu Mar 7 16:00:50 2019 -0800
drm/i915: Enable PSR2 by default
The support for PSR2 was polished, IGT tests for PSR2 was added and
it was tested performing regular user workloads like browsing,
editing documents and compiling Linux, so it is time to enable it by
default and enjoy even more power-savings.
Temporary workaround would be to set i915.enable_psr=0
-Chris
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 apparently has no effect. Should that file be read-only?)
Feel free to ask me to test a fix (or a revert) once you've figured out what
to do about this.
Paul Bolle
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 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:
> > $ git bisect log
> > git bisect start
> > # good: [89c3b37af87ec183b666d83428cb28cc421671a6] Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide
> > git bisect good 89c3b37af87ec183b666d83428cb28cc421671a6
> > # bad: [a2d635decbfa9c1e4ae15cb05b68b2559f7f827c] Merge tag
> > 'drm-
> > next-2019-05-09' of git://anongit.freedesktop.org/drm/drm
> > git bisect bad a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
> > # bad: [ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217] drm/i915:
> > Update DRIVER_DATE to 20190417
> > git bisect bad ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217
> >
> > Git told me I have nine steps after this. So at two hours per step
> > I
> > might
> > pinpoint the offending commit by Friday the 12th. If I'm lucky.
> > (There are
> > other things to do than bisecting this issue.)
> >
> > If you find that commit before I do, I'll be all ears.
>
> Sure ... I'm doing the holistic thing and looking at the tree in that
> branch. It seems to consist of 7 i915 updates
>
> c09d39166d8a3f3788680b32dbb0a40a70de32e2 DRIVER_DATE to 20190207
> 47ed55a9bb9e284d46d6f2489e32a53b59152809 DRIVER_DATE to 20190220
> f4ecb8ae70de86710e85138ce49af5c689951953 DRIVER_DATE to 20190311
> 1284ec985572232ace4817476baeb2d82b60be7a DRIVER_DATE to 20190320
> a01b2c6f47d86c7d1a9fa822b3b91ec233b61784 DRIVER_DATE to 20190328
> 28d618e9ab86f26a31af0b235ced55beb3e343c8 DRIVER_DATE to 20190404
> ad2c467aa92e283e9e8009bb9eb29a5c6a2d1217 DRIVER_DATE to 20190417
>
> So I figured I'd see if I can locate the problem by bisection of
> those
> plus inspection.
>
> James
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
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 server and
> > the display will never alter. It also seems that the system is
> > accepting keyboard input because when it freezes I can cat
> > information to a file (if the mouse was over an xterm) and verify
> > over the network the file contents. Nothing unusual appears in
> > dmesg when the lockup happens.
> >
> > The last kernel I booted successfully on the system was 5.0, so
> > I'll try compiling 5.1 to narrow down the changes.
>
> It's likely this is panel self-refresh going haywire.
>
> commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> Author: José Roberto de Souza <[email protected]>
> Date: Thu Mar 7 16:00:50 2019 -0800
>
> drm/i915: Enable PSR2 by default
>
> The support for PSR2 was polished, IGT tests for PSR2 was added
> and
> it was tested performing regular user workloads like browsing,
> editing documents and compiling Linux, so it is time to enable it
> by
> default and enjoy even more power-savings.
>
> Temporary workaround would be to set i915.enable_psr=0
It looks plausible. I have to say I was just about to mark a bisect
containing this as good, but that probably reflects my difficulty
reproducing the issue.
James
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 the
> > > network 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 it freezes I can cat
> > > information to a file (if the mouse was over an xterm) and verify
> > > over the network the file contents. Nothing unusual appears in
> > > dmesg when the lockup happens.
> > >
> > > The last kernel I booted successfully on the system was 5.0, so
> > > I'll try compiling 5.1 to narrow down the changes.
> >
> > It's likely this is panel self-refresh going haywire.
> >
> > commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> > Author: José Roberto de Souza <[email protected]>
> > Date: Thu Mar 7 16:00:50 2019 -0800
> >
> > drm/i915: Enable PSR2 by default
> >
> > The support for PSR2 was polished, IGT tests for PSR2 was added
> > and
> > it was tested performing regular user workloads like browsing,
> > editing documents and compiling Linux, so it is time to enable
> > it
> > by
> > default and enjoy even more power-savings.
> >
> > Temporary workaround would be to set i915.enable_psr=0
>
> It looks plausible. I have to say I was just about to mark a bisect
> containing this as good, but that probably reflects my difficulty
> reproducing the issue.
Take at look of what PSR version is supported by your panel, it likely
that a notebook shipped with Skylake will have panel that supports only
PSR1 so that patch has no effect on your machine.
sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
Sink support: yes [0x01]
Only if you have 0x03 your panel have support for PSR2.
Or check your dmesg:
[drm:intel_psr_init_dpcd [i915]] eDP panel supports PSR version 1
>
> James
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 2019-07-11 at 20:25 +0000, 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
> > > > place. The machine is still functional and if I log in over
> > > > the network 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 it freezes
> > > > I can cat information to a file (if the mouse was over an
> > > > xterm) and verify over the network the file contents. Nothing
> > > > unusual appears in dmesg when the lockup happens.
> > > >
> > > > The last kernel I booted successfully on the system was 5.0, so
> > > > I'll try compiling 5.1 to narrow down the changes.
> > >
> > > It's likely this is panel self-refresh going haywire.
> > >
> > > commit 8f6e87d6d561f10cfa48a687345512419839b6d8
> > > Author: José Roberto de Souza <[email protected]>
> > > Date: Thu Mar 7 16:00:50 2019 -0800
> > >
> > > drm/i915: Enable PSR2 by default
> > >
> > > The support for PSR2 was polished, IGT tests for PSR2 was
> > > added and
> > > it was tested performing regular user workloads like
> > > browsing,
> > > editing documents and compiling Linux, so it is time to
> > > enable it by
> > > default and enjoy even more power-savings.
> > >
> > > Temporary workaround would be to set i915.enable_psr=0
> >
> > It looks plausible. I have to say I was just about to mark a
> > bisect containing this as good, but that probably reflects my
> > difficulty
> > reproducing the issue.
>
> Take at look of what PSR version is supported by your panel, it
> likely that a notebook shipped with Skylake will have panel that
> supports only PSR1 so that patch has no effect on your machine.
>
> sudo more /sys/kernel/debug/dri/0/i915_edp_psr_status
> Sink support: yes [0x01]
It says
Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: enabled [0x81f00726]
Source PSR status: IDLE [0x04010212]
Busy frontbuffer bits: 0x00000000
I've also updated to the released 5.2 kernel and am running with the
debug parameters you requested ... but so far no reproduction.
James
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 attached the dmesg (it's 4MB uncompressed).
Is there any other output you'd like from the machine? I've got an ssh
session into it so I can try anything.
James
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 attached the dmesg (it's 4MB uncompressed).
> Is there any other output you'd like from the machine? I've got an
> ssh
> session into it so I can try anything.
Thanks, could you also share the output of this after the screen
freeze?
/sys/kernel/debug/dri/0/i915_edp_psr_status
/sys/kernel/debug/dri/0/i915_display_info
/sys/kernel/debug/dri/0/i915_dmc_info
/sys/kernel/debug/pmc_core/package_cstate_show
It eventually comes back from screen freeze? Like moving the mouse or
typing brings it back?
>
> James
On Thu, 2019-07-11 at 22:26 +0000, 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 ... but so far no reproduction.
> >
> > OK, it's happened. I've attached the dmesg (it's 4MB
> > uncompressed).
> > Is there any other output you'd like from the machine? I've got an
> > ssh session into it so I can try anything.
>
> Thanks, could you also share the output of this after the screen
> freeze?
>
> /sys/kernel/debug/dri/0/i915_edp_psr_status
> /sys/kernel/debug/dri/0/i915_display_info
> /sys/kernel/debug/dri/0/i915_dmc_info
> /sys/kernel/debug/pmc_core/package_cstate_show
jarvis:~ # for f in `cat ~/tmp.txt`; do echo $f; cat $f; done
/sys/kernel/debug/dri/0/i915_edp_psr_status
Sink support: yes [0x01]
PSR mode: PSR1 enabled
Source PSR ctl: disabled [0x01f00726]
Source PSR status: IDLE [0x04010216]
Busy frontbuffer bits: 0x00000001
/sys/kernel/debug/dri/0/i915_display_info
CRTC info
---------
CRTC 47: pipe: A, active=yes, (size=3200x1800), dither=no, bpp=24
fb: 118, pos: 0x0, size: 3200x1800
encoder 84: type: DDI A, connectors:
connector 85: type: eDP-1, status: connected, mode:
"": 0 373250 3200 3248 3280 3360 1800 1803 1808 1852
0x0 0xa
cursor visible? yes, position (-3, 261), size 256x256, addr
0x01740000
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no,
mode=0, scalers[1]: use=no, mode=0
--Plane id 30: type=PRI, crtc_pos= 0x 0,
crtc_size=3200x1800, src_pos=0.0000x0.0000,
src_size=3200.0000x1800.0000, format=XR24 little-endian (0x34325258),
rotation=0 (0x00000001)
--Plane id 37: type=OVL, crtc_pos= 0x 0,
crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000,
format=N/A, rotation=0 (0x00000001)
--Plane id 44: type=CUR, crtc_pos= -3x 261, crtc_size= 256x
256, src_pos=0.0000x0.0000, src_size=256.0000x256.0000, format=AR24
little-endian (0x34325241), rotation=0 (0x00000001)
underrun reporting: cpu=yes pch=yes
CRTC 65: pipe: B, active=yes, (size=1600x1200), dither=no, bpp=24
fb: 118, pos: 0x0, size: 3200x1800
encoder 90: type: DDI B, connectors:
connector 91: type: DP-1, status: connected, mode:
"": 0 162000 1600 1664 1856 2160 1200 1201 1204 1250
0x0 0x5
cursor visible? yes, position (-3, 261), size 256x256, addr
0x017c0000
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no,
mode=0, scalers[1]: use=no, mode=0
--Plane id 48: type=PRI, crtc_pos= 0x 0,
crtc_size=1600x1200, src_pos=0.0000x0.0000,
src_size=1600.0000x1200.0000, format=XR24 little-endian (0x34325258),
rotation=0 (0x00000001)
--Plane id 55: type=OVL, crtc_pos= 0x 0,
crtc_size= 0x 0, src_pos=0.0000x0.0000, src_size=0.0000x0.0000,
format=N/A, rotation=0 (0x00000001)
--Plane id 62: type=CUR, crtc_pos= -3x 261, crtc_size= 256x
256, src_pos=0.0000x0.0000, src_size=256.0000x256.0000, format=AR24
little-endian (0x34325241), rotation=0 (0x00000001)
underrun reporting: cpu=yes pch=yes
CRTC 83: pipe: C, active=no, (size=0x0), dither=no, bpp=0
underrun reporting: cpu=yes pch=yes
Connector info
--------------
connector 85: type eDP-1, status: connected
physical dimensions: 290x170mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 12
audio support: no
fixed mode:
"3200x1800": 60 373250 3200 3248 3280 3360 1800 1803
1808 1852 0x48 0xa
DP branch device present: no
modes:
"3200x1800": 60 373250 3200 3248 3280 3360 1800 1803
1808 1852 0x48 0xa
"3200x1800": 48 298600 3200 3248 3280 3360 1800 1803
1808 1852 0x40 0xa
connector 91: type DP-1, status: connected
physical dimensions: 430x320mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 12
audio support: no
DP branch device present: yes
Type: VGA
ID:
HW: 0.0
SW: 1.0
modes:
"1600x1200": 60 162000 1600 1664 1856 2160 1200 1201
1204 1250 0x48 0x5
"1400x1050": 75 156000 1400 1504 1648 1896 1050 1053
1057 1099 0x40 0x6
"1400x1050": 60 121750 1400 1488 1632 1864 1050 1053
1057 1089 0x40 0x6
"1280x1024": 75 135000 1280 1296 1440 1688 1024 1025
1028 1066 0x40 0x5
"1280x1024": 60 108000 1280 1328 1440 1688 1024 1025
1028 1066 0x40 0x5
"1280x960": 60 108000 1280 1376 1488 1800 960 961 964
1000 0x40 0x5
"1152x864": 75 108000 1152 1216 1344 1600 864 865 868
900 0x40 0x5
"1024x768": 75 78750 1024 1040 1136 1312 768 769 772
800 0x40 0x5
"1024x768": 70 75000 1024 1048 1184 1328 768 771 777
806 0x40 0xa
"1024x768": 60 65000 1024 1048 1184 1344 768 771 777
806 0x40 0xa
"832x624": 75 57284 832 864 928 1152 624 625 628 667
0x40 0xa
"800x600": 75 49500 800 816 896 1056 600 601 604 625
0x40 0x5
"800x600": 72 50000 800 856 976 1040 600 637 643 666
0x40 0x5
"800x600": 60 40000 800 840 968 1056 600 601 605 628
0x40 0x5
"800x600": 56 36000 800 824 896 1024 600 601 603 625
0x40 0x5
"640x480": 75 31500 640 656 720 840 480 481 484 500
0x40 0xa
"640x480": 73 31500 640 664 704 832 480 489 492 520
0x40 0xa
"640x480": 67 30240 640 704 768 864 480 483 486 525
0x40 0xa
"640x480": 60 25175 640 656 752 800 480 490 492 525
0x40 0xa
"720x400": 70 28320 720 738 846 900 400 412 414 449
0x40 0x6
connector 98: type HDMI-A-1, status: disconnected
connector 105: type DP-2, status: disconnected
connector 111: type HDMI-A-2, status: disconnected
/sys/kernel/debug/dri/0/i915_dmc_info
fw loaded: yes
path: i915/skl_dmc_ver1_27.bin
version: 1.27
DC3 -> DC5 count: 1226
DC5 -> DC6 count: 0
program base: 0x09004040
ssp base: 0x00002fc0
htp: 0x00b40068
/sys/kernel/debug/pmc_core/package_cstate_show
Package C2 : 0x5055eddc7d0
Package C3 : 0xee561ada80
Package C6 : 0xb038cdcfd0
Package C7 : 0x195c61800
Package C8 : 0x8a5a9fd25a0
Package C9 : 0x0
Package C10 : 0x0
> 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.
I've actually got a VGA display plugged in over a USB-C to VGA
converter and that's working fine in mirrored mode even as the panel is
completely frozen.
James
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,
Paul Bolle
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 hours into that session I had the machine lock
up hard. Screen frozen, no input possible, etc. I had to power cycle it (after
half an hour, behaving very patient).
But the screen freeze that we're focusing on here never occurred during this
session.
Paul Bolle