Bug#871719: linux-image-4.9.0-3-amd64: As requested reporting use of pci=nocrs as a boot parameter

2017-08-10 Thread Peter Collinson 
Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: normal
Tags: newcomer

Dear Maintainer,

I have a small fanless system sold to me by PONDESK in the UK. It's
exactly right for a small router and gateway system. It has WiFi which I am not
using. It's described as
Intel J1900 4 LAN 3G/4G WiFi Firewall Router Fanless Mini PC (MNHO-043)
If you want to find it, see
https://www.pondesk.com/product/Intel-J1900-4-LAN-3G4G-WiFi-Firewall-Router-Fanless-Mini-PC_MNHO-043

However, it's new hardware and so I looked at the boot log, just to
see if things were going as well as they should. Note that the lines
I've flagged are only present on a vanilla boot, unpack the file below to get a 
copy of
the whole sequence.

This warning is put out by the system early on.
[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in 
FADT/Gpe0Block: 128/32 (20160831/tbfadt-603)

Is this a problem?
[0.00] Calgary: detecting Calgary via BIOS EBDA area
[0.00] Calgary: Unable to locate Rio Grande table in EBDA - bailing!
[0.00] Memory: 8043028K/8275912K available (6187K kernel code, 1137K 
rwdata, 2856K rodata, 1392K init, 688K bss, 232884K reserved, 0K cma-reserved)

Some time later...

[1.088113] PCI: pci_cache_line_size set to 64 bytes
[1.088134] pci :00:17.0: can't claim BAR 0 [mem 0xd0a07000-0xd0a07fff]: 
no compatible bridge window

and then

[1.321138] pci :00:1c.3: res[15]=[mem 0x0010-0x002f 64bit pref] 
res_to_dev_res add_size 20 min_align 10
[1.321151] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321155] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321163] pci :00:1c.1: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321166] pci :00:1c.1: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321173] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321176] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321183] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321186] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321194] pci :00:17.0: BAR 0: no space for [mem size 0x1000]
[1.321198] pci :00:17.0: BAR 0: trying firmware assignment [mem 
0xd0a07000-0xd0a07fff]
[1.321202] pci :00:17.0: BAR 0: [mem 0xd0a07000-0xd0a07fff] conflicts 
with PCI Bus :00 [mem 0xc000-0xd0a07ffe window]
[1.321205] pci :00:17.0: BAR 0: failed to assign [mem size 0x1000]
[1.321212] pci :00:17.0: BAR 0: no space for [mem size 0x1000]
[1.321215] pci :00:17.0: BAR 0: trying firmware assignment [mem 
0xd0a07000-0xd0a07fff]
[1.321218] pci :00:17.0: BAR 0: [mem 0xd0a07000-0xd0a07fff] conflicts 
with PCI Bus :00 [mem 0xc000-0xd0a07ffe window]
[1.321221] pci :00:17.0: BAR 0: failed to assign [mem size 0x1000]
[1.321229] pci :00:1c.3: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321231] pci :00:1c.3: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321239] pci :00:1c.2: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321242] pci :00:1c.2: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321249] pci :00:1c.1: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321252] pci :00:1c.1: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321259] pci :00:1c.0: BAR 15: no space for [mem size 0x0020 
64bit pref]
[1.321262] pci :00:1c.0: BAR 15: failed to assign [mem size 0x0020 
64bit pref]
[1.321267] pci :00:1c.0: PCI bridge to [bus 01]
[1.321270] pci :00:1c.0:   bridge window [io  0xe000-0xefff]
[1.321276] pci :00:1c.0:   bridge window [mem 0xd090-0xd09f]
[1.321283] pci :00:1c.1: PCI bridge to [bus 02]
[1.321286] pci :00:1c.1:   bridge window [io  0xd000-0xdfff]
[1.321291] pci :00:1c.1:   bridge window [mem 0xd080-0xd08f]
[1.321298] pci :00:1c.2: PCI bridge to [bus 03]
[1.321301] pci :00:1c.2:   bridge window [io  0xc000-0xcfff]
[1.321306] pci :00:1c.2:   bridge window [mem 0xd070-0xd07f]
[1.321313] pci :00:1c.3: PCI bridge to [bus 04]
[1.321316] pci :00:1c.3:   bridge window [io  0xb000-0xbfff]
[1.321321] pci :00:1c.3:   bridge window [mem 0xd060-0xd06f]
[1.321329] pci_bus :00: Some PCI device resources are unassigned, try 
booting with pci=realloc
[1.321331] pci_bus :00: resource 4 [io  0x0070-0x0077]
[1.321334] pci_bus :00: resource 5 [io  0x-0x006f window]
[1.321336] pci_bus :00: resource 6 [io  0x0078-0x0cf7 window]
[1.321339] pci_bus :00: resource 7 [io  0x0d00-0x window]
[1.321342] pci_bus :00: resource 8 [mem 0x000a-0x000b window]
[

Bug#869684: linux-image-4.9.0-3-686-pae: Thinkpad T60 hangs on resume after suspend to disk; regress since Debian 8

2017-08-10 Thread Bernhard Übelacker 
Hello,
I installed a Thinkpad T60 last year around 16.19.2016 with Debian Testing.
With the kernel contained at that time suspend to disk was working well.
(linux-image-4.6.0-1-686-pae  4.6.4-1, [1])

Just recently I got this system back and upgraded it to current Stretch.
(linux-image-4.9.0-3-686-pae  4.9.30-2+deb9u3)
There I can confirm resume is not working anymore.

As my first attempt to add some information to this bug report never
arrived (with reportbug) I decided to try with a vanilla kernel:
The git head from yesterday has the same issue (4.13.0-rc4+)

And then tried some git bisect.
Finally I came to this commit:

$ git bisect bad
65fe935dd2387a4faf15314c73f5e6d31ef0217e is the first bad commit
commit 65fe935dd2387a4faf15314c73f5e6d31ef0217e
Author: Kees Cook 
Date:   Mon Jun 13 15:10:02 2016 -0700

x86/KASLR, x86/power: Remove x86 hibernation restrictions

With the following fix:

70595b479ce1 ("x86/power/64: Fix crash whan the hibernation code 
passes control to the image kernel")

... there is no longer a problem with hibernation resuming a
KASLR-booted kernel image, so remove the restriction.

...

:04 04 62ec80a77951d45d01880a17fc64e9ee9d2e974c 
a43a4a4e1d1625a67d5403328d52a0103253a747 M  Documentation
:04 04 81718df2254545796eda792b975f9ab32d2a62bd 
b75ddf9403921b170727f685370ecc70d0ff6907 M  arch
:04 04 85ea5ad6e9b8fea1691552d14c998b04f8364136 
3462d929255d999a68f1a37e7e7ba9a66b099a39 M  kernel


I tried adding "nokaslr" to my default kernel parameters and
indeed I could successfully resume with a vanilla 4.13.0-rc4+ and
the default Stretch 4.9.30-2+deb9u3 kernels.


Adding this to /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet nokaslr"
and executing
update-grub
should make it permanent.


Probably this can be confirmed by Sergio B.?


Kind regards,
Bernhard




[1] 
http://snapshot.debian.org/package/linux/4.6.4-1/#linux-image-4.6.0-1-686-pae_4.6.4-1

Bug#871701: linux 4.9: backport patches for new Loongson CPU

2017-08-10 Thread YunQiang Su 
Package: linux
Version: 4.9.30-2+deb9u2

The support Loongson 3A/B 2000 and 3000 has been merged into upstream.
I test the patchset with linux 4.9.30-2+deb9u2 for stretch.

It works well on both Loongson 3A 1000 and 3A 3000 CPU.
The patchset merged on June 28-29.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?h=v4.13-rc4=grep=Huacai+Chen


0a00024d7a779b283db2a02130ffa46f47634d0c
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=0a00024d7a779b283db2a02130ffa46f47634d0c

b392ee07999aa1f19b3a845fad47ec4275341f71
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=b392ee07999aa1f19b3a845fad47ec4275341f71

99b0b5a3a1e994247e7533de0fd7e4d13ead0ddd
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=99b0b5a3a1e994247e7533de0fd7e4d13ead0ddd

e1b88ca8d72193e48bac026b19b8c686cc7fea25
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=e1b88ca8d72193e48bac026b19b8c686cc7fea25

ecc38a0968ec3e0605079e49d276d9a4186abdb7
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=ecc38a0968ec3e0605079e49d276d9a4186abdb7

b9c4dc2cf9af62bc0d2d8504c15175aeac49ad53
   
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.13-rc4=b9c4dc2cf9af62bc0d2d8504c15175aeac49ad53

-- 
YunQiang Su

Bug#864642: vmxnet3: Reports suspect GRO implementation on vSphere hosts / one VM crashes

2017-08-10 Thread Andrew Moore 
On Tue, 8 Aug 2017 11:38:06 +0200 (CEST) Sven Hartge 
wrote:
> Um 16:22 Uhr am 03.08.17 schrieb Sven Hartge:
> > On 03.08.2017 15:34, Patrick Matthäi wrote:
> >> Am 16.07.2017 um 23:42 schrieb Ben Hutchings:
> >>> On Thu, 2017-07-06 at 21:50 +0200, Sven Hartge wrote:
>
> > Could this be https://bugzilla.kernel.org/show_bug.cgi?id=191201 ?
> >>> Note that this has been root-caused as a bug in the virtual device,
not
> >>> the driver.  (Though it would be nice if the driver could work around
> >>> it.)
> >
> >> I can confirm, that the VMs do not crash anymore with vSphere 6.5 build
> >> 5969303 from 27.07.2017, that is why I lowered the severity.
> >
> > This is the version from 6.5u1, right?
> >
> > Still: Stretch is basically unusable with HW13 on ESX6.5 below Update1.
>
> Hmm. There are discussions on Reddit right now indicating the bug still
> occurs even with the latest ESXi6.5u1 (Build 5969303).
>
>
https://www.reddit.com/r/homelab/comments/6s5dh6/debian_9_on_esxi_65u1_complete_lockup/
>
> One of the latest comments on the Kernel Bugzilla shows the same:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=191201#c54
>
> (For me, this is really frustrating right now, since I waited until
> ESX6.5u1 before updating my infrastructure and now it seems I have to
push
> this update even farther into the future because of this critical blocker
> bug.)
>
> I really wonder what could be done on the Kernel side to avoid the
> problem, since only newer Kernel are affected while older one don't show
> the problem.
>
> Grüße,
> Sven.
>
>
Hi Sven,

Both of those reports were me. I suspect the issue may be isolated to the
HPE custom implementation of the ESXi 6.5u1 build. I haven't seen any
similar reports of people using the vanilla 6.5u1 build.

Interestingly none of the fixes that have been discussed work with this
build either. This includes disabling the rx-mini buffer (# ethtool -G
 rx-mini 0) and adding vmxnet3.rev.30 = FALSE to the VMs vmx
file.

The only way I've managed to restore stability is by removing vmxnet3 out
of the equation completely and changing to the e1000 NIC type.

Thanks,
Andrew

Bug#871646: linux-image-4.9.0-3-amd64: mmc0 / sdhci errors after inserting SDHC card with O2 Micro Device 8620 controller

2017-08-10 Thread Jon Leech 
Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: important

Dear Maintainer,

I am unable to insert an SD card and have it recognized by the kernel after
upgrading from Debian 8.
Prior to the upgrade, the SD card was recognized and worked flawlessly.

   * What led up to the situation?

Inserting a 64GB SD card into the internal SD slot.

   * What was the outcome of this action?

Device was not recognized and could not be used. dmesg showed this relevant
information:

[  163.277284] sdhci: Timeout waiting for Buffer Read Ready interrupt during
tuning procedure, falling back to fixed sampling clock
[  163.279450] mmc0: tuning execution failed: -5
[  163.279500] mmc0: error -5 whilst initialising SD card
[  163.513203] mmc0: error -110 whilst initialising SD card
[  164.161328] sdhci: Timeout waiting for Buffer Read Ready interrupt during
tuning procedure, falling back to fixed sampling clock
[  164.163495] mmc0: tuning execution failed: -5
[  164.163545] mmc0: error -5 whilst initialising SD card
[  164.422865] mmc0: error -110 whilst initialising SD card

   * What outcome did you expect instead?

Device would be recognized and become mountable.


Additional information:

This behavior is at least superficially similar to longstanding kernel bug
https://bugzilla.kernel.org/show_bug.cgi?id=109231
although I see an additional "error -110".

Following advice in the kernel bug page, I attempted adding
debug_quirks2=0x1 to the sdhci kernel parameters.
This *did* allow inserting the SD card, having it recognized, and mounting it
successfully. However, attempting heavy use of the SD card (running the
"Unison" file synchronizer against my /home partition) caused Unison to lock up
*hard*, a flood of kernel errors, and inability to kill -9 Unison, or unmount
the device. I had no option at this point but to reboot the machine, with
consequent possible data loss, although fortunately the SD card was formatted
with an ext4 partition and appeared to recover properly.

Given the severity of this behavior, I have not attempted to load the sdhci
module with other quirks suggested in the kernel bug page, such as 65536 or
0x4, as yet.





-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-3-amd64 
root=UUID=34b763ac-7563-4b3f-b3e1-25bfd5ae4026 ro text

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[3.682546] usbcore: registered new interface driver ax88179_178a
[3.854778] EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: 
(null)
[4.245978] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[4.283125] Adding 7812092k swap on /dev/sda7.  Priority:-1 extents:1 
across:7812092k FS
[4.409914] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[4.409923] Bluetooth: BNEP filters: protocol multicast
[4.409931] Bluetooth: BNEP socket layer initialized
[4.506224] vboxdrv: loading out-of-tree module taints kernel.
[4.513052] vboxdrv: Found 4 processor cores
[4.550002] vboxdrv: TSC mode is Invariant, tentative frequency 2394456842 Hz
[4.550010] vboxdrv: Successfully loaded version 5.1.24 (interface 
0x002a)
[4.757739] vga_switcheroo: enabled
[4.759688] [TTM] Zone  kernel: Available graphics memory: 3936360 kiB
[4.759697] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[4.759702] [TTM] Initializing pool allocator
[4.759713] [TTM] Initializing DMA pool allocator
[4.759745] nouveau :04:00.0: DRM: VRAM: 2048 MiB
[4.759751] nouveau :04:00.0: DRM: GART: 1048576 MiB
[4.759758] nouveau :04:00.0: DRM: Pointer to TMDS table invalid
[4.759765] nouveau :04:00.0: DRM: DCB version 4.0
[4.759771] nouveau :04:00.0: DRM: Pointer to flat panel table invalid
[4.769589] VBoxNetFlt: Successfully started.
[4.781443] VBoxNetAdp: Successfully started.
[4.784878] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[4.786983] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
[4.787235] iwlwifi :02:00.0: L1 Enabled - LTR Enabled
[4.788829] VBoxPciLinuxInit
[4.791212] vboxpci: IOMMU not found (not registered)
[4.940291] nouveau :04:00.0: DRM: MM: using COPY for buffer copies
[4.940302] [drm] Initialized nouveau 1.3.1 20120801 for :04:00.0 on 
minor 1
[4.941881] ACPI: Video Device [VID] (multi-head: yes  rom: no  post: no)
[4.942297] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input16
[4.942479] ACPI: Video Device [VID1] (multi-head: yes  rom: yes  post: no)
[4.942567] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0f/LNXVIDEO:01/input/input17
[4.942682] snd_hda_intel :00:03.0: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[4.942695] [drm] Initialized i915 1.6.0

Bug#871639: NULL pointer dereference in reset_common_ring+0xc3/0x170 [i915]

2017-08-10 Thread Bjørn Mork 
Package: src:linux
Version: 4.9.30-2+deb9u3
Severity: normal
File: /boot/vmlinuz-4.9.0-3-amd64

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

I've been having issues with the i915 driver ever since I got this Skylake 
laptop.
The GPU is hanging every now and then.  But the error handling has become worse
over time, from merely pausing a few seconds via X restarting,  to now ooopsing
after updating to 4.9.30-2+deb9u3.

The issue started with a few warnings I've seen before, followed by the oops 
(which
is a new symptom AFAIK):

[drm] GPU HANG: ecode 9:0:0xffd7fffe, in Xorg [842], reason: Hang on render 
ring, action: reset
[drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including 
userspace.
[drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> 
DRM/Intel
[drm] drm/i915 developers can then reassign to the right component if it's not 
a kernel issue.
[drm] The gpu crash dump is required to analyze gpu hangs, so please always 
attach it.
[drm] GPU crash dump saved to /sys/class/drm/card0/error
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 3 PID: 842 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: ses enclosure sd_mod scsi_transport_sas sg uas usb_storage 
scsi_mod rfcomm ctr ccm ipt_REJECT nf_reject_ipv4 iptable_filter xt_set 
ip_set_hash_ip ip_set nfnetlink 8021q garp mrp stp llc tun cmac bnep arc4 
snd_hda_codec_hdmi snd_hda_codec_conexant intel_rapl x86_pkg_temp_thermal 
intel_powerclamp snd_hda_codec_generic coretemp kvm_intel kvm irqbypass 
snd_soc_skl snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp crct10dif_pclmul 
snd_hda_ext_core crc32_pclmul snd_soc_sst_match nls_ascii snd_soc_core 
nls_cp437 ghash_clmulni_intel cdc_mbim snd_compress cdc_wdm cdc_ncm usbnet 
qcserial intel_cstate usb_wwan vfat mii fat usbserial sparse_keymap iwlmvm 
btusb btrtl btbcm btintel bluetooth mac80211 intel_uncore iwlwifi efi_pstore 
snd_hda_intel intel_rapl_perf snd_hda_codec evdev
 iTCO_wdt joydev snd_hda_core snd_hwdep snd_pcm serio_raw efivars 
iTCO_vendor_support i915 snd_timer hid_sensor_accel_3d uvcvideo 
hid_sensor_trigger videobuf2_vmalloc hid_sensor_iio_common videobuf2_memops 
cfg80211 industrialio_triggered_buffer videobuf2_v4l2 kfifo_buf rtsx_pci_ms 
thinkpad_acpi videobuf2_core drm_kms_helper industrialio nvram memstick 
videodev drm mei_me snd media soundcore mei shpchp intel_pch_thermal rfkill ac 
battery i2c_algo_bit video tpm_crb wmi button parport_pc ppdev lp parport 
sunrpc efivarfs ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache 
crc32c_generic hid_sensor_custom hid_sensor_hub intel_ishtp_hid hid 
rtsx_pci_sdmmc mmc_core crc32c_intel aesni_intel aes_x86_64 glue_helper lrw 
gf128mul ablk_helper cryptd i2c_i801 psmouse i2c_smbus e1000e ptp nvme pps_core 
nvme_core xhci_pci xhci_hcd rtsx_pci mfd_core usbcore intel_ish_ipc usb_common 
intel_ishtp thermal
CPU: 3 PID: 842 Comm: Xorg Not tainted 4.9.0-3-amd64 #1 Debian 4.9.30-2+deb9u3
Hardware name: LENOVO 20FB006AMN/20FB006AMN, BIOS N1FET47W (1.21 ) 11/28/2016
  82728574 bea0c2be3b18 
 82476ebe  bea0c2be3b70 9c1b2c59
  9c1b2c565000 0001 82476f3f
Call Trace:
 [] ? dump_stack+0x5c/0x78
 [] ? __warn+0xbe/0xe0
 [] ? warn_slowpath_fmt+0x5f/0x80
 [] ? finish_wait+0x3c/0x70
 [] ? intel_atomic_commit_tail+0xf2b/0xf50 [i915]
 [] ? prepare_to_wait_event+0xf0/0xf0
 [] ? drm_atomic_helper_setup_commit+0x27c/0x380 
[drm_kms_helper]
 [] ? intel_atomic_commit+0x355/0x4c0 [i915]
 [] ? drm_atomic_helper_connector_dpms+0xe8/0x190 
[drm_kms_helper]
 [] ? drm_mode_connector_set_obj_prop+0x5b/0x70 [drm]
 [] ? drm_mode_obj_set_property_ioctl+0x11b/0x160 [drm]
 [] ? drm_mode_connector_property_set_ioctl+0x3e/0x60 [drm]
 [] ? drm_ioctl+0x1ea/0x470 [drm]
 [] ? drm_mode_connector_set_obj_prop+0x70/0x70 [drm]
 [] ? pipe_read+0x288/0x2d0
 [] ? do_vfs_ioctl+0x9f/0x600
 [] ? vfs_read+0x119/0x130
 [] ? SyS_ioctl+0x74/0x80
 [] ? system_call_fast_compare_end+0xc/0x9b
- ---[ end trace 93f14b701ef00ca8 ]---
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
[drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* 
[CRTC:26:pipe A] flip_done timed out
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
drm/i915: Resetting chip after gpu hang
[drm] RC6 on
[drm] GuC firmware load skipped
- [ cut here ]
WARNING: CPU: 2 PID: 879 at 
/build/linux-me40Ry/linux-4.9.30/drivers/gpu/drm/i915/intel_display.c:14180 
intel_atomic_commit_tail+0xf2b/0xf50 [i915]
pipe A vblank wait timed out
Modules linked in: