Heavy black flickering with Intel graphics after VT switching from X to Mir

[William Hua]

After running mir_demo_server on VT 1, when I switch to VT 7 then back to VT 1, the demo server really flickers black quite a lot (entire screen, pointer included). I'm not sure, but I also upgraded my kernel to 3.18.2-031802-generic at the same time, if it's because of that, please mark invalid.
---
ApportVersion: 2.15.1-0ubuntu2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: william 5932 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 15.04
HibernationDevice: RESUME=UUID=f950febe-baf1-425c-8ab5-f4f43a86839b
Lsusb:
 Bus 002 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 001 Device 003: ID 0a5c:217f Broadcom Corp. BCM2045B (BDC-2.1)
 Bus 001 Device 002: ID 8087:0020 Intel Corp. Integrated Rate Matching Hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
MachineType: LENOVO 3249CTO
Package: mir
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.18.0-9-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash thinkpad_acpi.fan_control=Y vt.handoff=7
ProcVersionSignature: Ubuntu 3.18.0-9.10-generic 3.18.2
RelatedPackageVersions:
 linux-restricted-modules-3.18.0-9-generic N/A
 linux-backports-modules-3.18.0-9-generic N/A
 linux-firmware 1.140
SystemImageInfo:
 current build number: 0
 device name:
 channel: daily
 last update: Unknown
Tags: vivid
Uname: Linux 3.18.0-9-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm autopilot cdrom dip disk fuse kvm libvirtd lpadmin plugdev sambashare sbuild sudo video
_MarkForUpload: True
dmi.bios.date: 01/26/2010
dmi.bios.vendor: LENOVO
dmi.bios.version: 6QET35WW (1.05 )
dmi.board.name: 3249CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr6QET35WW(1.05):bd01/26/2010:svnLENOVO:pn3249CTO:pvrThinkPadX201:rvnLENOVO:rn3249CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 3249CTO
dmi.product.version: ThinkPad X201
dmi.sys.vendor: LENOVO

[Daniel van Vugt (vanvugt)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
    apport-collect 1409133
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

[Daniel van Vugt (vanvugt)]

Can you also try mir_proving_server?

[William Hua (attente)]

Will apport-collect provide any information in the case that the server doesn't crash? I ran it, but nothing seemed to happen.

I also tried mir_proving_server, but it exhibited the same flickering behaviour.

[Daniel van Vugt (vanvugt)]

Yes, it should provide useful information about your software and hardware, that we need.

[William Hua (attente)]

It only pops up a dialog saying "No additional information collected."

[William Hua (attente)]

Not sure if this will help much, but when I downgraded to Mir 0.9.0+15.04.20141125-0ubuntu2, the mir_demo_server_shell works again (feels a bit slower than before though for some reason). So I guess the problem isn't with the kernel I booted.

Also, these are my video card details:

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prog-if 00 [VGA controller])
 Subsystem: Lenovo Device 215a
 Flags: bus master, fast devsel, latency 0, IRQ 26
 Memory at f2000000 (64-bit, non-prefetchable) [size=4M]
 Memory at d0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 1800 [size=8]
 Expansion ROM at <unassigned> [disabled]
 Capabilities: <access denied>
 Kernel driver in use: i915

[Daniel van Vugt (vanvugt)]

Thanks. Can you also paste the log output you get (from 0.10) when running mir_proving_server? It contains important information about the system.

[Daniel van Vugt (vanvugt)]

Also can you provide CPU information? (/proc/cpuinfo)

[William Hua (attente)]

Running mir_proving_server (0.10) as root doesn't show any output other than:

[1421162423.862128] (II) SharedLibrary: Loading libmirplatform5driver.so
[1421162424.018693] (II) DisplayServer: Mir version 0.10.0
[1421162424.027428] (II) GLRenderer: GL vendor: Intel Open Source Technology Center
[1421162424.027475] (II) GLRenderer: GL renderer: Mesa DRI Intel(R) Ironlake Mobile
[1421162424.027490] (II) GLRenderer: GL version: OpenGL ES 2.0 Mesa 10.3.2
[1421162424.027502] (II) GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
*vt switch*
[1421162461.237578] (II) GLRenderer: GL vendor: Intel Open Source Technology Center
[1421162461.237630] (II) GLRenderer: GL renderer: Mesa DRI Intel(R) Ironlake Mobile
[1421162461.237645] (II) GLRenderer: GL version: OpenGL ES 2.0 Mesa 10.3.2
[1421162461.237658] (II) GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16
*vt switch*
[1421162469.291452] (II) GLRenderer: GL vendor: Intel Open Source Technology Center
[1421162469.292135] (II) GLRenderer: GL renderer: Mesa DRI Intel(R) Ironlake Mobile
[1421162469.292524] (II) GLRenderer: GL version: OpenGL ES 2.0 Mesa 10.3.2
[1421162469.292557] (II) GLRenderer: GLSL version: OpenGL ES GLSL ES 1.0.16

[William Hua (attente)]

/proc/cpuinfo (couldn't attach it for some reason):

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 2
microcode : 0x9
cpu MHz : 1333.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid
bugs :
bogomips : 4787.88
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 2
microcode : 0x9
cpu MHz : 1333.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid
bugs :
bogomips : 4787.88
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 2
microcode : 0x9
cpu MHz : 1333.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt aes lahf_lm ida arat dtherm tpr_shadow vnmi flexpriority ept vpid
bugs :
bogomips : 4787.88
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 2
microcode : 0x9
cpu MHz : 1333.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 2
cpu cores : 2
apicid : 5
initial apicid : 5
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl...

[Daniel van Vugt (vanvugt)]

Thanks. That is indeed a processor family I don't have myself to test with. But I'll work on that.

[Daniel van Vugt (vanvugt)]

You say the hardware pointer is flickering too? That's rendered entirely by the kernel so this sounds like a kernel driver bug.

[William Hua (attente)]

Daniel, thanks, you're completely right. I downgraded my kernel to 3.16.7-031607-generic and the flickering problem went away. Definitely wondering if it has something to do with bug LP: #1408593 which also affected me when I upgraded to 3.18.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1409133

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Daniel van Vugt (vanvugt)]

See comment #1 onward.

[Daniel van Vugt (vanvugt)]

Actually, no...

William: Can you please re-run "apport-collect 1409133" when the /broken/ kernel version is running?
The command should work now this bug has a kernel task.

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1409133

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[William Hua (attente)]

apport information

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.19 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc4-vivid/

[Joseph Salisbury (jsalisbury)]

Does this bug also go away with the test kernel in comment #28 of bug 1408593

[William Hua (attente)]

Thanks Joseph,

The bug still exists with 3.19.0-031900rc4-generic.
The bug does not exist with 3.19.0-994-generic. However the pointer is very laggy.

I think I can only revert to 3.16.7-031607.201410301735 in the mean time...

[Joseph Salisbury (jsalisbury)]

The 3.19.0-994-generic is the daily build. That may indicate that this will be fixed in 3.19-rc5. Were you also able to test the test kernel in comment #28 of bug 1408593 ?

[William Hua (attente)]

Sorry, I wasn't specific enough. I meant I used the 3.19.0-994.201501130205 kernel from comment #28 of LP: #1408593. The bug doesn't exist there, however I have a very laggy pointer from that one which seems to be a new regression.

[Daniel van Vugt (vanvugt)]

Re: Comment #35
By laggy pointer you mean laggy in X? That would indicate it's falling back to software rendering and a software cursor.

[William Hua (attente)]

Still occurs with 3.19.0-031900rc6-generic :(

[Christopher M. Penalver (penalvch)]

William Hua, the next step is to fully commit bisect from kernel 3.16.7 to 3.18 in order to identify the last good kernel commit, followed immediately by the first bad one. This will allow for a more expedited analysis of the root cause of your issue. Could you please do this following https://wiki.ubuntu.com/Kernel/KernelBisection ?

Thank you for your understanding.

[Daniel van Vugt (vanvugt)]

William,
Can you post a video of the flickering? That's often helpful for us to identify the kind of problem it might be.

[William Hua (attente)]

Sorry, video is a bit big.

- switched to VT 1
- started mir_demo_server (no flickering yet)
- switched to VT 7
- switched to VT 1 (flickering is apparent, as seen by cursor)
- switched to VT 7
- started gedit under the mir backend
- switched to VT 1 (flickering is apparent, as seen by cursor and gedit window)

I will do the kernel bisection to find out what went wrong.

[William Hua (attente)]

Oops, sorry, that should be a .ogv extension...

[Daniel van Vugt (vanvugt)]

Certainly Mir's page flipping logic changed a bit in Mir 0.10 (faster). However, this bug doesn't occur on any other GPU (even tried several intel GPUs), and if the cursor is flickering then it's likely a kernel bug.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Confirmed on Ivy Bridge. I can see the bug now :)

[Daniel van Vugt (vanvugt)]

Weirdly the bug only happens on VT switching directly from X (VT 7). If you switch to some other VT before Mir's then there's no flickering.

[William Hua (attente)]

Kernel bisection yielded this as the culprit:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c51f71679042a5f388d9580ffbede14c897f1e86

Might try to bisect that branch, but it might be more difficult to test.

[Christopher M. Penalver (penalvch)]

William Hua, the issue you are reporting is an upstream one. Could you please report this problem to the appropriate mailing list (<email address hidden>) by following the instructions verbatim at https://wiki.ubuntu.com/Bugs/Upstream/kernel ?

Please provide a direct URL to your e-mail to the mailing list once you have made it so that it may be tracked via http://vger.kernel.org/vger-lists.html . It can take a day for the new e-mail to show up in the respective archive.

Thank you for your understanding.

[Daniel van Vugt (vanvugt)]

Also confirmed it doesn't matter which version of Mir I try; the bug is still present. This one is all kernel.

[Daniel van Vugt (vanvugt)]

WORKAROUND:
Switch to a different VT (other than X or Mir) before switching to Mir. That will avoid triggering the bug. It only happens if you're coming from the X VT.

[William Hua (attente)]

[1.] One line summary of the problem:

Switching from an X VT to a Mir VT with Intel graphics causes heavy black flickering.

[2.] Full description of the problem/report:

This is a regression caused by https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c51f71679042a5f388d9580ffbede14c897f1e86. It still occurs with the current master head at https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e36f014edff70fc02b3d3d79cead1d58f289332e as of February 3, 2015.

As root, run the mir_demo_server from the Mir project located at https://code.launchpad.net/~mir-team/mir/development-branch on VT 1. Switch back to a VT running X, which is VT 7 on my Ubuntu machine. Switch back to VT 1. The Mir server will flicker heavily, both screen and pointer, which it did not do until the above merge commit.

[3.] Keywords (i.e., modules, networking, kernel):

[4.] Kernel version (from /proc/version):

Linux version 3.19.0-rc7-custom+ (root@attente) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu2) ) #1 SMP Tue Feb 3 11:38:45 CET 2015

[5.] Output of Oops.. message (if applicable) with symbolic information resolved (see Documentation/oops-tracing.txt)

[6.] A small shell script or example program which triggers the problem (if possible)

Please see the mir_demo_server program from the Mir project.

[7.] Environment

Description: Ubuntu Vivid Vervet (development branch)
Release: 15.04

[7.1.] Software (add the output of the ver_linux script here)

Linux attente 3.19.0-rc7-custom+ #1 SMP Tue Feb 3 11:38:45 CET 2015 x86_64 x86_64 x86_64 GNU/Linux

Gnu C 4.9.2
Gnu make 4.0
binutils 2.25
util-linux 2.25.2
mount debug
module-init-tools 18
e2fsprogs 1.42.12
pcmciautils 018
PPP 2.4.6
Linux C Library 2.19
Dynamic linker (ldd) 2.19
Procps 3.3.9
Net-tools 1.60
Kbd 1.15.5
Sh-utils 8.23
wireless-tools 30
Modules Loaded ctr ccm nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_CHECKSUM iptable_mangle xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables intel_powerclamp coretemp arc4 kvm_intel kvm iwldvm mac80211 serio_raw iwlwifi snd_hda_codec_hdmi intel_ips snd_hda_codec_conexant snd_hda_codec_generic snd_hda_intel snd_hda_controller btusb snd_hda_codec thinkpad_acpi nvram snd_seq_midi snd_hwdep cfg80211 snd_seq_midi_event snd_pcm snd_rawmidi rfcomm shpchp mei_me mei bnep lpc_ich snd_seq bluetooth snd_seq_device snd_timer snd soundcore mac_hid parport_pc ppdev lp parport binfmt_misc dm_crypt crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel i915 aes_x86_64 lrw gf128mul glue_helper ablk_helper i2c_algo_bit cryptd drm_kms_helper e1000e drm ptp psmouse ahci pps_core libahci wmi video

[7.2.] Processor information (from /proc/cpuinfo):

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 37
model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz
stepping : 2
microcode : 0x9
cpu MHz : 1199....

[Chris Wilson (ickle)]

Please attach a drm.debug=0xf dmesg from across the VT switch. Something like:

In X, "echo 0xf > /sys/module/drm/parameters/debug ; sleep 10; echo 0 > /sys/module/drm/parameters/debug"
VT switch to Mir
wait 10 second to capture the flicker
VT switch to X
dmesg && attach

[William Hua (attente)]

Created attachment 113111
DRM debug log

[Ander Conselvan de Oliveira (conselvan2)]

Probably a duplicate of bug 90508. Could you give the patch referenced there a try?

[Fraph24 (fraph24)]

Created attachment 116362
dmesg.txt

(In reply to Ander Conselvan de Oliveira from comment #3)
> Probably a duplicate of bug 90508. Could you give the patch referenced there
> a try?

Bug #90508 is fixed in kernel-4.0.4-301. I'm using kernel-4.0.4-303 and I still got that issue.

Fedora 22 Workstation, x86_64.

After VT switch to X, I got this:
[ 5427.787710] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun

[Ander Conselvan de Oliveira (conselvan2)]

Francesco, please open a separate bug report and include dmesg with drm.debug=0xe from boot to the point where you get the FIFO underrun.

[Fraph24 (fraph24)]

(In reply to Ander Conselvan de Oliveira from comment #5)
> Francesco, please open a separate bug report and include dmesg with
> drm.debug=0xe from boot to the point where you get the FIFO underrun.

Done.

Here's the link (in the case they could be related somehow): https://bugs.freedesktop.org/show_bug.cgi?id=90896

[Daniel van Vugt (vanvugt)]

Needs retesting.