Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1390848 > unrolled thread

Re: Regression of v4.6-rc vs. v4.5: hangs after a few minutes after boot

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Regression of v4.6-rc vs. v4.5: hangs after a few minutes after  boot Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-04-29 10:10 +0200
    Re: Regression of v4.6-rc vs. v4.5: Merge tag  'drm-intel-next-2016-02-29' Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-04-30 16:00 +0200
      Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-05 19:50 +0200
        Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" "Zanoni, Paulo R" <paulo.r.zanoni@intel.com> - 2016-05-05 21:00 +0200
          Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected:  a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW" Daniel Vetter <daniel@ffwll.ch> - 2016-05-05 22:00 +0200
            Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected:  a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-06 01:00 +0200
          Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-06 01:00 +0200
            Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" "Zanoni, Paulo R" <paulo.r.zanoni@intel.com> - 2016-05-06 02:00 +0200
          Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-08 12:20 +0200
            Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-08 13:30 +0200
        Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Daniel Vetter <daniel@ffwll.ch> - 2016-05-06 08:40 +0200
          Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4  "drm/i915/fbc: enable FBC by default on HSW and BDW" Stefan Richter <stefanr@s5r6.in-berlin.de> - 2016-05-08 13:50 +0200

#1390848 — Re: Regression of v4.6-rc vs. v4.5: hangs after a few minutes after boot

On Apr 26 Stefan Richter wrote:
> v4.6-rc solidly hangs after a short while after boot, login to X11, and
> doing nothing much remarkable on the just brought up X desktop.
> 
> Hardware: x86-64, E3-1245 v3 (Haswell),
>           mainboard Supermicro X10SAE,
>           using integrated Intel graphics (HD P4600, i915 driver),
>           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
>           Intel LAN (i217, igb driver),
>           several IEEE 1394 controllers, some of them behind
>           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI, Tundra)
>           and one PCI-to-CardBus bridge (Ricoh)
> 
> kernel.org kernel, Gentoo Linux userland
> 
> 1. known good:  v4.5-rc5 (gcc 4.9.3)
>    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> 
> 2. known good:  v4.5.2 (gcc 5.2.0)
>    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> 
> I will send my linux-4.6-rc5/.config in a follow-up message.

After it proved impossible to capture an oops through netconsole, I
started git bisect.  This will apparently take almost a week, as git
estimated 13 bisection steps and I will be allowing about 12 hours of
uptime as a sign for a good kernel.  (In my four or five tests of bad
kernels before I started bisection, they hung after 3 minutes...5.5 hours
uptime, with no discernible difference in workload.  Maybe 12 h cutoff is
even too short...)
-- 
Stefan Richter
-======----- -=-- ===-=
http://arcgraph.de/sr/

[toc] | [next] | [standalone]

#1391624 — Re: Regression of v4.6-rc vs. v4.5: Merge tag 'drm-intel-next-2016-02-29'

On Apr 29 Stefan Richter wrote:
> On Apr 26 Stefan Richter wrote:
> > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > doing nothing much remarkable on the just brought up X desktop.
> > 
> > Hardware: x86-64, E3-1245 v3 (Haswell),
> >           mainboard Supermicro X10SAE,
> >           using integrated Intel graphics (HD P4600, i915 driver),
> >           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> >           Intel LAN (i217, igb driver),
> >           several IEEE 1394 controllers, some of them behind
> >           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI, Tundra)
> >           and one PCI-to-CardBus bridge (Ricoh)
> > 
> > kernel.org kernel, Gentoo Linux userland
> > 
> > 1. known good:  v4.5-rc5 (gcc 4.9.3)
> >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> > 
> > 2. known good:  v4.5.2 (gcc 5.2.0)
> >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> > 
> > I will send my linux-4.6-rc5/.config in a follow-up message.

 .config: http://www.spinics.net/lists/kernel/msg2243444.html
   lspci: http://www.spinics.net/lists/kernel/msg2243447.html

Some userland package versions, in case these have any bearing:
x11-base/xorg-drivers-1.17
x11-base/xorg-server-1.17.4
x11-bas/xorg-x11-7.4-r2

> After it proved impossible to capture an oops through netconsole, I
> started git bisect.  This will apparently take almost a week, as git
> estimated 13 bisection steps and I will be allowing about 12 hours of
> uptime as a sign for a good kernel.  (In my four or five tests of bad
> kernels before I started bisection, they hung after 3 minutes...5.5 hours
> uptime, with no discernible difference in workload.  Maybe 12 h cutoff is
> even too short...)

There are about 9 more bisection steps left to go.
The first few steps sent me straight into DRM land.
My current "git bisect log" with own annotations:

git bisect start

# bad: [9735a22799b9214d17d3c231fe377fc852f042e9] Linux 4.6-rc2
git bisect bad 9735a22799b9214d17d3c231fe377fc852f042e9

# good: [b562e44f507e863c6792946e4e1b1449fbbac85d] Linux 4.5
git bisect good b562e44f507e863c6792946e4e1b1449fbbac85d

# good: [6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f] Merge branch 'for-4.6' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
# ++ still good after 18 h uptime
git bisect good 6b5f04b6cf8ebab9a65d9c0026c650bb2538fd0f

# good: [2c856e14dad8cb1b085ae1f30c5e125c6d46019b] Merge tag 'arm64-perf' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
# ++ still good after 24 h uptime
git bisect good 2c856e14dad8cb1b085ae1f30c5e125c6d46019b

# bad: [8bb7e27bbb9d0db7ca0e83d40810fb752381cdd5] staging: delete STE RMI4 hackish driver
# -- hung after 3 h uptime
git bisect bad 8bb7e27bbb9d0db7ca0e83d40810fb752381cdd5

# bad: [507d44a9e1bb01661c75b88fd866d2461ab41c9c] Merge tag 'drm-intel-next-2016-02-29' of git://anongit.freedesktop.org/drm-intel into drm-next
# -- hung after 2 h uptime
git bisect bad 507d44a9e1bb01661c75b88fd866d2461ab41c9c
-- 
Stefan Richter
-======----- -=-- ====-
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1395252 — Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On Apr 30 Stefan Richter wrote:
> On Apr 29 Stefan Richter wrote:
> > On Apr 26 Stefan Richter wrote:  
> > > v4.6-rc solidly hangs after a short while after boot, login to X11, and
> > > doing nothing much remarkable on the just brought up X desktop.
> > > 
> > > Hardware: x86-64, E3-1245 v3 (Haswell),
> > >           mainboard Supermicro X10SAE,
> > >           using integrated Intel graphics (HD P4600, i915 driver),
> > >           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> > >           Intel LAN (i217, igb driver),
> > >           several IEEE 1394 controllers, some of them behind
> > >           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI, Tundra)
> > >           and one PCI-to-CardBus bridge (Ricoh)
> > > 
> > > kernel.org kernel, Gentoo Linux userland
> > > 
> > > 1. known good:  v4.5-rc5 (gcc 4.9.3)
> > >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> > > 
> > > 2. known good:  v4.5.2 (gcc 5.2.0)
> > >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> > > 
> > > I will send my linux-4.6-rc5/.config in a follow-up message.  
> 
>  .config: http://www.spinics.net/lists/kernel/msg2243444.html
>    lspci: http://www.spinics.net/lists/kernel/msg2243447.html
> 
> Some userland package versions, in case these have any bearing:
> x11-base/xorg-drivers-1.17
> x11-base/xorg-server-1.17.4
> x11-bas/xorg-x11-7.4-r2

Furthermore, there is a single display hooked up via DisplayPort.

> > After it proved impossible to capture an oops through netconsole, I
> > started git bisect.  This will apparently take almost a week, as git
> > estimated 13 bisection steps and I will be allowing about 12 hours of
> > uptime as a sign for a good kernel.  (In my four or five tests of bad
> > kernels before I started bisection, they hung after 3 minutes...5.5 hours
> > uptime, with no discernible difference in workload.  Maybe 12 h cutoff is
> > even too short...)  

I took at least 18 hours uptime (usually 24 hours) as a sign for good
kernels.  During the bisection, bad kernels hung after 3 h, 2 h, 9 min,
45 min, and 4 min uptime.  Thus I arrived at a98ee79317b4 "drm/i915/fbc:
enable FBC by default on HSW and BDW" as the point where the hangs are
introduced.

Quoting the changelog of the commit:

    Oh, and in case you - the person reading this commit message - found
    this commit through git bisect, please do the following:
     - Check your dmesg and see if there are error messages mentioning
       underruns around the time your problem started happening.

Well, I always had the followings lines in dmesg:
[drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A
[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun

I always got these when I switch on the DisplayPort attached monitor.
Recently I changed userland from kdm to sddm and noticed that I
apparently get these when sddm shuts down.  I am not aware of whether
or not this also already happened with kdm.

However, "around the time your problem started happening" there is
nothing in dmesg, because "your problem" is a complete hang without
possibility of disk IO and without netconsole output.

     - Download intel-gpu-tools, compile it, and run:
       $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt
       Then send us the fbc.txt file, especially if you get a failure.
       This will really maximize your chances of getting the bug fixed
       quickly.

Do you need this while FBC is enabled, or can I run it while FBC is
disabled?

     - Try to find a reliable way to reproduce the problem, and tell us.

The reliable way is to just wait for the kernel to hang after about
3 minutes to 5.5 hours.  I have not identified any special activity
which would trigger the hang.

     - Boot with drm.debug=0xe, reproduce the problem, then send us the
       dmesg file.

I can try this, but I am skeptical about getting any useful kernel
messages from before the hang.

PS:
I am mentioning the following just in case that it has any relationship
with the FBC related kernel freezes.  Maybe it doesn't...  There is
another recent regression on this PC, but I have not yet figured out
whether it was introduced by any particular kernel version.  The
regression is:  When switching from X11 to text console by [Ctrl][Alt][Fx]
or by shutting down sddm, I often only get a blank screen.  I suspect
that this regression was introduced when I replaced kdm by sddm, but
I am not sure about that.
-- 
Stefan Richter
-======----- -=-= --=-=
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1395288 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> On Apr 30 Stefan Richter wrote:
> > 
> > On Apr 29 Stefan Richter wrote:
> > > 
> > > On Apr 26 Stefan Richter wrote:  
> > > > 
> > > > v4.6-rc solidly hangs after a short while after boot, login to
> > > > X11, and
> > > > doing nothing much remarkable on the just brought up X desktop.
> > > > 
> > > > Hardware: x86-64, E3-1245 v3 (Haswell),
> > > >           mainboard Supermicro X10SAE,
> > > >           using integrated Intel graphics (HD P4600, i915
> > > > driver),
> > > >           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> > > >           Intel LAN (i217, igb driver),
> > > >           several IEEE 1394 controllers, some of them behind
> > > >           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI,
> > > > Tundra)
> > > >           and one PCI-to-CardBus bridge (Ricoh)
> > > > 
> > > > kernel.org kernel, Gentoo Linux userland
> > > > 
> > > > 1. known good:  v4.5-rc5 (gcc 4.9.3)
> > > >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> > > > 
> > > > 2. known good:  v4.5.2 (gcc 5.2.0)
> > > >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> > > > 
> > > > I will send my linux-4.6-rc5/.config in a follow-up message.  
> >  .config: http://www.spinics.net/lists/kernel/msg2243444.html
> >    lspci: http://www.spinics.net/lists/kernel/msg2243447.html
> > 
> > Some userland package versions, in case these have any bearing:
> > x11-base/xorg-drivers-1.17
> > x11-base/xorg-server-1.17.4
> > x11-bas/xorg-x11-7.4-r2
> Furthermore, there is a single display hooked up via DisplayPort.
> 
> > 
> > > 
> > > After it proved impossible to capture an oops through netconsole,
> > > I
> > > started git bisect.  This will apparently take almost a week, as
> > > git
> > > estimated 13 bisection steps and I will be allowing about 12
> > > hours of
> > > uptime as a sign for a good kernel.  (In my four or five tests of
> > > bad
> > > kernels before I started bisection, they hung after 3
> > > minutes...5.5 hours
> > > uptime, with no discernible difference in workload.  Maybe 12 h
> > > cutoff is
> > > even too short...)  
> I took at least 18 hours uptime (usually 24 hours) as a sign for good
> kernels.  During the bisection, bad kernels hung after 3 h, 2 h, 9
> min,
> 45 min, and 4 min uptime.  Thus I arrived at a98ee79317b4
> "drm/i915/fbc:
> enable FBC by default on HSW and BDW" as the point where the hangs
> are
> introduced.
> 
> Quoting the changelog of the commit:

Thanks for following the instructions on the commit message! :)

> 
>     Oh, and in case you - the person reading this commit message -
> found
>     this commit through git bisect, please do the following:
>      - Check your dmesg and see if there are error messages
> mentioning
>        underruns around the time your problem started happening.
> 
> Well, I always had the followings lines in dmesg:
> [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo
> underrun on pipe A
> [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> underrun

Oh, well... I had a patch that would just disable FBC in case we saw a
FIFO underrun, but it was rejected. Maybe this is the time to think
about it again? Otherwise, I can't think of much besides disabling FBC
on HSW until all the underruns and watermarks regressions are fixed
forever.

> 
> I always got these when I switch on the DisplayPort attached monitor.
> Recently I changed userland from kdm to sddm and noticed that I
> apparently get these when sddm shuts down.  I am not aware of whether
> or not this also already happened with kdm.
> 
> However, "around the time your problem started happening" there is
> nothing in dmesg, because "your problem" is a complete hang without
> possibility of disk IO and without netconsole output.
> 
>      - Download intel-gpu-tools, compile it, and run:
>        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 
> 2>&1 | tee fbc.txt
>        Then send us the fbc.txt file, especially if you get a
> failure.
>        This will really maximize your chances of getting the bug
> fixed
>        quickly.
> 
> Do you need this while FBC is enabled, or can I run it while FBC is
> disabled?

FBC enabled. Considering your description, my hope is that maybe some
specific subtest will be able to hang your machine, so testing this
again will require only running the specific subtest instead of waiting
18 hours.

> 
>      - Try to find a reliable way to reproduce the problem, and tell
> us.
> 
> The reliable way is to just wait for the kernel to hang after about
> 3 minutes to 5.5 hours.  I have not identified any special activity
> which would trigger the hang.
> 
>      - Boot with drm.debug=0xe, reproduce the problem, then send us
> the
>        dmesg file.
> 
> I can try this, but I am skeptical about getting any useful kernel
> messages from before the hang.

Agree.

> 
> PS:
> I am mentioning the following just in case that it has any
> relationship
> with the FBC related kernel freezes.  Maybe it doesn't...  There is
> another recent regression on this PC, but I have not yet figured out
> whether it was introduced by any particular kernel version.  The
> regression is:  When switching from X11 to text console by
> [Ctrl][Alt][Fx]
> or by shutting down sddm, I often only get a blank screen.  I suspect
> that this regression was introduced when I replaced kdm by sddm, but
> I am not sure about that.

Maybe there is some relationship, since this operation involves a mode
change. You can also try checking dmesg to see if there are underruns
right when you do the change.


If you don't want to keep carrying a manual revert, you can just boot
with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
it would be good to know in case you still somehow see the machine
hangs even with FBC disabled.

Thanks,
Paulo

[toc] | [prev] | [next] | [standalone]

#1395338 — Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On Thu, May 05, 2016 at 06:50:14PM +0000, Zanoni, Paulo R wrote:
> Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > On Apr 30 Stefan Richter wrote:
> > > 
> > > On Apr 29 Stefan Richter wrote:
> > > > 
> > > > On Apr 26 Stefan Richter wrote:  
> > > > > 
> > > > > v4.6-rc solidly hangs after a short while after boot, login to
> > > > > X11, and
> > > > > doing nothing much remarkable on the just brought up X desktop.
> > > > > 
> > > > > Hardware: x86-64, E3-1245 v3 (Haswell),
> > > > >           mainboard Supermicro X10SAE,
> > > > >           using integrated Intel graphics (HD P4600, i915
> > > > > driver),
> > > > >           C226 PCH's AHCI and USB 2/3, ASMedia ASM1062 AHCI,
> > > > >           Intel LAN (i217, igb driver),
> > > > >           several IEEE 1394 controllers, some of them behind
> > > > >           PCIe bridges (IDT, PLX) or PCIe-to-PCI bridges (TI,
> > > > > Tundra)
> > > > >           and one PCI-to-CardBus bridge (Ricoh)
> > > > > 
> > > > > kernel.org kernel, Gentoo Linux userland
> > > > > 
> > > > > 1. known good:  v4.5-rc5 (gcc 4.9.3)
> > > > >    known bad:   v4.6-rc2 (gcc 4.9.3), only tried one time
> > > > > 
> > > > > 2. known good:  v4.5.2 (gcc 5.2.0)
> > > > >    known bad:   v4.6-rc5 (gcc 5.2.0), only tried one time
> > > > > 
> > > > > I will send my linux-4.6-rc5/.config in a follow-up message.  
> > >  .config: http://www.spinics.net/lists/kernel/msg2243444.html
> > >    lspci: http://www.spinics.net/lists/kernel/msg2243447.html
> > > 
> > > Some userland package versions, in case these have any bearing:
> > > x11-base/xorg-drivers-1.17
> > > x11-base/xorg-server-1.17.4
> > > x11-bas/xorg-x11-7.4-r2
> > Furthermore, there is a single display hooked up via DisplayPort.
> > 
> > > 
> > > > 
> > > > After it proved impossible to capture an oops through netconsole,
> > > > I
> > > > started git bisect.  This will apparently take almost a week, as
> > > > git
> > > > estimated 13 bisection steps and I will be allowing about 12
> > > > hours of
> > > > uptime as a sign for a good kernel.  (In my four or five tests of
> > > > bad
> > > > kernels before I started bisection, they hung after 3
> > > > minutes...5.5 hours
> > > > uptime, with no discernible difference in workload.  Maybe 12 h
> > > > cutoff is
> > > > even too short...)  
> > I took at least 18 hours uptime (usually 24 hours) as a sign for good
> > kernels.  During the bisection, bad kernels hung after 3 h, 2 h, 9
> > min,
> > 45 min, and 4 min uptime.  Thus I arrived at a98ee79317b4
> > "drm/i915/fbc:
> > enable FBC by default on HSW and BDW" as the point where the hangs
> > are
> > introduced.
> > 
> > Quoting the changelog of the commit:
> 
> Thanks for following the instructions on the commit message! :)
> 
> > 
> >     Oh, and in case you - the person reading this commit message -
> > found
> >     this commit through git bisect, please do the following:
> >      - Check your dmesg and see if there are error messages
> > mentioning
> >        underruns around the time your problem started happening.
> > 
> > Well, I always had the followings lines in dmesg:
> > [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo
> > underrun on pipe A
> > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> > underrun
> 
> Oh, well... I had a patch that would just disable FBC in case we saw a
> FIFO underrun, but it was rejected. Maybe this is the time to think
> about it again? Otherwise, I can't think of much besides disabling FBC
> on HSW until all the underruns and watermarks regressions are fixed
> forever.

Hm, if it's watermarks then testing with latest drm-intel-nightly would be
interesting. We finally managed to land atomic watermark updates (should
all be there in 4.7 too):

https://cgit.freedesktop.org/drm-intel

Cheers, Daniel

> 
> > 
> > I always got these when I switch on the DisplayPort attached monitor.
> > Recently I changed userland from kdm to sddm and noticed that I
> > apparently get these when sddm shuts down.  I am not aware of whether
> > or not this also already happened with kdm.
> > 
> > However, "around the time your problem started happening" there is
> > nothing in dmesg, because "your problem" is a complete hang without
> > possibility of disk IO and without netconsole output.
> > 
> >      - Download intel-gpu-tools, compile it, and run:
> >        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 
> > 2>&1 | tee fbc.txt
> >        Then send us the fbc.txt file, especially if you get a
> > failure.
> >        This will really maximize your chances of getting the bug
> > fixed
> >        quickly.
> > 
> > Do you need this while FBC is enabled, or can I run it while FBC is
> > disabled?
> 
> FBC enabled. Considering your description, my hope is that maybe some
> specific subtest will be able to hang your machine, so testing this
> again will require only running the specific subtest instead of waiting
> 18 hours.
> 
> > 
> >      - Try to find a reliable way to reproduce the problem, and tell
> > us.
> > 
> > The reliable way is to just wait for the kernel to hang after about
> > 3 minutes to 5.5 hours.  I have not identified any special activity
> > which would trigger the hang.
> > 
> >      - Boot with drm.debug=0xe, reproduce the problem, then send us
> > the
> >        dmesg file.
> > 
> > I can try this, but I am skeptical about getting any useful kernel
> > messages from before the hang.
> 
> Agree.
> 
> > 
> > PS:
> > I am mentioning the following just in case that it has any
> > relationship
> > with the FBC related kernel freezes.  Maybe it doesn't...  There is
> > another recent regression on this PC, but I have not yet figured out
> > whether it was introduced by any particular kernel version.  The
> > regression is:  When switching from X11 to text console by
> > [Ctrl][Alt][Fx]
> > or by shutting down sddm, I often only get a blank screen.  I suspect
> > that this regression was introduced when I replaced kdm by sddm, but
> > I am not sure about that.
> 
> Maybe there is some relationship, since this operation involves a mode
> change. You can also try checking dmesg to see if there are underruns
> right when you do the change.
> 
> 
> If you don't want to keep carrying a manual revert, you can just boot
> with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> it would be good to know in case you still somehow see the machine
> hangs even with FBC disabled.
> 
> Thanks,
> Paulo
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1395458 — Re: [Intel-gfx] Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Daniel Vetter wrote:
> Hm, if it's watermarks then testing with latest drm-intel-nightly would be
> interesting. We finally managed to land atomic watermark updates (should
> all be there in 4.7 too):
> 
> https://cgit.freedesktop.org/drm-intel

I will see if I can test this sometime soon.
-- 
Stefan Richter
-======----- -=-= --==-
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1395456 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Zanoni, Paulo R wrote:
> Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> >     Oh, and in case you - the person reading this commit message - found
> >     this commit through git bisect, please do the following:
> >      - Check your dmesg and see if there are error messages mentioning
> >        underruns around the time your problem started happening.
> > 
> > Well, I always had the followings lines in dmesg:
> > [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A
> > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun  
> 
> Oh, well... I had a patch that would just disable FBC in case we saw a
> FIFO underrun, but it was rejected. Maybe this is the time to think
> about it again? Otherwise, I can't think of much besides disabling FBC
> on HSW until all the underruns and watermarks regressions are fixed
> forever.

Just to be clear though, I know that these messages are emitted when the
monitor is switched on, and when sddm is being shut down --- but I do not
know whether there is any sort of underrun when I get the FBC related
freeze (since I just don't get any kernel messages at that point).

Is there a chance that a serial console would fare better than
netconsole?  This board and another PC in its vicinity have got onboard
serial ports but I don't have cables at the moment.

> >      - Download intel-gpu-tools, compile it, and run:
> >        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt  
> >        Then send us the fbc.txt file, especially if you get a failure.
> >        This will really maximize your chances of getting the bug fixed
> >        quickly.
> > 
> > Do you need this while FBC is enabled, or can I run it while FBC is
> > disabled?  
> 
> FBC enabled. Considering your description, my hope is that maybe some
> specific subtest will be able to hang your machine, so testing this
> again will require only running the specific subtest instead of waiting
> 18 hours.

The kms_frontbuffer_tracking runs from which I posted output two hours
ago did not trigger a lockup.

(I ran them while X11 was shut down because otherwise
kms_frontbuffer_tracking would skip all tests with "Can't become DRM
master, please check if no other DRM client is running.")

> > PS:
> > I am mentioning the following just in case that it has any relationship
> > with the FBC related kernel freezes.  Maybe it doesn't...  There is
> > another recent regression on this PC, but I have not yet figured out
> > whether it was introduced by any particular kernel version.  The
> > regression is:  When switching from X11 to text console by [Ctrl][Alt][Fx]
> > or by shutting down sddm, I often only get a blank screen.  I suspect
> > that this regression was introduced when I replaced kdm by sddm, but
> > I am not sure about that.  
> 
> Maybe there is some relationship, since this operation involves a mode
> change. You can also try checking dmesg to see if there are underruns
> right when you do the change.

Yes, this is accompanied by
[drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A
[drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun  
-- 
Stefan Richter
-======----- -=-= --=-=
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1395503 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

Em Sex, 2016-05-06 às 00:54 +0200, Stefan Richter escreveu:
> On May 05 Zanoni, Paulo R wrote:
> > 
> > Em Qui, 2016-05-05 às 19:45 +0200, Stefan Richter escreveu:
> > > 
> > >     Oh, and in case you - the person reading this commit message
> > > - found
> > >     this commit through git bisect, please do the following:
> > >      - Check your dmesg and see if there are error messages
> > > mentioning
> > >        underruns around the time your problem started happening.
> > > 
> > > Well, I always had the followings lines in dmesg:
> > > [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared
> > > fifo underrun on pipe A
> > > [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> > > underrun  
> > Oh, well... I had a patch that would just disable FBC in case we
> > saw a
> > FIFO underrun, but it was rejected. Maybe this is the time to think
> > about it again? Otherwise, I can't think of much besides disabling
> > FBC
> > on HSW until all the underruns and watermarks regressions are fixed
> > forever.
> Just to be clear though, I know that these messages are emitted when
> the
> monitor is switched on, and when sddm is being shut down --- but I do
> not
> know whether there is any sort of underrun when I get the FBC related
> freeze (since I just don't get any kernel messages at that point).

The fact that underruns have occurred earlier is enough to know that
something is wrong (most probably, bad watermarks): we stop reporting
underruns once we get the first one. In addition, we already know that
FBC has the tendency to amplify apparently-harmless FIFO underruns into
black screens, and I wouldn't be surprised to learn that it could also
cause full machine lockups.

> 
> Is there a chance that a serial console would fare better than
> netconsole?  This board and another PC in its vicinity have got
> onboard
> serial ports but I don't have cables at the moment.

In the past, for some specific cases not related to FBC, I had more
luck with serial console than with netconsole. But if this is really
caused by FBC and watermarks, I don't think you'll be able to grab any
specific message at the time of the machine hang. OTOH, if something
actually shows up, it could help invalidate our current assumption of
the relationship between the problem and FBC and underruns.

> 
> > 
> > > 
> > >      - Download intel-gpu-tools, compile it, and run:
> > >        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest
> > > '*fbc-*' 2>&1 | tee fbc.txt  
> > >        Then send us the fbc.txt file, especially if you get a
> > > failure.
> > >        This will really maximize your chances of getting the bug
> > > fixed
> > >        quickly.
> > > 
> > > Do you need this while FBC is enabled, or can I run it while FBC
> > > is
> > > disabled?  
> > FBC enabled. Considering your description, my hope is that maybe
> > some
> > specific subtest will be able to hang your machine, so testing this
> > again will require only running the specific subtest instead of
> > waiting
> > 18 hours.
> The kms_frontbuffer_tracking runs from which I posted output two
> hours
> ago did not trigger a lockup.
> 
> (I ran them while X11 was shut down because otherwise
> kms_frontbuffer_tracking would skip all tests with "Can't become DRM
> master, please check if no other DRM client is running.")

Yes, this is the correct way.

> 
> > 
> > > 
> > > PS:
> > > I am mentioning the following just in case that it has any
> > > relationship
> > > with the FBC related kernel freezes.  Maybe it doesn't...  There
> > > is
> > > another recent regression on this PC, but I have not yet figured
> > > out
> > > whether it was introduced by any particular kernel version.  The
> > > regression is:  When switching from X11 to text console by
> > > [Ctrl][Alt][Fx]
> > > or by shutting down sddm, I often only get a blank screen.  I
> > > suspect
> > > that this regression was introduced when I replaced kdm by sddm,
> > > but
> > > I am not sure about that.  
> > Maybe there is some relationship, since this operation involves a
> > mode
> > change. You can also try checking dmesg to see if there are
> > underruns
> > right when you do the change.
> Yes, this is accompanied by
> [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo
> underrun on pipe A
> [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO
> underrun  

[toc] | [prev] | [next] | [standalone]

#1396408 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 05 Zanoni, Paulo R wrote:
> If you don't want to keep carrying a manual revert, you can just boot
> with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> it would be good to know in case you still somehow see the machine
> hangs even with FBC disabled.

As expected, i915.enable_fbc=0 works fine.
No freeze within 2.5 days uptime; tested on v4.6-rc6.
-- 
Stefan Richter
-======----- -=-= -=---
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1396414 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 08 Stefan Richter wrote:
> On May 05 Zanoni, Paulo R wrote:
> > If you don't want to keep carrying a manual revert, you can just boot
> > with i915.enable_fbc=0 for now (or write a /etc/modprobe.d file). Also,
> > it would be good to know in case you still somehow see the machine
> > hangs even with FBC disabled.  
> 
> As expected, i915.enable_fbc=0 works fine.
> No freeze within 2.5 days uptime; tested on v4.6-rc6.

Furthermore, I checked out drm-intel.git (v4.6-rc6-962-g91567024d358
"drm-intel-nightly: 2016y-05m-06d-14h-29m-58s UTC integration manifest")
and applied "git diff v4.6-rc6..." on top of v4.6-rc6.

I booted the result once with default i915.enable_fbc, i.e. FBC enabled,
performed the test which Daniel asked for (I will post the results in
another message), then started X11.
  - The good news:  I was able to switch back and forth between the sddm
    greeter screen on tty7, the text consoles at tty1...6, and the logger
    at tty12 --- without getting any FIFO underrun messages and without
    getting stuck with a blank screen.
  - The bad news:  Less than a minute after login into sddm, just after
    having started openbox + lxpanel + konsole, the kernel froze again
    without netconsole output.

I am now on 4.6.0-rc6+intel-drm-nightly with i915.enable_fbc=0.  This is
running fine so far.  (uptime is just 30 minutes now though, so that
doesn't say a lot.)  Again, switching between ttys works without FIFO
underruns, unlike plain v4.6-rc6.  Not sure if it is coincidence or if
this is because somebody fixed something.

Like v4.6-rc6 and older,4.6.0-rc6+intel-drm-nightly still exhibits the
following behaviour:  If I switch the displayport connected monitor off
and on again, the following messages are logged when the monitor comes on:
    [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR* uncleared fifo underrun on pipe A
    [drm:intel_cpu_fifo_underrun_irq_handler] *ERROR* CPU pipe A FIFO underrun
Other than these messages, there is nothing extraordinary going on.
-- 
Stefan Richter
-======----- -=-= -=---
http://arcgraph.de/sr/

[toc] | [prev] | [next] | [standalone]

#1395626 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
> On May 05 Stefan Richter wrote:
> > Quoting the changelog of the commit:
> [...]
> >      - Download intel-gpu-tools, compile it, and run:
> >        $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt
> >        Then send us the fbc.txt file, especially if you get a failure.
> 
> Attached are results of kms_frontbuffer_tracking from current
> intel-gpu-tools.git (intel-gpu-tools-1.14-273-gb4b2ac346c92), taken on
> kernel v4.5.2 and on v4.6-rc5.

> Subtest fbc-1p-primscrn-spr-indfb-fullscreen failed.
> **** DEBUG ****
> (kms_frontbuffer_tracking:2266) DEBUG: Test requirement passed: fbc.can_test
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x100000000000001, size=14745600)
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=7, pitch=10240)
> (kms_frontbuffer_tracking:2266) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
> (kms_frontbuffer_tracking:2266) DEBUG: Rect 0 CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x100000000000001, size=14745600)
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
> (kms_frontbuffer_tracking:2266) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=7, pitch=10240)
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
> (kms_frontbuffer_tracking:2266) DEBUG: Calculated CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
> (kms_frontbuffer_tracking:2266) igt-core-INFO: Timed out: CRC reading
> ****  END  ****
> Timed out: CRC reading
> Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)

This one failed in both runs. Can you please retest with just that using

# kms_frontbuffer_tracking --run-subtest fbc-1p-primscrn-spr-indfb-fullscreen

Also please boot with drm.debug=0xe and grab the full dmesg of just that
single subtest. There's definitely something going wrong here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[toc] | [prev] | [next] | [standalone]

#1396416 — Re: Regression of v4.6-rc vs. v4.5 bisected: a98ee79317b4 "drm/i915/fbc: enable FBC by default on HSW and BDW"

On May 06 Daniel Vetter wrote:
> On Thu, May 05, 2016 at 10:45:31PM +0200, Stefan Richter wrote:
[...]
> > Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.876s)  
> 
> This one failed in both runs. Can you please retest with just that using
> 
> # kms_frontbuffer_tracking --run-subtest fbc-1p-primscrn-spr-indfb-fullscreen
> 
> Also please boot with drm.debug=0xe and grab the full dmesg of just that
> single subtest. There's definitely something going wrong here.

I performed this test with
  - plain v4.6-rc6,
  - v4.6-rc6 patched with drm-intel-nightly (2016y-05m-06d-14h-29m-58s).

On v4.6-rc6, the test failed thus:

-------- 8< --------
Subtest fbc-1p-primscrn-spr-indfb-fullscreen failed.
**** DEBUG ****
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: fbc.can_test
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x100000000000001, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) DEBUG: Blue CRC:   pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x100000000000001, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Rect 0 CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-draw-DEBUG: Test requirement passed: intel_gen(intel_get_drm_devid(fd)) >= 5
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[2ca73d01 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(width=2560, height=1440, format=0x34325258, tiling=0x100000000000001, size=14745600)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) drmtest-DEBUG: Test requirement passed: is_i915_device(fd) && has_known_intel_chipset(fd)
(kms_frontbuffer_tracking:1914) igt-fb-DEBUG: igt_create_fb_with_bo_size(handle=6, pitch=10240)
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) DEBUG: Test requirement passed: !fbc_not_enough_stolen()
(kms_frontbuffer_tracking:1914) DEBUG: Calculated CRC: pipe:[febb8b20 00000000 00000000 00000000 00000000] sink:[unsupported!]
(kms_frontbuffer_tracking:1914) igt-core-INFO: Timed out: CRC reading
****  END  ****
IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6 x86_64)
Primary screen: DP 2560x1440, crtc 26
FBC last action not supported
Can't test PSR: no usable eDP screen.
Sink CRC not supported: primary screen is not eDP
Timed out: CRC reading
Subtest fbc-1p-primscrn-spr-indfb-fullscreen: FAIL (5.806s)
-------- >8 --------

On v4.6-rc6 plus drm-intel-nightly, the test apparently passed:

-------- 8< --------
IGT-Version: 1.14-gc03a8ae6bf2f (x86_64) (Linux: 4.6.0-rc6+intel-drm-nightly x86_64)
Primary screen: DP 2560x1440, crtc 26
FBC last action not supported
Can't test PSR: no usable eDP screen.
Sink CRC not supported: primary screen is not eDP
Subtest fbc-1p-primscrn-spr-indfb-fullscreen: SUCCESS (1.018s)
-------- >8 --------

I will send the kernel messages from each of these two tests in a reply to
intel-gfx@lists.freedesktop.org only.
-- 
Stefan Richter
-======----- -=-= -=---
http://arcgraph.de/sr/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web