| Summary: | DP MST: re-docking messes up displays | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | DRI | Reporter: | Daniel Michalik <dev> | ||||||||||||||
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||||||
| Severity: | normal | ||||||||||||||||
| Priority: | medium | CC: | dion, georgmueller, intel-gfx-bugs, leho | ||||||||||||||
| Version: | XOrg git | ||||||||||||||||
| Hardware: | x86-64 (AMD64) | ||||||||||||||||
| OS: | Linux (All) | ||||||||||||||||
| Whiteboard: | |||||||||||||||||
| i915 platform: | HSW | i915 features: | display/DP MST | ||||||||||||||
| Attachments: |
|
||||||||||||||||
|
Description
Daniel Michalik
2014-10-06 14:22:47 UTC
Created attachment 107430 [details]
X log
Comment: This might or might not be connected to #84717. In the Xlog there are entries that indicate that it was detected that the laptop was undocked:
[ 5483.415] removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-5 (null)
[ 5484.975] removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-4 (null)
[ 5485.017] removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-3 (null)
However those refer to DP-3, DP-4, and DP-5, rather than to the xrandr designators used (DP2-1, DP2-2, DP2-3).
The unknown is from sna_output_detect() calling DRM_IOCTL_MODE_GETCONNECTOR on an invalid connector. The output should have been disconnected by the hotplug notification... except that you do not have udev monitoring compiled into your ddx (or it failed to be initialised). In the short term, check your build to see why udev is not configured. My challenge is to handle it more gracefully. Created attachment 107435 [details] Xorg.log with udev Chris, thank you for your quick answer. I installed libudev-dev and reconfigured + compiled + installed the video driver. Undocking now causes the laptop screen to show some part of the entire picture, and seemingly not reacting to my keypresses. Re-docking brings back the screens, but X does not react to inputs, no mouse cursor visible. xlog attached. The messages: [ 40.992] (II) intel(0): Disabled output DP2-1 upon undock [ 58.881] (II) intel(0): Enabled output DP2-1 upon re-dock seem to be new and seemingly make sense. DP-5 (which does not exist according to xrandr) gets removed upon undock: [ 39.579] removing GPU device /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-5 (null) Same for DP-4 and DP-3, a while later. At 58 seconds I re-dock, and DP-3 and DP-4 are getting *removed* a second time now, rather than readded. [ 59.168] (II) intel(0): switch to mode 1920x1080@60.0 on DP2-1 using pipe 1, position (0, 0), rotation normal, reflection none seems to be the right thing to do, however my X remains unusable in this moment. The log ends. Are you positive that is is unresposiveness and not just an invisible cursor? (There is a mystery in the kernel there.) It is a good question what exactly "unreponsive" means. System did not execute keystrokes, i.e. open applications/a terminal. I did not try logging in remotely. I triggered a reboot through Alt+Sysreq B. In addition, I think the symptoms vary from time to time I try. I'm not yet seeing a pattern. If you have suggestions what exactly to test, I'll be happy to execute it. Okay, one thing that got clearer to me now: Udev is also the mechanism for triggering the xrandr auto-configuration. That means there is a very fundamental difference between my first and my second report, namely a number of xrandr commands executed when docking and un-docking in the second, but not in the first scenario (since no udev support). One bug is then, I guess, the non-graceful handling of the non-udev situation, but do not seem to be the reason for the other glitches I observed. I'll keep playing with it and will try to provide more information for you. I am not sure. I like returning Unknown there for the ioctl failure - actually cleaning the dead outputs at that point is impossible (at least I can't rearrange or destroy the outputs whilst the core is iterating over the array). We could replace the udev notification with a poll for changes in output status - but that is just replicating work already done by the kernel. And I can't see a suitable hook for adding a global probe into the RandR query - unless I wrap the rrGetInfo hook... Okay that is tempting. Created attachment 107442 [details] [review] Wrap rrGetInfo Could you rebuild without udev (--disable-udev iirc) and see if this hack works at all? Created attachment 107459 [details] [review] Wrap rrGetInfo commit 9ed1ac8b506509be410c12870397417c7638886e Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Oct 6 21:37:14 2014 +0100 sna: Wrap rrGetInfo so that we can probe when udev is not active If the ddx is configured without udev support, we do not receive notifications when the MST topology is changed. This leads us to query the kernel for bad connectors, and so we end up reporting an unknown connection status for them, which the user and client often find confusing. However, we can not simply act upon the detection failure as we are too deep inside the callback chain and cannot change the arrays of known connectors whilst iterating over them. A neat compromise is to hook into the rrGetInfo call chain and poll for MST changes before we report back the current configuration. References: https://bugs.freedesktop.org/show_bug.cgi?id=84718 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> But obviously we need to track down the current severe misbehaviour. Could you try compiling the ddx with --enable-debug[=full] to see if that generates any useful information before it dies? Using 57c48e4973ac0dad09744eaa82315a5f023094e7, built with --disable-udev. After un-docking I now get the following xrandr output, which matches my expectations. $ xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 eDP1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 59.93 1680x1050 59.95 59.88 1600x1024 60.17 1400x1050 59.98 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1360x768 59.80 59.96 1152x864 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP2-1 disconnected (normal left inverted right x axis y axis) DP2-2 disconnected (normal left inverted right x axis y axis) DP2-3 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) I will get you a full log and more symptoms on the freezing behaviour as well. I'm uploading Xorg log (large, cannot attach it here) with full debug after multiple undock, re-dock actions. I will add a URL in a moment. Screens were auto-configured on each of the dock events triggered by udev. During the last undock a crash occured: the mouse cursor is visible and changes icon based on position and keypresses (e.g. to an input symbol, to an arrow, size when clicking), however keypresses and clicks trigger no changes/usable inputs. It is not possible to change to VT. After the last undock a re-dock was done, but did not restore functionality. I killed the machine using ALT+Sysreq B. URL: www.argafal.de/public/Xorg.0.log.old.bz2 Here I will describe another peculiarity connected to MST. It might be connected to this bug, or could become a separate issue. I have the laptop in the dock, and I disabled the xrandr auto-configure rule in udev. xrandr output: $ xrandr Screen 0: minimum 8 x 8, current 3120 x 2160, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+1080 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 59.93 1680x1050 59.95 59.88 1600x1024 60.17 1400x1050 59.98 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1360x768 59.80 59.96 1152x864 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP2-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 531mm x 299mm 1920x1080 60.00*+ 1600x1200 60.00 1680x1050 59.88 1280x1024 75.02 60.02 1440x900 59.90 1280x960 60.00 1152x864 75.00 1024x768 75.08 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 640x480 75.00 72.81 66.67 60.00 720x400 70.08 DP2-2 connected 1200x1600+1920+0 left (normal left inverted right x axis y axis) 432mm x 324mm 1600x1200 59.98*+ 1280x1024 75.02 60.02 1152x864 75.00 1024x768 75.08 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 640x480 75.00 72.81 66.67 60.00 720x400 70.08 DP2-3 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) I undock. $ xrandr Screen 0: minimum 8 x 8, current 3120 x 2160, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+1080 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 59.93 1680x1050 59.95 59.88 1600x1024 60.17 1400x1050 59.98 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1360x768 59.80 59.96 1152x864 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP2-1 disconnected (normal left inverted right x axis y axis) DP2-2 disconnected (normal left inverted right x axis y axis) DP2-3 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) My screen output on the laptop (eDP1) does not change, I don't get the typical feature of a primary screen (such as the dock, status bar, clock, etc). The mouse cursor cannot leave the screen, so there is no other screen active that I could reach but not see. All of this is not my point, just a description of what I see. The peculiarity is, that I can change the status by disabling the unconnected DP2-3 (which was never connected before) with 'xrandr --output DP2-3 --off', and voila, my laptop screen changes to become the main screen with all the expected features. $ xrandr Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767 eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 175mm 1920x1080 60.01*+ 59.93 1680x1050 59.95 59.88 1600x1024 60.17 1400x1050 59.98 1280x1024 60.02 1440x900 59.89 1280x960 60.00 1360x768 59.80 59.96 1152x864 60.00 1024x768 60.00 800x600 60.32 56.25 640x480 59.94 DP1 disconnected (normal left inverted right x axis y axis) DP2 disconnected (normal left inverted right x axis y axis) DP2-1 disconnected (normal left inverted right x axis y axis) DP2-2 disconnected (normal left inverted right x axis y axis) DP2-3 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) (In reply to Daniel Michalik from comment #14) > Here I will describe another peculiarity connected to MST. It might be > connected to this bug, or could become a separate issue. I have the laptop > in the dock, and I disabled the xrandr auto-configure rule in udev. I think that is actually a pecularity of xrandr - the last step at least. The initial problem is that the extended desktop is transformed into a constrained viewport of the original (which is a no-op, just disabling the unused outputs and updating the cursor bounds). You either want to reduce the framebuffer size (like xrandr did at the end), or specify that the eDP now wants to pan the entire desktop. The other issue here though is that although you have the eDP marked as primary, your DE doesn't seem to be using it for the status bar etc. (But each to their own tastes ;) The current do-noting approach works well if you immediately plug everything back in, the windows do not move and you find everything where you left it. However, often you do want to rearrange after unplugging. The right approach for us is, of course, to leave it to the user (or de on their behalf) to decide. I understand your reasoning about the last bit I reported. I don't think it is worth taking it up with Xfce to change the current behaviour, I can live with that one just fine by reconfiguring screens when something is unplugged/plugged in. I am still confused though why disabling a 'never-been-used' output should change the framebuffer size. I think this does not happen with non-MST outputs. Do you think this should be filed as an xrandr bug? Do you have any comment to the actual crash? Sorry for the 110 MB Xlog. ;) The session was just two minutes long or so, but starting at 320 everything goes haywire. I think it is connected to a timing issue, let me elaborate. Undocking causes a drm udev event which calls a shell-script. The first thing this does is to query /sys/class/drm/*/status to find out what the new configuration looks like, and then calls a handful of xrandr queries. Nothing else, and none of that should be able to cause a crash. What if /sys/class/drm/*/status of the MST ports is queried before they are removed/updated? It looks like, from the log, as if it happens instantaneous only for DP-5, but DP-3 and DP-4 follow a few seconds later, that could be just enough time for my script to try to query them in-between. Interesting enough, if I disable the udev triggering, undock, wait 10s, and then execute the script manually, it never seems to fail. Small number statistics, admittedly. Another thing I still haven't understood. Upon undocking, DP-3, DP-4, and DP-5 get removed according to the log. Upon re-docking they get removed again, according to the log. Two comments: a) They shouldn't exist when re-docking? b) They should be added, not removed when re-docking? (In reply to Daniel Michalik from comment #17) > Another thing I still haven't understood. Upon undocking, DP-3, DP-4, and > DP-5 get removed according to the log. Upon re-docking they get removed > again, according to the log. Two comments: > a) They shouldn't exist when re-docking? > b) They should be added, not removed when re-docking? It's just a bad log message. It's in the core Xorg code to handle hotplugging of whole GPU devices and responds to any drm hotplug event and prints confusing log messages. The interesting thing about the log you pasted is that it dies on a modesetting operation. I guess drm.debug=6 dmesg would be relevant as well. Another problem is that you are using Present, which is broken across screen resizes. You could try compiling the ddx with --disable-dri3 to see if that helps at all. But I think dmesg is the next step towards working out the cause of the freeze. Chris Wilson wrote: > It's just a bad log message. It's in the core Xorg code to handle > hotplugging of whole GPU devices and responds to any drm hotplug event and > prints confusing log messages. Understood. Maybe that could be fixed to avoid confusion? > The interesting thing about the log you pasted is that it dies on a > modesetting operation. Ok, so nothing to do with the /sys/class/drm/*/status queries then. I need a few pointers to provide more information: > I guess drm.debug=6 dmesg would be relevant as well. What do you mean by 'drm.debug=6 dmesg'? Do I need to change dmesg settings in some way (how)? I can access dmesg of a (future) crashed session through /var/log/dmesg.1, but I don't know how to change the debug level that is written into this file. > Another problem is that you are using Present, What is 'Present'? > which is broken across screen resizes. How so, where can I read more? > You could try compiling the ddx with --disable-dri3 to see if that > helps at all. Ok. Let's try to get you more information first. > But I think dmesg is the next step towards working out the > cause of the freeze. I'll be happy to. Could you please point me at how to do that? (In reply to Daniel Michalik from comment #19) > Chris Wilson wrote: > > I guess drm.debug=6 dmesg would be relevant as well. > > What do you mean by 'drm.debug=6 dmesg'? Oh, I see, it's just a kernel parameter. Got it, will try to reproduce this now. Created attachment 107607 [details]
syslog with drm.debug=6
I also found this in yesterday's log. No idea if it is connected to anything or not. Oct 8 14:21:16 AgnesGru console-kit-daemon[1042]: (process:25701): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed Oct 8 14:21:16 AgnesGru kernel: [ 1481.342305] ------------[ cut here ]------------ Oct 8 14:21:16 AgnesGru kernel: [ 1481.342337] WARNING: CPU: 2 PID: 945 at /build/linux-TfYgVl/linux-3.17~rc5/drivers/gpu/drm/i915/i915_gem.c:5011 i915_gem_track_fb+0xf1/0x130 [i915]() Oct 8 14:21:16 AgnesGru kernel: [ 1481.342389] Modules linked in: rfcomm binfmt_misc bnep nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc arc4 iTCO_wdt iTCO_vendor_support x86_pkg_temp_thermal intel_powerclamp intel_rapl coretemp ecb uvcvideo iwlmvm videobuf2_vmalloc kvm videobuf2_memops cdc_mbim videobuf2_core v4l2_common mac80211 videodev psmouse media pcspkr serio_raw i2c_i801 joydev cdc_ncm usbnet mii cdc_wdm evdev cdc_acm btusb snd_hda_codec_realtek iwlwifi bluetooth snd_hda_codec_generic rtsx_pci_ms cfg80211 memstick i915 wmi thinkpad_acpi nvram tpm_tis snd_hda_intel drm_kms_helper tpm rfkill battery ac snd_hda_controller drm intel_smartconnect snd_hda_codec mei_me i2c_algo_bit snd_hwdep video i2ccore snd_pcm mei snd_timer snd button lpc_ich soundcore shpchp processor fuse parport_pc ppdev lp parport autofs4 ext4 crc16 mbcache jbd2 algif_skcipher af_alg hid_generic hid_microsoft usbhid hid dm_crypt dm_mod sg sd_mod crc_t10dif crct10dif_generic ahci libahci rtsx_pci_sdmmc mmc_core crct10dif_pclmul crct10dif_common crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd libata ehci_pci scsi_mod xhci_hcd ehci_hcd rtsx_pci mfd_core e1000e usbcore ptp usb_common pps_core thermal thermal_sys Oct 8 14:21:16 AgnesGru kernel: [ 1481.342424] CPU: 2 PID: 945 Comm: Xorg Not tainted 3.17-rc5-amd64 #1 Debian 3.17~rc5-1~exp1 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342426] Hardware name: LENOVO 20AQ0069MH/20AQ0069MH, BIOS GJET71WW (2.21 ) 02/10/2014 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342430] 0000000000000009 ffffffff8150e2a6 0000000000000000 ffffffff810668a7 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342433] ffff8802146b8e40 ffff8802146b8e40 ffff880214a71dc0 ffff8802146b8e40 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342435] ffff8802146b8e40 ffffffffa04e1cd1 00000010146b8e40 ffff880213102000 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342437] Call Trace: Oct 8 14:21:16 AgnesGru kernel: [ 1481.342442] [<ffffffff8150e2a6>] ? dump_stack+0x41/0x51 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342448] [<ffffffff810668a7>] ? warn_slowpath_common+0x77/0x90 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342463] [<ffffffffa04e1cd1>] ? i915_gem_track_fb+0xf1/0x130 [i915] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342483] [<ffffffffa0512534>] ? __intel_set_mode+0x694/0x15f0 [i915] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342500] [<ffffffffa051a9e2>] ? intel_set_mode+0x12/0x30 [i915] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342516] [<ffffffffa051b93e>] ? intel_crtc_set_config+0x91e/0xe20 [i915] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342529] [<ffffffffa044bba4>] ? drm_mode_set_config_internal+0x64/0xf0 [drm] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342537] [<ffffffffa04847bb>] ? restore_fbdev_mode+0xab/0xd0 [drm_kms_helper] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342543] [<ffffffffa04847fe>] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x1e/0x30 [drm_kms_helper] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342550] [<ffffffffa0486352>] ? drm_fb_helper_set_par+0x22/0x60 [drm_kms_helper] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342556] [<ffffffffa04862e7>] ? drm_fb_helper_hotplug_event+0x87/0xd0 [drm_kms_helper] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342562] [<ffffffffa048636a>] ? drm_fb_helper_set_par+0x3a/0x60 [drm_kms_helper] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342578] [<ffffffffa0526116>] ? intel_fbdev_set_par+0x16/0x60 [i915] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342582] [<ffffffff8131048e>] ? fb_set_var+0x15e/0x3b0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342591] [<ffffffffa027aff0>] ? jbd2_journal_dirty_metadata+0xc0/0x290 [jbd2] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342599] [<ffffffffa027aae6>] ? do_get_write_access+0x336/0x4e0 [jbd2] Oct 8 14:21:16 AgnesGru kernel: [ 1481.342602] [<ffffffff811d7dba>] ? __getblk+0x2a/0x2e0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342607] [<ffffffff813078cb>] ? fbcon_blank+0x1cb/0x2b0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342612] [<ffffffff8137aff1>] ? do_unblank_screen+0xb1/0x1d0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342616] [<ffffffff81371cc4>] ? vt_ioctl+0x564/0x10d0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342622] [<ffffffff813669ec>] ? tty_ioctl+0x26c/0xb40 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342626] [<ffffffff811bd84f>] ? dput+0x1f/0x170 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342629] [<ffffffff811b9e7f>] ? do_vfs_ioctl+0x2cf/0x4b0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342634] [<ffffffff8108062c>] ? task_work_run+0x9c/0xd0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342637] [<ffffffff811ba0e1>] ? SyS_ioctl+0x81/0xa0 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342642] [<ffffffff8151452a>] ? int_signal+0x12/0x17 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342646] [<ffffffff8151426d>] ? system_call_fast_compare_end+0x10/0x15 Oct 8 14:21:16 AgnesGru kernel: [ 1481.342648] ---[ end trace 9df8acf9d9712225 ]--- Oct 8 14:21:16 AgnesGru kernel: [ 1481.430313] ------------[ cut here ]----------- Created attachment 107608 [details] syslog for kernel bug mentioned in comment 22 I think I remember this. I had compiled a new ddx and wanted to restart X. I either executed /etc/init.d/xlim restart, or kill -9 -1 as a user. Either way, the machine become completely unusable (black screens, white non-blinking cursor, no reaction to any input) and had to be killed through Sysreq. Oct 9 11:53:42 XY kernel: [ 228.226045] [drm:drm_mode_setcrtc] [CRTC:7] Oct 9 11:53:42 XY kernel: [ 228.226048] [drm:drm_mode_setcrtc] [CONNECTOR:18:eDP-1] Oct 9 11:53:42 XY kernel: [ 228.226050] [drm:intel_crtc_set_config] [CRTC:7] [FB:191] #connectors=1 (x y) (0 0) Oct 9 11:53:42 XY kernel: [ 228.226054] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:7], mode_changed=0, fb_changed=1 Oct 9 11:53:42 XY kernel: [ 228.226055] [drm:intel_modeset_stage_output_state] [CONNECTOR:18:eDP-1] to [CRTC:7] Oct 9 11:53:42 XY kernel: [ 228.226056] [drm:intel_modeset_stage_output_state] [CONNECTOR:110:DP-3] to [CRTC:11] Oct 9 11:53:42 XY kernel: [ 228.226057] [drm:intel_modeset_stage_output_state] [CONNECTOR:118:DP-4] to [CRTC:15] Oct 9 11:53:42 XY kernel: [ 228.226063] [drm:ironlake_update_primary_plane] Writing base 08905000 00000000 0 0 12800 Oct 9 11:53:42 XY kernel: [ 228.238631] [drm:drm_mode_setcrtc] [CRTC:11] Oct 9 11:53:42 XY kernel: [ 228.238635] [drm:drm_mode_setcrtc] [CONNECTOR:110:DP-3] Oct 9 11:53:42 XY kernel: [ 228.238637] [drm:intel_crtc_set_config] [CRTC:11] [FB:191] #connectors=1 (x y) (0 0) Oct 9 11:53:42 XY kernel: [ 228.238640] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:11], mode_changed=0, fb_changed=1 Oct 9 11:53:42 XY kernel: [ 228.238641] [drm:intel_modeset_stage_output_state] [CONNECTOR:18:eDP-1] to [CRTC:7] Oct 9 11:53:42 XY kernel: [ 228.238642] [drm:intel_modeset_stage_output_state] [CONNECTOR:110:DP-3] to [CRTC:11] Oct 9 11:53:42 XY kernel: [ 228.238643] [drm:intel_modeset_stage_output_state] [CONNECTOR:118:DP-4] to [CRTC:15] Oct 9 11:53:42 XY kernel: [ 228.238649] [drm:ironlake_update_primary_plane] Writing base 08905000 00000000 0 0 12800 Oct 9 11:53:42 XY kernel: [ 228.254619] [drm:drm_mode_setcrtc] [CRTC:15] Oct 9 11:53:42 XY kernel: [ 228.254623] [drm:drm_mode_setcrtc] [CONNECTOR:118:DP-4] Oct 9 11:53:42 XY kernel: [ 228.254624] [drm:intel_crtc_set_config] [CRTC:15] [FB:191] #connectors=1 (x y) (0 0) Oct 9 11:53:42 XY kernel: [ 228.254628] [drm:intel_set_config_compute_mode_changes] computed changes for [CRTC:15], mode_changed=0, fb_changed=1 Oct 9 11:53:42 XY kernel: [ 228.254630] [drm:intel_modeset_stage_output_state] [CONNECTOR:18:eDP-1] to [CRTC:7] Oct 9 11:53:42 XY kernel: [ 228.254631] [drm:intel_modeset_stage_output_state] [CONNECTOR:110:DP-3] to [CRTC:11] Oct 9 11:53:42 XY kernel: [ 228.254631] [drm:intel_modeset_stage_output_state] [CONNECTOR:118:DP-4] to [CRTC:15] And freeze. So we never make it to drm:ironlake_update_primary_plane on the last CRTC. Chris, thank you for looking at it. Did you have a look at the kernel bug as well, do you think it might be related? Also, is there any additional information that I can provide? I'm also hanging out in #intel-gfx on freenode, in case you think it might be easier to have a direct conversation. (In reply to Daniel Michalik from comment #25) > Chris, thank you for looking at it. Did you have a look at the kernel bug as > well, do you think it might be related? Also, is there any additional > information that I can provide? I'm also hanging out in #intel-gfx on > freenode, in case you think it might be easier to have a direct conversation. The kernel warning is unrelated, and I think Daniel has resolved it already. The freeze you experience in X is directly related to the freeze in the kernel. If it is the lockup I expect, it should timeout after 10s. That would be something to check, just wait and see if it recovers eventually. Also checking with drm-intel-nightly has a couple of further lockup reduction patches. (In reply to Chris Wilson from comment #26) > The kernel warning is unrelated, and I think Daniel has resolved it already. > The freeze you experience in X is directly related to the freeze in the > kernel. If it is the lockup I expect, it should timeout after 10s. That > would be something to check, just wait and see if it recovers eventually. > Also checking with drm-intel-nightly has a couple of further lockup > reduction patches. Hi Chris, I did some more experiments. The lockup does not timeout after 10s. Also I correct myself. X does not freeze, but only the 'display' does. The underlying X session seems to be fully functional, except that I can't see any of it. Let me explain: I take out the laptop from the dock. The displays are autoconfigured, but in-between some of the xrandr steps the display 'freezes', and whatever configuration that is is shown until I reboot, no updates occur. It always freezes in the same moment, so the frozen window configuration is always the same, but I cannot pinpoint which was the last successful xrandr command. Once the 'freeze' occurs the image I see does not get updated anymore, but the mouse cursor keeps working. The machine suspends and resumes correctly. It activates the screensaver (I can tell from the fact that the mouse is restricted in its movements to the login box of xlock). Once I type in my password the mouse is free to move along the entire screen again. The mouse cursor updates depending on keypresses, e.g. if I open (blindly) something to write it changes into a input symbol. I can type blindly type commands if I manage to blindly open a terminal. Executing xrandr --auto does not restore the display. I managed to restart by typing Alt+F2 and 'sudo reboot'. If I change to a virutal terminal (Alt+Ctrl+F1) I cannot see anything there either, but the screens update to black. I cannot recover the frozen X image through Alt+Ctrl+F7. I hope this helps to shed some more light on the issue. Let me know if I should conduct further investigations or provide additional log files. Thanks, Daniel Chris, I updated from 3.17-rc5 to 3.17-1-amd64 #1 SMP Debian 3.17-1~exp1 (2014-10-14) x86_64 GNU/Linux. The problem persists with the same symptoms as described in my previous post. There is no 10 second timeout either. Another thing I noticed is that this always happens when un-docking, but has never occurred when docking. Kind regards, Daniel Confirming that this still happens with the newest version, git commit a8d1eaf6ee1fed0aeff681d33864e17cb904ddd3. Kind regards, Daniel Hi Chris, I hate to bother you, but I was just wondering if there is any news regarding this bug? Kind regards, Daniel It looks like I'm experiencing almost same behavior with Lenovo t440p machine and UltraDock on kernel 3.17. The different thing is that I'm not getting any docked connectors in xrandr if I dock laptop on-the-fly. While xorg.log shows followed: (II) intel(0): EDID vendor "LGD", prod id 1034 (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1920x1080"x0.0 140.10 1920 1980 2016 2092 1080 1083 1088 1116 +hsync -vsync (67.0 kHz eP) (II) intel(0): EDID vendor "LGD", prod id 1034 (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1920x1080"x0.0 140.10 1920 1980 2016 2092 1080 1083 1088 1116 +hsync -vsync (67.0 kHz eP) (II) intel(0): EDID vendor "LGD", prod id 1034 (II) intel(0): Printing DDC gathered Modelines: (II) intel(0): Modeline "1920x1080"x0.0 140.10 1920 1980 2016 2092 1080 1083 1088 1116 +hsync -vsync (67.0 kHz eP) After restarting Xorg, everything seems to be ok until I unplug it. Guys CC-d to this bug, you feel like checking out my report at bug 85913? I'm wondering if these things are related here. Please try kernel v4.4. Please reopen if this bug still exists on the latest drm-intel-nightly. |
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.