Bug 91241 - Get "vblank not available on crtc 1" warning with 3.19-rc1 onwards
Summary: Get "vblank not available on crtc 1" warning with 3.19-rc1 onwards
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-12 21:12 UTC by William
Modified: 2015-03-03 13:39 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.19-rc4
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
annotated syslog (29.08 KB, text/plain)
2015-01-12 21:12 UTC, William
Details
output of "xrandr --verbose" (7.62 KB, text/plain)
2015-01-12 21:14 UTC, William
Details
syslog traces for 3.19-rc7 (20.26 KB, text/plain)
2015-02-02 10:15 UTC, William
Details
dmesg output as requested in comment 9 (38.86 KB, text/plain)
2015-02-16 09:55 UTC, William
Details

Description William 2015-01-12 21:12:40 UTC
Created attachment 163311 [details]
annotated syslog

Get "vblank not available on crtc 1" Warning with 3.19-rc1 onwards

------------------------------------

On boot all is ok, but on starting "X" get "vblank not available on crtc 1"
warning and trace in /var/log/syslog. There are no more warnings unless I
wait for the monitor to go into blank/standby and the machine is re-awoken.

So far, apart from the warnings, there seem to be no adverse effects on
operation.

------------------------------------

Hardware:
  Asus P7H55-M SI with Intel Core i5 processor
  and Integrated Graphics [i915 driver].
  The board has 3 physical graphics connectors :-
    VGA    = VGA1
    DVI-D  = HDMI1 in use.
    HDMI   = HDMI2

Distro: Slackware-14.1, but with latest kernel.

X: xorg-server-1.14.3-x86_64-3_slack14.1
   xorg-server-xvfb-1.14.3-x86_64-3_slack14.1

Window manager: icewm-1.3.8 (also get similar results with twm, wmaker)

------------------------------------

Was last OK under 3.18.02 (also checked ok under 3.18.01, 3.14.27, 3.14.28).

The warnings first appear kernel 3.19-rc1, and are also in rc2,rc3,rc4.

Under previous kernels I do not get these warnings (though the
"ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_]" message
is present in the syslog under all versions).

------------------------------------

The only changes in kernel config from 3.18.2 are due to new options
automatically brought in with 3.19-rc[1-4] as follows :-

> CONFIG_INIT_FALLBACK=y
> CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
> CONFIG_X86_VSYSCALL_EMULATION=y
> CONFIG_PCIE_PME=y

------------------------------------

I will attach an annotated syslog and the output of "xrandr --verbose".
These are taken under kernel 3.19-rc4.
Comment 1 William 2015-01-12 21:14:22 UTC
Created attachment 163321 [details]
output of "xrandr --verbose"
Comment 2 William 2015-01-19 10:53:54 UTC
As my timeouts are fairly long I had not previously realised the problem
with kernels 3.17.n and 3.18.n - so a correction is needed to my original
report. [I do not currently have 3.15.n or 3.16.n installed - but could
test them if needed.]

I have done some more testing (including 3.19-rc5) :-

Kernel   | Console goes |  X start | X awakes from
         | to sleep     |          | Blank/Standby/Suspend/Off.
----------------------------------------------------------------
         |              |          |
3.14.28  | Ok           |  Ok      |  Ok     Ok     Ok     Ok    
         |              |          |
3.17.3   | Ok           |  Ok      |  Trace  Trace  Trace  Trace 
         |              |          |
3.18.3   | Ok           |  Ok      |  Trace  Trace  Trace  Trace 
         |              |          |
3.19-rc1 | Trace        |  Trace   |  Trace  Trace  Trace  Trace 
         |              |          |
3.19-rc5 | Trace        |  Trace   |  Trace  Trace  Trace  Trace 
         |              |          |

The three events which can cause a warning/trace are :-

    The console (no X running) goes to sleep.
    X Starts up
    X awakens after a Blank/Standby/Suspend/Off.
Comment 3 William 2015-01-27 15:40:12 UTC
I have now tested with more kernels (inc 3.15-rc1 and 3.19-rc6) :-

The bug related to X awakes from Blank/Standby/Suspend/Off was
first introduced in 3.15-rc1.

The bug related to Console goes to sleep and X startup was
first introduced in 3.19-rc1.
Comment 4 Jani Nikula 2015-01-29 10:00:49 UTC
Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel.
Comment 5 William 2015-01-30 17:15:30 UTC
Thanks, but I do not know my way around that site, or the build
process associated with it. I managed to download a few of the
patches but I am not sure what the base for the patches is.

So I think I need to wait a couple of days till the 3.19-rc7 comes
out to test with that.
Comment 6 William 2015-02-02 10:15:07 UTC
Created attachment 165561 [details]
syslog traces for 3.19-rc7

Tested with 3.19-rc7 with similar results to previous 3.19-rc's.
Will attach syslog traces.
Comment 7 Jani Nikula 2015-02-11 13:49:14 UTC
Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. I suspect this may be fixed by

commit f9b61ff6bce9a44555324b29e593fdffc9a115bc
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jan 7 13:54:39 2015 +0100

    drm/i915: Push vblank enable/disable past encoder->enable/disable
Comment 8 William 2015-02-14 18:48:03 UTC
That helps thanks.

The problem related to "Console goes to sleep" and "X startup", which
was introduced in 3.19-rc1, is fixed by applying the patch in
commit-f9b61ff6bce9a44555324b29e593fdffc9a115bc to 3.19.0.

But the problem related to X awakes from Blank/Standby/Suspend/Off,
which was introduced in 3.15-rc1, is still present.
Comment 9 Jani Nikula 2015-02-16 08:28:08 UTC
(In reply to William from comment #8)
> That helps thanks.
> 
> The problem related to "Console goes to sleep" and "X startup", which
> was introduced in 3.19-rc1, is fixed by applying the patch in
> commit-f9b61ff6bce9a44555324b29e593fdffc9a115bc to 3.19.0.
> 
> But the problem related to X awakes from Blank/Standby/Suspend/Off,
> which was introduced in 3.15-rc1, is still present.

Please attach dmesg from boot to the problem with drm.debug=14 module parameter set, running the kernel with the other problem fixed.
Comment 10 William 2015-02-16 09:55:49 UTC
Created attachment 167071 [details]
dmesg output as requested in comment 9

Used "xset s blank s 5"
Attaching dmesg output as requested in comment 9.
Comment 11 Jani Nikula 2015-03-03 13:39:42 UTC
(In reply to William from comment #10)
> Created attachment 167071 [details]
> dmesg output as requested in comment 9
> 
> Used "xset s blank s 5"
> Attaching dmesg output as requested in comment 9.

OK, please file a *new* bug about this. Add drm.debug=14 module parameter, and attach complete dmesg on the new bug.

Closing this one as fixed.

Note You need to log in before you can comment on or make changes to this bug.