Summary: | [SNB] vblank wait timeout, giving kernel panic, while switching TTY | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Marcel Dijkstra <marcel.foss> | ||||||||
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: | normal | ||||||||||
Priority: | high | CC: | intel-gfx-bugs, mariusz.g.mazur, orzel, samantham, ville.syrjala | ||||||||
Version: | unspecified | ||||||||||
Hardware: | x86-64 (AMD64) | ||||||||||
OS: | Linux (All) | ||||||||||
Whiteboard: | ReadyForDev | ||||||||||
i915 platform: | SNB | i915 features: | display/atomic | ||||||||
Attachments: |
|
Description
Marcel Dijkstra
2016-08-20 01:18:35 UTC
Today came update to linux 4.7.1-1 on Arch Linux and after many cycles between TTY2 and TTY7 no kernel panic happened thus-far. My window manager is compiz 0.9.12.2-5 with emerald 0.9.5-19 window decorator. Oddly, switching to TTY7 does sometimes cause repeated flickering of GTK-elements with transparancies e.g. transparent terminal and icons in notification area. Another kernel-oops switching TTY2 to TTY7, even without fancy terminal-font and background-coloring. It hasn't gone away; I could get back to TTY2 this time. Recently, Arch Linux driver-package suggested DRI3 and SNA-acceleration as default, which I have moved to. Before I was on DRI2 and UXA-acceleration. This could have brought on the problem. Going back to DRI2, UXA for time being. ---=[ /etc/X11/xorg.conf.d ]=--- Section "Device" Identifier "Intel Graphics" Driver "intel" #Option "DRI" "2" # DRI3 is now default Option "AccelMethod" "sna" # default #Option "AccelMethod" "uxa" # fallback EndSection ---=[ /var/log/Xorg.0.log ]=--- [ 25.863] (II) LoadModule: "intel" [ 25.864] (II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so [ 26.102] (II) Module intel: vendor="X.Org Foundation" [ 26.102] compiled for 1.18.4, module version = 2.99.917 [ 26.102] Module class: X.Org Video Driver [ 26.102] ABI class: X.Org Video Driver, version 20.0 [ 26.102] (II) intel: Driver for Intel(R) Integrated Graphics Chipsets: i810, i810-dc100, i810e, i815, i830M, 845G, 854, 852GM/855GM, 865G, 915G, E7221 (i915), 915GM, 945G, 945GM, 945GME, Pineview GM, Pineview G, 965G, G35, 965Q, 946GZ, 965GM, 965GME/GLE, G33, Q35, Q33, GM45, 4 Series, G45/G43, Q45/Q43, G41, B43 [ 26.102] (II) intel: Driver for Intel(R) HD Graphics: 2000-6000 [ 26.102] (II) intel: Driver for Intel(R) Iris(TM) Graphics: 5100, 6100 [ 26.102] (II) intel: Driver for Intel(R) Iris(TM) Pro Graphics: 5200, 6200, P6300 [ 26.228] (II) intel(0): Using Kernel Mode Setting driver: i915, version 1.6.0 20160425 [ 26.228] (II) intel(0): SNA compiled from 2.99.917-691-ga77397a [ 26.261] (--) intel(0): Integrated Graphics Chipset: Intel(R) HD Graphics 3000 [ 26.261] (--) intel(0): CPU: x86-64, sse2, sse3, ssse3, sse4.1, sse4.2, avx; using a maximum of 2 threads [ 26.276] (==) Depth 24 pixmap format is 32 bpp [ 26.323] (II) intel(0): SNA initialized with Sandybridge (gen6, gt2) backend [ 26.323] (==) intel(0): Backing store enabled [ 26.323] (==) intel(0): Silken mouse enabled [ 26.325] (II) intel(0): HW Cursor enabled [ 26.325] (II) intel(0): RandR 1.2 enabled, ignore the following RandR disabled message. [ 26.349] (==) intel(0): DPMS enabled [ 26.349] (==) intel(0): Display hotplug detection enabled [ 26.349] (II) intel(0): [DRI2] Setup complete [ 26.349] (II) intel(0): [DRI2] DRI driver: i965 [ 26.349] (II) intel(0): [DRI2] VDPAU driver: va_gl [ 26.349] (II) intel(0): direct rendering: DRI2 DRI3 enabled [ 26.349] (II) intel(0): hardware support for Present enabled [ 26.349] (--) RandR disabled [ 26.626] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [ 26.626] (II) AIGLX: enabled GLX_ARB_create_context [ 26.626] (II) AIGLX: enabled GLX_ARB_create_context_profile [ 26.626] (II) AIGLX: enabled GLX_EXT_create_context_es{,2}_profile [ 26.626] (II) AIGLX: enabled GLX_INTEL_swap_event [ 26.626] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [ 26.626] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB [ 26.626] (II) AIGLX: enabled GLX_ARB_fbconfig_float [ 26.626] (II) AIGLX: enabled GLX_EXT_fbconfig_packed_float [ 26.626] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [ 26.626] (II) AIGLX: enabled GLX_ARB_create_context_robustness [ 26.627] (II) AIGLX: Loaded and initialized i965 [ 26.627] (II) GLX: Initialized DRI2 GL provider for screen 0 [ 26.654] (II) intel(0): switch to mode 1600x900@60.0 on LVDS1 using pipe 0, position (0, 0), rotation normal, reflection none ---=[ kernel oops (same as before) ]=--- Aug 24 18:21:31 thinkpad kernel: ------------[ cut here ]------------ Aug 24 18:21:31 thinkpad kernel: WARNING: CPU: 0 PID: 521 at drivers/gpu/drm/drm_irq.c:1318 drm_wait_one_vblank+0x1b0/0x1c0 [drm] Aug 24 18:21:31 thinkpad kernel: vblank wait timed out on crtc 0 ... Aug 24 18:21:31 thinkpad kernel: ---[ end trace 2c15743601acdbb9 ]--- Aug 24 18:21:31 thinkpad kernel: ------------[ cut here ]------------ Aug 24 18:21:31 thinkpad kernel: WARNING: CPU: 0 PID: 521 at drivers/gpu/drm/i915/intel_display.c:13562 intel_atomic_commit+0x13af/0x1460 [i915] Aug 24 18:21:31 thinkpad kernel: pipe A vblank wait timed out ... Aug 24 18:21:31 thinkpad kernel: ---[ end trace 2c15743601acdbba ]- Hi, can you try with the last drm-tip kernel from https://cgit.freedesktop.org/drm-tip. Boot with drm.debug=0x1e and then retest, reproduce the problem, and attach the dmesg. Created attachment 129444 [details]
drm-tip kernel oops
---=[ description ]=---
The kernel oops occurs after switching several times between TTY2 and X11(DRI3, SNA) on my Lenovo ThinkPad (attachment).
Switching back to X11 can take several seconds and a few more seconds before X11 becomes responsive.
After kernel oops the mouse pointer can dissapear repeatedly, taking again few seconds for X11 to become responsive and for mouse pointer to reappear.
Again a "flip_done time out" is seen in "dmesg" every time it happens (attachment).
No issues occur trying to switch several times between TTY2 and X11(DRI3, SNA) on an Intel Core-i3 NUC with same Arch Linux and "4.10.0-rc7-drmtip" kernel.
---=[ system info ]=---
distro: Arch Linux, arch: x86_64
linux: 4.10.0-rc7-drmtip (git#2699547: integration manifest)
xf86-video-intel: 1:2.99.917+753+g9fe04af4-1
mesa: 13.0.4-1
xorg-server: 1.19.1-1
kernel-param: i915.modeset=1 drm.debug=0x1e
machine-1: Lenovo ThinkPad T520, model 42435JG
cpu: CPU0: Intel(R) Core(TM) i7-2640M CPU @ 2.80GHz (family: 0x6, model: 0x2a, stepping: 0x7)
lspci: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
machine-2: Intel NUC5i3RYB
CPU0: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz (family: 0x6, model: 0x3d, stepping: 0x4)
lspci: 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09)
information provided changing the status of the bug to REOPEN Reporter, are you able to test if latest drm-tip helps here? On git#30d33 "... integration manifest"; there occurs a dependency error trying to `make modules_install` kernel-modules with default Arch Linux `.config`, reading: "depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper". Tried to unset "CONFIG_DRM_KMS_HELPER, CONFIG_DRM_KMS_FB_HELPER and CONFIG_DRM_FBDEV_EMULATION" in `.config` through options in `make menuconfig`. How to proceed? KMS helper might be required for me to test TTY-switching. Succesfully installed drmp-tip kernel git#5b3638: "2017y-06m-08d-20h-34m-37s UTC integration manifest". The kernel crashes switching to TTY2 with X11 on DRI3, SNA on my Thinkpad, after switching about 5 cycles between TTY2 and TTY7. No kernel panic is recorded in system log. Can only give DRM debug information right before crash: Jun 09 19:28:29 tinkpad kernel: [drm:drm_atomic_check_only [drm]] checking ffff8801fad12800 Jun 09 19:28:29 tinkpad kernel: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:40:LVDS-1] Jun 09 19:28:29 tinkpad kernel: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:40:LVDS-1] keeps [ENCODER:41:LVDS], now on [CRTC:32:pipe A] Jun 09 19:28:29 tinkpad kernel: [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:32:pipe A] has [PLANE:26:primary A] with fb 67 Jun 09 19:28:29 tinkpad kernel: [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:26:primary A] visible 1 -> 1, off 0, on 0, ms 0 Jun 09 19:28:29 tinkpad kernel: [drm:drm_atomic_commit [drm]] committing ffff8801fad12800 Jun 09 19:28:29 tinkpad kernel: [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state ffff8801fad12800 Jun 09 19:28:29 tinkpad kernel: [drm:__drm_atomic_state_free [drm]] Freeing atomic state ffff8801fad12800 Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_add_affected_connectors [drm]] Adding all current connectors for [CRTC:39:pipe B] to ffff88020f302800 Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_check_only [drm]] checking ffff88020f302800 Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:40:LVDS-1] Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:40:LVDS-1] keeps [ENCODER:41:LVDS], now on [CRTC:32:pipe A] Jun 09 19:38:08 tinkpad kernel: [drm:intel_plane_atomic_calc_changes [i915]] [CRTC:32:pipe A] has [PLANE:26:primary A] with fb 67 Jun 09 19:38:08 tinkpad kernel: [drm:intel_plane_atomic_calc_changes [i915]] [PLANE:26:primary A] visible 1 -> 1, off 0, on 0, ms 0 Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_commit [drm]] committing ffff88020f302800 Jun 09 19:38:08 tinkpad kernel: [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state ffff88020f302800 Jun 09 19:38:08 tinkpad kernel: [drm:__drm_atomic_state_free [drm]] Freeing atomic state ffff88020f302800 Hello Marcel, A lot of changes have been made on latest kernel, is this still reproducible with latest drm-tip? If so, could you attach dmesg as requested on comment #3 if possible? Thanks. Created attachment 133125 [details]
4.13.0-rc2 drmtip
Tried 4.13.0-rc2 drmtip (git#30aa81) on my T520 thinkpad, with X11 on SNA, DRI3. Display hangs on TTY2. Again two 'flip_done timeout' occur. Some hardware specific quirk or race-condition?
*** Bug 97241 has been marked as a duplicate of this bug. *** My laptop has always had this problem since i've bought it (sept 2016). Dmesg is flooded with things like this (see at the end). I'm using the intel driver, as the modsetting driver in xorg can't even detect my favourite resolution (1600x900) and is unusably slow. I use SNA/DRI3 and very recent software (gentoo). Currently seeing the problem with kernel 4.14.2, xf86-video-intel-2.99.917_p20171018, xorg-server-1.19.5 A kind of 'workaround' is to add 'irqpoll' to the kernel command line. In which ase i dont see those messages anymore, but instead my dmesg is flooded with hpet1: lost 163 rtc interrupts Nov 28 14:50:30 chaos kernel: pipe A vblank wait timed out Nov 28 14:50:30 chaos kernel: ------------[ cut here ]------------ Nov 28 14:50:30 chaos kernel: WARNING: CPU: 2 PID: 12508 at drivers/gpu/drm/i915/intel_display.c:12176 intel_atomic_commit_tail+0xeef/0xf00 Nov 28 14:50:30 chaos kernel: Modules linked in: Nov 28 14:50:30 chaos kernel: CPU: 2 PID: 12508 Comm: kworker/u8:2 Tainted: G W 4.14.2 #21 Nov 28 14:50:30 chaos kernel: Hardware name: Notebook W330AU/W330AU, BIOS 5.011 09/22/2015 Nov 28 14:50:30 chaos kernel: Workqueue: events_unbound intel_atomic_commit_work Nov 28 14:50:30 chaos kernel: task: ffff880227d08000 task.stack: ffffc90000b64000 Nov 28 14:50:30 chaos kernel: RIP: 0010:intel_atomic_commit_tail+0xeef/0xf00 Nov 28 14:50:30 chaos kernel: RSP: 0018:ffffc90000b67dc8 EFLAGS: 00010292 Nov 28 14:50:30 chaos kernel: RAX: 000000000000001c RBX: 0000000000000000 RCX: 0000000000000000 Nov 28 14:50:30 chaos kernel: RDX: ffff880256d13740 RSI: ffff880256d0ca58 RDI: ffff880256d0ca58 Nov 28 14:50:30 chaos kernel: RBP: ffffc90000b67e70 R08: 000000000000ae2b R09: 0000000000000001 Nov 28 14:50:30 chaos kernel: R10: ffffc90000b67dc8 R11: 0000000000000001 R12: 00000000000111c6 Nov 28 14:50:30 chaos kernel: R13: ffff88024ce00000 R14: ffff88024ce09000 R15: 0000000000000001 Nov 28 14:50:30 chaos kernel: FS: 0000000000000000(0000) GS:ffff880256d00000(0000) knlGS:0000000000000000 Nov 28 14:50:30 chaos kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 28 14:50:30 chaos kernel: CR2: 00007f7741d77140 CR3: 0000000002009003 CR4: 00000000003606e0 Nov 28 14:50:30 chaos kernel: Call Trace: Nov 28 14:50:30 chaos kernel: ? wait_woken+0x80/0x80 Nov 28 14:50:30 chaos kernel: intel_atomic_commit_work+0xd/0x10 Nov 28 14:50:30 chaos kernel: process_one_work+0x1d9/0x350 Nov 28 14:50:30 chaos kernel: worker_thread+0x2d/0x3f0 Nov 28 14:50:30 chaos kernel: kthread+0x11b/0x140 Nov 28 14:50:30 chaos kernel: ? wq_sysfs_prep_attrs+0x50/0x50 Nov 28 14:50:30 chaos kernel: ? kthread_create_on_node+0x40/0x40 Nov 28 14:50:30 chaos kernel: ret_from_fork+0x22/0x30 Nov 28 14:50:30 chaos kernel: Code: 75 b0 4c 89 45 80 48 83 c7 08 e8 5d 51 c4 ff 4c 8b 45 80 4d 85 c0 0f 85 d9 fa ff ff 8d 73 41 48 c7 c7 20 72 e3 81 e8 9d 67 c5 ff <0f> ff e9 c3 fa ff ff 66 2e 0f 1f 84 00 00 00 00 00 55 48 89 e5 Nov 28 14:50:30 chaos kernel: ---[ end trace fbb2f696c8a355a1 ]--- 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. Created attachment 138477 [details]
linux-4.16.0-rc7-drmtip
No kernel panic or oops on current drm-tip, with X11 on DRI3/SNA. Switching TTY still gives "flip_done time out" errors; system becomes slow and unresponsive, but does power down eventually.
Based on this closing, please re-open if still occurs. If I understood wrongly, please comment. There are still "flip_done time out" errors. Currently it does not result in kernel panic or kernel oops. However an unresponsive kernel has happened before with this bug. This bug is not resolved; it is hardly possible to power down after "flip_done time out" and I cannot reliably switch TTY. Ville, any help here? Marcel, do you still have the issue? Please try to reproduce the issue using drm-tip (https://cgit.freedesktop.org/drm-tip) and kernel parameters drm.debug=0x1e log_buf_len=4M, and if the problem persists attach the full dmesg from boot. No feedback about the issue recently, closing as resolved works for me. Please create a new bug if the issue is different from the original issue (Kernel panic). If kernel panic still occurs with latest drm-tip https://cgit.freedesktop.org/drm-tip, reopen the issue and send dmesg from boot with kernel parameters drm.debug=0x1e log_buf_len=4M. |
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.