Summary: | [Haswell] blank Screen with intel ddx on first use right after using fbdev ddx. Breaking SuSE Install | ||
---|---|---|---|
Product: | DRI | Reporter: | Rodrigo Vivi <rodrigo.vivi> |
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: | major | ||
Priority: | medium | CC: | sndirsch |
Version: | XOrg git | ||
Hardware: | Other | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Created attachment 83980 [details]
fbdev xorg conf
Created attachment 83981 [details]
intel xorg conf
Created attachment 83982 [details]
normal intel ddx run: dmesg
Created attachment 83983 [details]
normal intel ddx run: xorg.0.log
Created attachment 83984 [details]
fbdev running: dmesg
Created attachment 83985 [details]
fbdev running: xorg log
Created attachment 83986 [details]
intel running after fbdev: blank screen! (dmesg)
Created attachment 83987 [details]
intel running after fbdev: blank screen! (xorg log)
It might save work for others to state that experts at SUSE looked at intel_reg_dumper output and it appears that the state of the PIPEACONF register might be relevant to the root cause. Created attachment 83988 [details]
dmesg regular boot with intelddx since I always forgot to increase log buf size
The WARN is significant as it is pointing out the DPMS performed by uxa following the modeset finds the output disabled: [ 131.230177] [drm:check_encoder_state], [ENCODER:10:DAC-10] [ 131.230183] [drm:check_encoder_state], [ENCODER:11:TMDS-11] [ 131.230187] ------------[ cut here ]------------ [ 131.230250] WARNING: CPU: 0 PID: 3268 at drivers/gpu/drm/i915/intel_display.c:8487 check_encoder_state+0x1f9/0x270 [i915]() [ 131.230254] encoder's computed active state doesn't match tracked active state (expected 1, found 0) [ 131.230256] Modules linked in: nfs(F) fscache(F) lockd(F) sunrpc(F) af_packet(F) xt_limit(F) snd_pcm_oss(F) snd_mixer_oss(F) snd_seq(F) snd_seq_device(F) binfmt_misc(F) ip6t_REJECT(F) nf_conntrack_ipv6(F) nf_defrag_ipv6(F) ip6table_raw(F) xt_CT(F) ipt_REJECT(F) xt_state(F) iptable_raw(F) iptable_filter(F) ip6table_mangle(F) nf_conntrack_netbios_ns(F) nf_conntrack_broadcast(F) nf_conntrack_ipv4(F) nf_conntrack(F) nf_defrag_ipv4(F) ip_tables(F) cpufreq_conservative(F) cpufreq_userspace(F) ip6table_filter(F) ip6_tables(F) cpufreq_powersave(F) x_tables(F) ipv6(F) fuse(F) nls_iso8859_1(F) nls_cp437(F) vfat(F) fat(F) loop(F) dm_mod(F) snd_hda_codec_realtek(F) snd_hda_intel(F) snd_hda_codec(F) snd_hwdep(F) snd_pcm(F) snd_timer(F) snd(F) hid_generic(F) hp_wmi(F) tpm_infineon(F) soundcore(F) ehci_pci(F) sparse_keymap(F) rfkill(F) ehci_hcd(F) acpi_cpufreq(F) e1000e(F) sr_mod(F) cdrom(F) tpm_tis(F) snd_page_alloc(F) iTCO_wdt(F) pcspkr(F) serio_raw(F) mperf(F) ptp(F) sg(F) iTCO_vendor_support(F) lpc_ich(F) i2c_i801(F) mfd_core(F) wmi(F) pps_core(F) rtc_cmos(F) tpm(F) tpm_bios(F) ext3(F) jbd(F) mbcache(F) i915(F) drm_kms_helper(F) drm(F) intel_agp(F) i2c_algo_bit(F) intel_gtt(F) i2c_core(F) video(F) usbhid(F) hid(F) sd_mod(F) crc_t10dif(F) xhci_hcd(F) usbcore(F) fan(F) usb_common(F) button(F) thermal(F) processor(F) thermal_sys(F) hwmon(F) scsi_dh_rdac(F) scsi_dh_hp_sw(F) scsi_dh_emc(F) scsi_dh_alua(F) scsi_dh(F) ahci(F) libahci(F) libata(F) scsi_mod(F) [ 131.230388] CPU: 0 PID: 3268 Comm: X Tainted: GF W 3.11.0-rc4-0.11-default #1 [ 131.230391] Hardware name: Hewlett-Packard HP Z230 SFF Workstation/1906, BIOS L51 v01.00 06/07/2013 [ 131.230395] 0000000000002127 ffff88011577bc18 ffffffff8149505e ffff88011577bc58 [ 131.230403] ffffffff8104a167 ffff88011280c000 ffff880114a0e000 0000000000000001 [ 131.230409] ffff88011280c3f0 ffff88011280c000 ffff88011280c408 ffff88011577bcb8 [ 131.230416] Call Trace: [ 131.230431] [<ffffffff8149505e>] dump_stack+0x6a/0x7c [ 131.230440] [<ffffffff8104a167>] warn_slowpath_common+0x87/0xb0 [ 131.230446] [<ffffffff8104a231>] warn_slowpath_fmt+0x41/0x50 [ 131.230488] [<ffffffffa022a469>] check_encoder_state+0x1f9/0x270 [i915] [ 131.230524] [<ffffffffa023216d>] intel_modeset_check_state+0x7d/0xa0 [i915] [ 131.230555] [<ffffffffa02321db>] intel_connector_dpms+0x4b/0x90 [i915] [ 131.230586] [<ffffffffa0198c57>] drm_mode_obj_set_property_ioctl+0x357/0x370 [drm] [ 131.230612] [<ffffffffa0198c9d>] drm_mode_connector_property_set_ioctl+0x2d/0x30 [drm] [ 131.230635] [<ffffffffa018b44a>] drm_ioctl+0x3aa/0x630 [drm] [ 131.230665] [<ffffffffa0198c70>] ? drm_mode_obj_set_property_ioctl+0x370/0x370 [drm] [ 131.230675] [<ffffffff8117c163>] do_vfs_ioctl+0x83/0x370 [ 131.230681] [<ffffffff8117c4e1>] SyS_ioctl+0x91/0xb0 [ 131.230690] [<ffffffff8149d529>] ? do_page_fault+0x9/0x10 [ 131.230697] [<ffffffff814a1ad2>] system_call_fastpath+0x16/0x1b [ 131.230702] ---[ end trace 78439480d92af715 ]--- [ 131.230706] [drm:check_encoder_state], [ENCODER:16:TMDS-16] [ 131.230711] [drm:check_encoder_state], [ENCODER:19:TMDS-19] [ 131.230715] [drm:check_crtc_state], [CRTC:3] [ 131.230721] [drm:check_crtc_state], [CRTC:5] [ 131.230725] [drm:check_crtc_state], [CRTC:7] Created attachment 84029 [details]
dmesgs with ickle's patch
The situation improved a lot.
No warn.
No oops.
Screen back after alternating to fbcon.
But still blank screen when starting intel ddx after fbcon
An igt testcase for this would be pretty awesome ... Rodrigo, can you add a ton of printk through modesetting see why we decide to only do a fbset versus modeset? The most strange thing I notice was when if fails on intel_connector_dpms mode is != connector->dpms so it doesn't return on that point like on every time that that works. When it works: [ 22.003560] [drm:intel_crtc_set_config], MODE_CHANGED intel_crtc_set_config 8031 [ 22.003574] [drm:intel_crt_dpms], VIVI: intel_crt_dpms 148 [ 22.003578] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 [ 22.003581] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 [ 22.003584] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 [ 22.003586] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 [ 22.003589] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 When if fails: [ 121.876256] [drm:intel_crtc_set_config], MODE_CHANGED intel_crtc_set_config 8031 [ 121.876272] [drm:intel_crt_dpms], VIVI: intel_crt_dpms 148 [ 121.876276] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3846 [ 121.876277] [drm:intel_connector_dpms], VIVI: intel_connector_dpms 3859 [ 121.876278] [drm:intel_modeset_check_state], VIVI: intel_modeset_check_state 7533 [ 121.876279] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876281] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876282] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876283] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876285] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876286] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 [ 121.876287] [drm:intel_connector_check_state], VIVI: intel_connector_check_state 3804 Rodrigo, can you please add a few debug printks to intel_crt_dpms to dump the current and the requested dpms mode and then grab a full dmesg when this fails? It wouldn't surprise me at all if we have yet another bug in our dpms tracking ... connector-dpms and mode at intel_crt_dpms are both 3 always... with ddx intel working, with ddx fbdev and with intel failling but connector-> dpms is changed to OFF here because !crtc Rodrigo, can you please attach a new debug dmesg with everything from boot to the intel ddx with the broken config? I.e. boot -> fbdev ddx -> intel ddx with black screen. I couldn't find it in all the above stuff ;-) Created attachment 85766 [details]
Full dmesg
This is the latest full dmesg with SuSE kernel and some printks I was using for debug.
dpms off/on cycle helps. With blank screen on intel ddx after fbdev I used xset dpms force off / than moved the mouse and got screen back. Created attachment 86067 [details]
Full logs with SNA and ddx debug=full
Chris fixed sna building on SLED and I could get it running here but the issue remains. Attached full new log with SNA and debug=full, but I couldn't notice anything new.
Also he confirmed that with same SLED this bug doesn't occur on IVB.
CRTC is off for some weird reason on this HSW. Any ideas/theories?
commit 63a070a31a3963f836539ee7629d64fe3c9f88c8 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Sep 18 17:03:40 2013 +0100 sna: Do not change DPMS mode on unconnected outputs The operation is in theory redundant, and in the case of Haswell where we have multiple outputs aliasing to the same encoder, actually harmful. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> For UXA, I think diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index 7dc0f68..3c2f964 100644 --- a/src/uxa/intel_display.c +++ b/src/uxa/intel_display.c @@ -1123,10 +1123,13 @@ intel_output_dpms(xf86OutputPtr output, int dpms) intel_output_dpms_backlight(output, intel_output->dpms_mode, dpms); - drmModeConnectorSetProperty(mode->fd, - intel_output->output_id, - props->prop_id, - dpms); + + if (output->crtc) + drmModeConnectorSetProperty(mode->fd, + intel_output->output_id, + props->prop_id, + dpms); + if (dpms != DPMSModeOff) intel_output_dpms_backlight(output, intel_output->dpms_mode, Hi Chris, Thank you very much for fixing this. I also confirmed that this patch in comment fixes the issue on UXA and already prepared one for Suse's ddx. Thanks again, Rodrigo. Chris/Rodrigo. This is great news! One question. Knowing that SNA has become the driver default, could you still push the UXA fix to git as well? Thanks a lot! Hi Stefan, Since Chris is the real author of the uxa patch as well I think makes more sense for him to push his patch, but I'm going to prepare one right now and submit anyway. For the xf86-video-intel you use on SLED I had attached the patch on your bugzilla: 817998 commit 4497212307dee5e35bc6836201738a2fdb559020 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Sep 18 17:03:40 2013 +0100 uxa: Do not change DPMS mode on unconnected outputs The operation is in theory redundant, and in the case of Haswell where we have multiple outputs aliasing to the same encoder, actually harmful. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Stefan Dirsch <sndirsch@suse.de> Thanks, Chris! i-g-t commit 0b19cb5dc2afe55084b946b053c527b9f44a011f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 3 18:30:56 2013 +0200 tests/kms_flip: Check the dpms confusion Some kernels inadvertedly forwarded dpms changes to crtcs connected to shared encoders even though that specific output wasn't enabled. Hilarity ensued. Note that we only have shared encoders on hsw (DP+HDMI) and with sdvo cards (multi-function encoders). v2: Do a full OFF->ON->OFF transition to make sure something actually happens. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> kernel commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 29 19:15:07 2013 +0100 drm/i915: Only apply DPMS to the encoder if enabled The current test for an attached enabled encoder fails if we have multiple connectors aliased to the same encoder - both connectors believe they own the enabled encoder and so we attempt to both enable and disable DPMS on the encoder, leading to hilarity and an OOPs: [ 354.803064] WARNING: CPU: 0 PID: 482 at /usr/src/linux/dist/3.11.2/drivers/gpu/drm/i915/intel_display.c:3869 intel_modeset_check_state+0x764/0x770 [i915]() [ 354.803064] wrong connector dpms state [ 354.803084] Modules linked in: nfsd auth_rpcgss oid_registry exportfs nfs lockd sunrpc xt_nat iptable_nat nf_nat_ipv4 nf_nat xt_limit xt_LOG xt_tcpudp nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT ipv6 xt_recent xt_conntrack nf_conntrack iptable_filter ip_tables x_tables snd_hda_codec_realtek snd_hda_codec_hdmi x86_pkg_temp_thermal snd_hda_intel coretemp kvm_intel snd_hda_codec i915 kvm snd_hwdep snd_pcm_oss snd_mixer_oss crc32_pclmul snd_pcm crc32c_intel e1000e intel_agp igb ghash_clmulni_intel intel_gtt aesni_intel cfbfillrect aes_x86_64 cfbimgblt lrw cfbcopyarea drm_kms_helper ptp video thermal processor gf128mul snd_page_alloc drm snd_timer glue_helper 8250_pci snd pps_core ablk_helper agpgart cryptd sg soundcore fan i2c_algo_bit sr_mod thermal_sys 8250 i2c_i801 serial_core hwmon cdrom i2c_core evdev button [ 354.803086] CPU: 0 PID: 482 Comm: kworker/0:1 Not tainted 3.11.2 #1 [ 354.803087] Hardware name: Supermicro X10SAE/X10SAE, BIOS 1.00 05/03/2013 [ 354.803091] Workqueue: events console_callback [ 354.803092] 0000000000000009 ffff88023611db48 ffffffff814048ac ffff88023611db90 [ 354.803093] ffff88023611db80 ffffffff8103d4e3 ffff880230d82800 ffff880230f9b800 [ 354.803094] ffff880230f99000 ffff880230f99448 ffff8802351c0e00 ffff88023611dbe0 [ 354.803094] Call Trace: [ 354.803098] [<ffffffff814048ac>] dump_stack+0x54/0x8d [ 354.803101] [<ffffffff8103d4e3>] warn_slowpath_common+0x73/0x90 [ 354.803103] [<ffffffff8103d547>] warn_slowpath_fmt+0x47/0x50 [ 354.803109] [<ffffffffa089f1be>] ? intel_ddi_connector_get_hw_state+0x5e/0x110 [i915] [ 354.803114] [<ffffffffa0896974>] intel_modeset_check_state+0x764/0x770 [i915] [ 354.803117] [<ffffffffa08969bb>] intel_connector_dpms+0x3b/0x60 [i915] [ 354.803120] [<ffffffffa037e1d0>] drm_fb_helper_dpms.isra.11+0x120/0x160 [drm_kms_helper] [ 354.803122] [<ffffffffa037e24e>] drm_fb_helper_blank+0x3e/0x80 [drm_kms_helper] [ 354.803123] [<ffffffff812116c2>] fb_blank+0x52/0xc0 [ 354.803125] [<ffffffff8121e04b>] fbcon_blank+0x21b/0x2d0 [ 354.803127] [<ffffffff81062243>] ? update_rq_clock.part.74+0x13/0x30 [ 354.803129] [<ffffffff81047486>] ? lock_timer_base.isra.30+0x26/0x50 [ 354.803130] [<ffffffff810472b2>] ? internal_add_timer+0x12/0x40 [ 354.803131] [<ffffffff81047f48>] ? mod_timer+0xf8/0x1c0 [ 354.803133] [<ffffffff81266d61>] do_unblank_screen+0xa1/0x1c0 [ 354.803134] [<ffffffff81268087>] poke_blanked_console+0xc7/0xd0 [ 354.803136] [<ffffffff812681cf>] console_callback+0x13f/0x160 [ 354.803137] [<ffffffff81053258>] process_one_work+0x148/0x3d0 [ 354.803138] [<ffffffff81053f19>] worker_thread+0x119/0x3a0 [ 354.803140] [<ffffffff81053e00>] ? manage_workers.isra.30+0x2a0/0x2a0 [ 354.803141] [<ffffffff8105994b>] kthread+0xbb/0xc0 [ 354.803142] [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120 [ 354.803144] [<ffffffff8140b32c>] ret_from_fork+0x7c/0xb0 [ 354.803145] [<ffffffff81059890>] ? kthread_create_on_node+0x120/0x120 This regression goes back to the big modeset rework and the conversion to the new dpms helpers which started with: commit 5ab432ef4997ce32c9406721b37ef6e97e57dae1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jun 30 08:59:56 2012 +0200 drm/i915/hdmi: convert to encoder->disable/enable Fixes: igt/kms_flip/dpms-off-confusion Reported-and-tested-by: Wakko Warner <wakko@animx.eu.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Link: http://lkml.kernel.org/r/20130928185023.GA21672@animx.eu.org Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [danvet: Add regression citation, mention the igt testcase this fixes and slap a cc: stable on the patch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> commit 72e909953c1865f86fbd6325ff807d7c7357af5f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 13 09:46:13 2014 +0000 Revert "uxa: Do not change DPMS mode on unconnected outputs" This reverts commit 4497212307dee5e35bc6836201738a2fdb559020. Unfortunately, this simple fix does not work for UXA as DPMS is used by the xserver to turn off CRTCs and outputs. Since UXA does not implement CRTC DPMS, this commit causes us to fail to turn off outputs. The kernel has been fixed up in the meantime and that commit has been recommended to be backported to all stable kernels: commit c9976dcf55c8aaa7037427b239f15e5acfc01a3a Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sun Sep 29 19:15:07 2013 +0100 drm/i915: Only apply DPMS to the encoder if enabled so it should be safe for UXA to rely on its old behaviour. Bugzilla: https://code.google.com/p/chromium/issues/detail?id=341135 References: https://bugs.freedesktop.org/show_bug.cgi?id=68030 Suggested-by: Dominik Behr <dbehr@google.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> |
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.
Created attachment 83979 [details] script to reproduce bug Bug description: Blank screen on the first intel DDX run right after running FBDEV DDX. Not even possible to alternate to fbcon. Have to reboot or restart X to get screen back. This behaviour breaks SuSE installation. System environment: -- chipset: Haswell -- system architecture: x86_64 -- xf86-video-intel: xorg-x11-driver-video-7.4.0.1-0.81.27 -- xserver: 1.6.5 -- libdrm: 2.4.41-0.8.46 -- kernel: nightly 7e4f3f0cb9d232721bfdaa00c27c5550f70428a8 3.11.0-rc4-0.11 -- Linux distribution: SLED -- Display connector: DP Reproducing steps: - Run Intel ddx and stop it. - Run FBDEV ddx and stop it. - Run Intel ddx again. - Blank Screen (only on first run after fbdev) - Restart X or machine and screen is back.