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 ---
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
I'm assuming this is a display related bug, rather than an OpenGL bug (Mesa). Reassigning.
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
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.
make sure your intel-microcode is up to date. My KBL/NV system had similar issues before I updated that package.
I'd also highly recommend the latest BIOS for the Dell XPS 9560. My system got a lot more stable after updating.
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.
(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.
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...
Created attachment 135198 [details] Kernel log of problematic boot with "drm.debug=0x1e log_bug_len=2M"
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.
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
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.
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.
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!
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.
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.
Jani, can you have a look this?
Please try a more recent kernel.
I'm currently running 4.15.15 (and was during the crash I experienced this morning)
(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
Any updates here Daniel? I will resolve and please reopen if seen still.
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
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.