Bug 103474

Summary:

Hard lock when unplugging and reconnecting external USB-C DP display

Product:

DRI

Reporter:

Daniel Playfair Cal <daniel.playfair.cal>

Component:

DRM/Intel

Assignee:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Status:

CLOSED WORKSFORME

QA Contact:

Intel GFX Bugs mailing list <intel-gfx-bugs>

Severity:

major

Priority:

medium

CC:

daniel.playfair.cal, intel-gfx-bugs, jani.nikula, jan.public, jean-louis, mcepl

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

ReadyForDev

i915 platform:

KBL

i915 features:

display/atomic, display/DP MST

Attachments:

Description	Flags
System log including disconnecting and reconnecting the display	none
System log including disconnecting and reconnecting the display and waiting for automatic reboot	none
Stacktrace of gnome-shell user session crash when disconnecting the display	none
Kernel log of problematic boot with "drm.debug=0x1e log_bug_len=2M"	none
output of journalctl -xb from openSUSE/Tumbleweed kernel-default-4.18.15-1.2.x86_64	none
output of dmidecode	none

Description Daniel Playfair Cal 2017-10-26 22:09:47 UTC

Created attachment 135093 [details]
System log including disconnecting and reconnecting the display

Using the mesa intel driver, when I disconnect an external screen, all the screens turn on and off repeatedly, and then when I reconnect it, I get a hard system lock.

I have a laptop (Dell XPS 9560) with internal graphics (Kaby Lake) and also NVIDIA discrete graphics, but this is not used in my setup. The laptop has an HDMI output and a USB-C port, both connected to the intel graphics.

I'm running Arch linux
kernel 4.13.8
mesa 17.2.2
gnome-shell 3.26.1 with wayland
mutter 3.26.1 with patch from here: https://bugzilla.gnome.org/show_bug.cgi?id=789501 (doesn't affect the hard lock but prevents the shell from crashing on disconnect)

The HDMI port is connected to a external Viewsonic VX2433WM with HDMI
The USB-C port is connected to an adapter (https://www.scorptec.com.au/product/Adapters/USB/63599-UCDP-ADP?gclid=CjwKCAjwj8bPBRBiEiwASlFLFWzBo5Yv8-dz5Adk7SaR0JHZYLOK0Vrc-7om229vKYUmqRsWUkOXVBoC_FEQAvD_BwE), which is connected to a Dell U2515H with a displayport cable.

I have set the following options for the i915 kernel module:
i915 enable_psr=1 disable_power_well=0

Possibly notable entries in the log include:
Oct 27 08:26:56 danielpc-arch kernel: xhci_hcd 0000:3e:00.0: xHCI host controller not responding, assume dead
Oct 27 08:26:56 danielpc-arch kernel: xhci_hcd 0000:3e:00.0: HC died; cleaning up
Oct 27 08:26:56 danielpc-arch kernel: hub 3-0:1.0: activate --> -19
Oct 27 08:27:01 danielpc-arch kernel: [drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
Oct 27 08:27:01 danielpc-arch kernel: pcieport 0000:00:1d.6: AER: Corrected error received: id=00ee
Oct 27 08:27:01 danielpc-arch kernel: pcieport 0000:00:1d.6: PCIe Bus Error: severity=Corrected, type=Physical Layer, id=00ee(Receiver ID)
Oct 27 08:27:01 danielpc-arch kernel: pcieport 0000:00:1d.6:   device [8086:a11e] error status/mask=00000001/00002000
Oct 27 08:27:01 danielpc-arch kernel: pcieport 0000:00:1d.6:    [ 0] Receiver Error         (First)
Oct 27 08:27:01 danielpc-arch kernel: [drm:intel_mst_pre_enable_dp [i915]] *ERROR* failed to allocate vcpi
Oct 27 08:27:23 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:27 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:31 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:35 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:39 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:43 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:27:46 danielpc-arch kernel: i2c i2c-4: sendbytes: NAK bailout.
Oct 27 08:28:11 danielpc-arch kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
Oct 27 08:28:11 danielpc-arch kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
Oct 27 08:28:11 danielpc-arch kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
Oct 27 08:28:12 danielpc-arch kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
Oct 27 08:28:12 danielpc-arch kernel: [drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit
Oct 27 08:28:12 danielpc-arch kernel: [drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
Oct 27 08:28:39 danielpc-arch kernel: [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO underrun

--- gnome-shell crashes, hard lock occurs, gnome-shell coredump does not complete in time ---

Comment 1 Daniel Playfair Cal 2017-10-26 22:27:30 UTC

I've tried removing the non standard i915 options, and the problem is the same.

It seems like sometimes after hard locking for a while, my system reboots but then turns off before getting past the BIOS

Comment 2 Kenneth Graunke 2017-10-26 22:31:49 UTC

I'm assuming this is a display related bug, rather than an OpenGL bug (Mesa).  Reassigning.

Comment 3 Daniel Playfair Cal 2017-10-26 22:36:22 UTC

Created attachment 135094 [details]
System log including disconnecting and reconnecting the display and waiting for automatic reboot

This is another log having disabled my non default i915 module options, including waiting for the automatic reboot after the hard lock. There are some different error messages and a stacktrace. The reboot that crashed in the BIOS did not generate any logs.

Highlights:
Oct 27 09:20:36 danielpc-arch kernel: i915 0000:00:02.0: HDMI-A-1: EDID is invalid:
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Oct 27 09:20:36 danielpc-arch kernel:         [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Oct 27 09:21:30 danielpc-arch kernel: [drm:intel_mst_enable_dp [i915]] *ERROR* Timed out waiting for ACT sent
Oct 27 09:21:30 danielpc-arch kernel: pipe C vblank wait timed out
Oct 27 09:21:30 danielpc-arch kernel: ------------[ cut here ]------------
Oct 27 09:21:30 danielpc-arch kernel: WARNING: CPU: 1 PID: 1156 at drivers/gpu/drm/i915/intel_display.c:12848 intel_atomic_commit_tail+0xf6f/0xf80 [i915]
Oct 27 09:21:30 danielpc-arch kernel: Modules linked in: fuse ccm rfcomm hid_generic usbhid uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev media btusb btrtl snd_hda_codec_hdmi
Oct 27 09:21:30 danielpc-arch kernel:  idma64 i2c_algo_bit drm_kms_helper rtsx_pci_ms cfg80211 memstick drm mei_me intel_gtt mei agpgart hci_uart syscopyarea sysfillrect intel_lpss_pci i2c_hid intel_pch_thermal 
Oct 27 09:21:30 danielpc-arch kernel:  i8042 serio
Oct 27 09:21:30 danielpc-arch kernel: CPU: 1 PID: 1156 Comm: gnome-shell Tainted: G           O    4.13.8-1-ARCH #1
Oct 27 09:21:30 danielpc-arch kernel: Hardware name: Dell Inc. XPS 15 9560/05FFDN, BIOS 1.4.0 08/23/2017
Oct 27 09:21:30 danielpc-arch kernel: task: ffff95bc6aa16c80 task.stack: ffffb453c19ac000
Oct 27 09:21:30 danielpc-arch kernel: RIP: 0010:intel_atomic_commit_tail+0xf6f/0xf80 [i915]
Oct 27 09:21:30 danielpc-arch kernel: RSP: 0018:ffffb453c19afa90 EFLAGS: 00010286
Oct 27 09:21:30 danielpc-arch kernel: RAX: 000000000000001c RBX: 0000000000000002 RCX: 0000000000000000
Oct 27 09:21:30 danielpc-arch kernel: RDX: 0000000000000000 RSI: ffff95bc7f44dc78 RDI: ffff95bc7f44dc78
Oct 27 09:21:30 danielpc-arch kernel: RBP: ffffb453c19afb48 R08: 000000000000048e R09: 0000000000000004
Oct 27 09:21:30 danielpc-arch kernel: R10: ffffb453c19afa90 R11: 0000000000000001 R12: 000000000000735a
Oct 27 09:21:30 danielpc-arch kernel: R13: ffff95bc5d498000 R14: ffff95bc5ed08000 R15: 0000000000000004
Oct 27 09:21:30 danielpc-arch kernel: FS:  00007fb0304e8240(0000) GS:ffff95bc7f440000(0000) knlGS:0000000000000000
Oct 27 09:21:30 danielpc-arch kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 27 09:21:30 danielpc-arch kernel: CR2: 00007f199492a000 CR3: 0000000434961000 CR4: 00000000003406e0
Oct 27 09:21:30 danielpc-arch kernel: Call Trace:
Oct 27 09:21:30 danielpc-arch kernel:  ? finish_task_switch+0x75/0x200
Oct 27 09:21:30 danielpc-arch kernel:  ? wait_woken+0x80/0x80
Oct 27 09:21:30 danielpc-arch kernel:  intel_atomic_commit+0x3c7/0x470 [i915]
Oct 27 09:21:30 danielpc-arch kernel:  ? drm_atomic_check_only+0x37b/0x540 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  ? wait_woken+0x80/0x80
Oct 27 09:21:30 danielpc-arch kernel:  drm_atomic_commit+0x4b/0x50 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  drm_atomic_helper_set_config+0x68/0x90 [drm_kms_helper]
Oct 27 09:21:30 danielpc-arch kernel:  __drm_mode_set_config_internal+0x65/0x110 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  drm_mode_setcrtc+0x479/0x630 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  ? drm_mode_getcrtc+0x180/0x180 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  drm_ioctl_kernel+0x5d/0xb0 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  drm_ioctl+0x31b/0x3d0 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  ? drm_mode_getcrtc+0x180/0x180 [drm]
Oct 27 09:21:30 danielpc-arch kernel:  do_vfs_ioctl+0xa5/0x600
Oct 27 09:21:30 danielpc-arch kernel:  ? __fget+0x6e/0x90
Oct 27 09:21:30 danielpc-arch kernel:  SyS_ioctl+0x79/0x90
Oct 27 09:21:30 danielpc-arch kernel:  entry_SYSCALL_64_fastpath+0x1a/0xa5
Oct 27 09:21:30 danielpc-arch kernel: RIP: 0033:0x7fb02fe56157
Oct 27 09:21:30 danielpc-arch kernel: RSP: 002b:00007ffe7452e148 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
Oct 27 09:21:30 danielpc-arch kernel: RAX: ffffffffffffffda RBX: 000055ab797a0810 RCX: 00007fb02fe56157
Oct 27 09:21:30 danielpc-arch kernel: RDX: 00007ffe7452e180 RSI: 00000000c06864a2 RDI: 0000000000000008
Oct 27 09:21:30 danielpc-arch kernel: RBP: 000055ab797a0810 R08: 0000000000000000 R09: 000055ab7c7dffc0
Oct 27 09:21:30 danielpc-arch kernel: R10: 000055ab7c5f7140 R11: 0000000000000246 R12: 0000000000000001
Oct 27 09:21:30 danielpc-arch kernel: R13: 00007ffe7452e050 R14: 00007ffe7452dfd0 R15: 000055ab79821c00
Oct 27 09:21:30 danielpc-arch kernel: Code: ff ff ff 48 83 c7 08 e8 20 14 58 eb 4c 8b 85 70 ff ff ff 4d 85 c0 0f 85 7b fa ff ff 8d 73 41 48 c7 c7 e8 ec c0 c0 e8 82 ca 59 eb <0f> ff e9 65 fa ff ff 66 2e 0f 1f 84 
Oct 27 09:21:30 danielpc-arch kernel: ---[ end trace 66a7709b20598e23 ]---
Oct 27 09:21:40 danielpc-arch kernel: [drm:drm_atomic_helper_commit_cleanup_done [drm_kms_helper]] *ERROR* [CRTC:46:pipe C] flip_done timed out

Comment 4 Chris Wilson 2017-10-26 22:43:00 UTC

That's pretty much just a warning that the cable was unplugged in the middle of dp chatter, not petty but the actual death appears to be Xwayland, which if my memory serves doesn't survive an output disappearing atm.

Comment 5 Mark Janes 2017-10-26 22:52:28 UTC

make sure your intel-microcode is up to date.  My KBL/NV system had similar issues before I updated that package.

Comment 6 Kenneth Graunke 2017-10-27 01:42:53 UTC

I'd also highly recommend the latest BIOS for the Dell XPS 9560.  My system got a lot more stable after updating.

Comment 7 Daniel Playfair Cal 2017-10-28 00:53:52 UTC

Created attachment 135137 [details]
Stacktrace of gnome-shell user session crash when disconnecting the display

It does say "Connection to xwayland lost"

If XWayland can't handle a display being unplugged,then why is it that when I unplug a display without using this usb-c to displayport adapter my shell usually doesn't crash? And how can I see why XWayland crashed?

I updated my BIOS and thunderbolt controller firmware to the latest, I'm not sure if it made any difference.

I tried disabling my display manager, booting into a console, and disconnecting and reconnecting the screen repeatedly. In that case, everything works fine.

Unfortunately the coredump for the second gnome-shell crash never seems to complete. When it crashes after reconnecting the displayport adapter, often the caps lock light flashes on and off repeatedly for a few seconds, then the power light turns off (but the screen statys on). The image of the display manager flashed back on the screen, and then turned black. Next I saw the post screen (power light still off) for a few seconds, then the computer turned off.

My microcode should be up to date - my bootloader is configured as follows:
linux /vmlinuz-linux
initrd /intel-ucode.img
initrd /initramfs-linux.img

and I have intel-ucode 20170707-1 which is the latest for Arch.

Comment 8 Elizabeth 2017-10-31 17:12:06 UTC

(In reply to Daniel Playfair Cal from comment #7)
> Created attachment 135137 [details]
> Stacktrace of gnome-shell user session crash when disconnecting the display
> 
> It does say "Connection to xwayland lost"
> 
> If XWayland can't handle a display being unplugged,then why is it that when
> I unplug a display without using this usb-c to displayport adapter my shell
> usually doesn't crash? And how can I see why XWayland crashed?
> ...
You mean with a cable usb-c to DP or using another dongle or using the HDMI port?

Could you attach full dmesg from boot to problem with debug info (drm.debug=0x1e log_bug_len=2M parameters on grub)? Thank you.

Comment 9 Daniel Playfair Cal 2017-10-31 21:15:27 UTC

The USB-C port is connected to an adapter (https://www.scorptec.com.au/product/Adapters/USB/63599-UCDP-ADP?gclid=CjwKCAjwj8bPBRBiEiwASlFLFWzBo5Yv8-dz5Adk7SaR0JHZYLOK0Vrc-7om229vKYUmqRsWUkOXVBoC_FEQAvD_BwE), which is connected to a Dell U2515H with a displayport cable.

This is the one that I am unplugging. I unplug the adaptor from the computer's USB-C port and then back in, at which point the hard lock happens.

I will collect the log...

Comment 10 Daniel Playfair Cal 2017-10-31 21:34:56 UTC

Created attachment 135198 [details]
Kernel log of problematic boot with "drm.debug=0x1e log_bug_len=2M"

Comment 11 Daniel Playfair Cal 2017-10-31 21:38:42 UTC

This may also be relevant - a bug report for the crashes of gnome-shell I experience before the hang: https://bugzilla.gnome.org/show_bug.cgi?id=789501

This hang does not occur in a console - it only happens if gnome-shell is running in Wayland (I haven't tested other configurations / compositors etc).

Apparently the kernel is reporting invalid information about which displays are connected as soon as the monitor is unplugged.

Comment 12 Elizabeth 2017-11-01 16:01:37 UTC

There are a lot of "Link Training failed" errors through the dmesg. Sample:
...
[drm:drm_dp_dpcd_access [drm_kms_helper]] Too many retries, giving up. First error: -110
[drm:intel_dp_start_link_train [i915]] *ERROR* failed to enable link training
[drm:intel_dp_start_link_train [i915]] Link Training failed at link rate = 540000, lane count = 4
[drm:intel_dp_modeset_retry_work_fn [i915]] [CONNECTOR:63:DP-2]

...
[drm:intel_dp_start_link_train [i915]] Channel equalization failed 5 times
[drm:intel_dp_set_idle_link_train [i915]] *ERROR* Timed out waiting for DP idle patterns
[drm:intel_dp_start_link_train [i915]] Link Training failed at link rate = 540000, lane count = 4
[drm:intel_dp_modeset_retry_work_fn [i915]] [CONNECTOR:63:DP-2]
[drm:intel_dp_check_mst_status [i915]] got esi 41 10 00
[drm:intel_dp_check_mst_status [i915]] got esi2 41 10 00
[drm:intel_dp_check_mst_status [i915]] channel EQ not ok, retraining
[drm:intel_wait_ddi_buf_idle [i915]] *ERROR* Timeout waiting for DDI BUF C idle bit

Comment 13 Daniel Playfair Cal 2017-12-04 22:28:59 UTC

Something has changed with recent kernels (I'm currently on 4.14.3 but I think the change happened on the 4.13 branch)

Now to reproduce this problem I have to unplug and reinsert the USB-C plug twice, when before it was only once.

Comment 14 Adam Williamson 2017-12-15 00:42:41 UTC

A note on the 'wayland / Shell crash' side of things: the attached logs contain these errors:

Oct 27 08:28:38 danielpc-arch org.gnome.Shell.desktop[7418]: Fatal server error:
Oct 27 08:28:38 danielpc-arch org.gnome.Shell.desktop[7418]: (EE) wl_registry@2: error 0: invalid global wl_output (36)

Oct 27 09:21:30 danielpc-arch org.gnome.Shell.desktop[1156]: Fatal server error:
Oct 27 09:21:30 danielpc-arch org.gnome.Shell.desktop[1156]: (EE) wl_registry@2: error 0: invalid global wl_output (31)

There are several other reports of this. We have several in Fedora, I'm treating https://bugzilla.redhat.com/show_bug.cgi?id=1514220 as the 'master' report and duping others against that. There is also an Ubuntu report in Launchpad:

https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1728588

and an issue on the freedesktop.org Phabricator (I am unclear what the relationship between the Phab instance and this BZ instance is):

https://phabricator.freedesktop.org/T7722

suggesting that there's basically a generic race issue with adding / destroying temporary global objects.

It seems like this particular case has more problems than just the Wayland / Shell crash part, but that's my notes on that part of it.

Comment 15 Jean-Louis Dupond 2017-12-21 09:19:49 UTC

Hi,

I have a similar laptop (Precision 5520), and had the exact same issue.
When I disconnected my WD15 dock (which has an external monitor connected) and reconnected it, everything was hanging, and I had a black screen and same errors.

I tried drm-tip yesterday, and this fixed my issue.
Could you maby try drm-tip? Cause it seems like some recent commit fixed this problem!

Comment 16 Jani Saarinen 2018-03-29 07:11:21 UTC

First of all. Sorry about spam.
This is mass update for our bugs. 

Sorry if you feel this annoying but with this trying to understand if bug still valid or not.
If bug investigation still in progress, please ignore this and I apologize!

If you think this is not anymore valid, please comment to the bug that can be closed.
If you haven't tested with our latest pre-upstream tree(drm-tip), can you do that also to see if issue is valid there still and if you cannot see issue there, please comment to the bug.

Comment 17 Daniel Playfair Cal 2018-04-19 00:19:39 UTC

I just experienced this again

In case its useful, I just experienced a system crash as per https://bugs.freedesktop.org/show_bug.cgi?id=103474

There is no "invalid global wl_output" in the logs, but the stacktrace is similar.

It happenned while I was debugging this issue: https://gitlab.gnome.org/GNOME/mutter/issues/122#

System log with drm.debug=0xff: https://www.dropbox.com/s/82gkxjctnt86t4v/log_mutter_flash.txt?dl=0

Xwayland stack trace:

#0  0x00007fa18dc14860 in raise () from /usr/lib/libc.so.6
No symbol table info available.
#1  0x00007fa18dc15ec9 in abort () from /usr/lib/libc.so.6
No symbol table info available.
#2  0x00005568fb9f3cda in OsAbort ()
No symbol table info available.
#3  0x00005568fb9f97f3 in ?? ()
No symbol table info available.
#4  0x00005568fb9fa615 in FatalError ()
No symbol table info available.
#5  0x00005568fb88560c in ?? ()
No symbol table info available.
#6  0x00007fa18fc1381c in wl_log (fmt=<optimized out>) at src/wayland-util.c:406
        argp = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7ffcd8e13950, reg_save_area = 0x7ffcd8e13890}}
#7  0x00007fa18fc0fb1a in display_handle_error (data=<optimized out>, display=0x5568fd193ad0, object=0x5568fd197fa0, code=0, message=<optimized out>) at src/wayland-client.c:810
        proxy = 0x5568fd197fa0
        object_id = <optimized out>
        interface = <optimized out>
#8  0x00007fa18d38017e in ffi_call_unix64 () at ../src/x86/unix64.S:76
No locals.
#9  0x00007fa18d37faef in ffi_call (cif=cif@entry=0x7ffcd8e13a80, fn=<optimized out>, rvalue=<optimized out>, rvalue@entry=0x0, avalue=avalue@entry=0x7ffcd8e13b50) at ../src/x86/ffi64.c:525
        classes = {X86_64_INTEGER_CLASS, X86_64_NO_CLASS, X86_64_SSE_CLASS, X86_64_NO_CLASS}
        stack = <optimized out>
        argp = <optimized out>
        arg_types = <optimized out>
        gprcount = 5
        ssecount = <optimized out>
        ngpr = 1
        nsse = 0
        i = <optimized out>
        avn = <optimized out>
        ret_in_memory = <optimized out>
        reg_args = <optimized out>
#10 0x00007fa18fc12399 in wl_closure_invoke (closure=0x5568fde2f810, flags=1, target=<optimized out>, opcode=0, data=<optimized out>) at src/connection.c:935
        count = <optimized out>
        cif = {abi = FFI_UNIX64, nargs = 5, arg_types = 0x7ffcd8e13aa0, rtype = 0x7fa18d380570 <ffi_type_void>, bytes = 0, flags = 0}
        ffi_types = {0x7fa18d380450 <ffi_type_pointer>, 0x7fa18d380450 <ffi_type_pointer>, 0x7fa18d380450 <ffi_type_pointer>, 0x7fa18d3804d0 <ffi_type_uint32>, 0x7fa18d380450 <ffi_type_pointer>, 
          0x7fa18d3804b0 <ffi_type_sint32>, 0x7fa18d3804b0 <ffi_type_sint32>, 0x7fa18d380450 <ffi_type_pointer>, 0x7fa18d380450 <ffi_type_pointer>, 0x7fa18d3804b0 <ffi_type_sint32>, 0x0, 0x0, 0x50000, 
          0xffffffffffffffff, 0x0, 0x7fa18dfa8a68 <recvmsg+104>, 0x34, 0x3, 0x34, 0x5568fd193c40, 0x34, 0x7fa18fc111ac <wl_buffer_copy+112>}
        ffi_args = {0x7ffcd8e13a70, 0x7ffcd8e13a78, 0x5568fde2f828, 0x5568fde2f830, 0x5568fde2f838, 0x7fa18fc114eb <wl_connection_copy+9>, 0x34, 0x7fa18fc13013 <wl_connection_demarshal+1205>, 0x7ffcd8e13bd0, 
          0x5568fde2f914, 0x5568fd193c40, 0x25b, 0x7fa18fe17d20 <wl_display_events>, 0x5568fd193b48, 0x34, 0x7fa18fc121e0 <wl_closure_lookup_objects+160>, 0x5568fd193b48, 0x7fa18fe17d20 <wl_display_events>, 
          0x4b673, 0x7fa18fc0f6aa <increase_closure_args_refcount+74>, 0xfdf2d273, 0xfefc75eb563b5d00}
        implementation = <optimized out>
#11 0x00007fa18fc0ff7a in dispatch_event (display=display@entry=0x5568fd193ad0, queue=queue@entry=0x5568fd193b80) at src/wayland-client.c:1310
        closure = 0x5568fde2f810
        proxy = 0x5568fd193ad0
        opcode = 0
        proxy_destroyed = <optimized out>
#12 0x00007fa18fc0ffbe in dispatch_queue (display=display@entry=0x5568fd193ad0, queue=queue@entry=0x5568fd193b98) at src/wayland-client.c:1449
        count = 0
#13 0x00007fa18fc10c52 in wl_display_dispatch_queue_pending (display=0x5568fd193ad0, queue=0x5568fd193b98) at src/wayland-client.c:1698
        ret = <optimized out>
#14 0x00007fa18fc10c73 in wl_display_dispatch_pending (display=<optimized out>) at src/wayland-client.c:1761
No locals.
#15 0x00005568fb885bbb in ?? ()
No symbol table info available.
#16 0x00005568fb9f1851 in ?? ()
No symbol table info available.
#17 0x00005568fb9ea6fb in WaitForSomething ()
No symbol table info available.
#18 0x00005568fb9b6503 in ?? ()
No symbol table info available.
#19 0x00005568fb9ba7a0 in ?? ()
No symbol table info available.
#20 0x00007fa18dc00f4a in __libc_start_main () from /usr/lib/libc.so.6
No symbol table info available.
#21 0x00005568fb88523a in _start ()
No symbol table info available.

Comment 18 Jani Saarinen 2018-04-19 06:43:48 UTC

Jani, can you have a look this?

Comment 19 Jani Nikula 2018-04-19 12:39:04 UTC

Please try a more recent kernel.

Comment 20 Daniel Playfair Cal 2018-04-19 12:47:15 UTC

I'm currently running 4.15.15 (and was during the crash I experienced this morning)

Comment 21 Jani Nikula 2018-04-19 13:54:31 UTC

(In reply to Daniel Playfair Cal from comment #20)
> I'm currently running 4.15.15 (and was during the crash I experienced this
> morning)

Please try drm-tip branch of [1] and, if that doesn't work, also apply https://bugs.freedesktop.org/show_bug.cgi?id=104425#c18 on top.

[1] https://cgit.freedesktop.org/drm/drm-tip

Comment 22 Jani Saarinen 2018-05-04 09:57:17 UTC

Any updates here Daniel? I will resolve and please reopen if seen still.

Comment 23 Matej Cepl 2018-11-08 14:57:42 UTC

Created attachment 142411 [details]
output of journalctl -xb from openSUSE/Tumbleweed kernel-default-4.18.15-1.2.x86_64

Could somebody say whether this is the same bug? I have ThinkPad T480 connected to Samsung SyncMaster 2243 (so I have dual head setup).

Using openSUSE/Tumbleweed with

kernel-default-4.18.15-1.2.x86_64
xorg-x11-server-wayland-1.20.2-1.1.x86_64
xorg-x11-driver-video-7.6_1-17.2.x86_64
intel-vaapi-driver-2.1.0-2.1.x86_64
kernel-firmware-20181001-1.1.noarch

Comment 24 Matej Cepl 2018-11-08 14:58:17 UTC

Created attachment 142412 [details]
output of dmidecode

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.