Created attachment 130406 [details] [review] Fix for kernel WARN What I'm using: - R9 290 - Kernel 4.10.4 - ASUS PB278Q monitor, connected with DisplayPort - OpenGL core profile version string: 4.5 (Core Profile) Mesa 13.1.0-devel (git-d9fef84) - radeon DDX 7.8.99 (Git) On the above setup, I have two problems: - Kernel warning that happens when I turn the monitor on from an off state - Display stays blank after being turned on or waking from sleep First is the kernel WARN. It looks like this: [102004.855043] ------------[ cut here ]------------ [102004.855046] WARNING: CPU: 7 PID: 14012 at ./include/drm/drm_crtc.h:1403 drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper] [102004.855046] Modules linked in: vhost_net vhost macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp bridge stp llc ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables binfmt_misc nls_iso8859_1 mxm_wmi intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd snd_usb_audio snd_usbmidi_lib input_leds joydev serio_raw snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_soc_rt5640 snd_hda_codec snd_soc_ssm4567 snd_soc_rl6231 snd_hda_core snd_soc_core snd_hwdep mei_me lpc_ich [102004.855058] mei snd_compress shpchp snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_timer snd_seq_device snd wmi elan_i2c soundcore dw_dmac video snd_soc_sst_acpi i2c_designware_platform snd_soc_sst_match i2c_designware_core 8250_dw mac_hid spi_pxa2xx_platform acpi_pad tpm_infineon kvm_intel kvm irqbypass sunrpc parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq dm_mirror dm_region_hash dm_log hid_generic usbhid amdkfd amd_iommu_v2 radeon(OE) i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm e1000e crc32c_intel drm psmouse ahci ptp libahci pps_core sdhci_acpi sdhci i2c_hid hid fjes [102004.855070] CPU: 7 PID: 14012 Comm: kworker/7:1 Tainted: G W OE 4.9.0 #13 [102004.855070] Hardware name: Gigabyte Technology Co., Ltd. Z97X-UD3H-BK/Z97X-UD3H-BK-CF, BIOS F6 06/17/2014 [102004.855078] Workqueue: events radeon_dp_work_func [radeon] [102004.855079] ffffa82d4c277d20 ffffffffaa432693 0000000000000000 0000000000000000 [102004.855080] ffffa82d4c277d60 ffffffffaa082bbb 0000057b401c8000 ffff8c7641aa1800 [102004.855081] ffff8c764008a000 ffff8c764008a000 0000000000000003 0000000000000000 [102004.855082] Call Trace: [102004.855083] [<ffffffffaa432693>] dump_stack+0x63/0x90 [102004.855083] [<ffffffffaa082bbb>] __warn+0xcb/0xf0 [102004.855084] [<ffffffffaa082ced>] warn_slowpath_null+0x1d/0x20 [102004.855087] [<ffffffffc059a453>] drm_helper_choose_crtc_dpms+0x93/0xa0 [drm_kms_helper] [102004.855089] [<ffffffffc059a4d7>] drm_helper_connector_dpms+0x77/0x100 [drm_kms_helper] [102004.855096] [<ffffffffc05d5bb0>] ? atombios_blank_crtc+0x150/0x150 [radeon] [102004.855103] [<ffffffffc05ef0c6>] radeon_connector_hotplug+0xf6/0x120 [radeon] [102004.855111] [<ffffffffc05fcd0f>] radeon_dp_work_func+0x3f/0x60 [radeon] [102004.855112] [<ffffffffaa09d90b>] process_one_work+0x16b/0x480 [102004.855113] [<ffffffffaa09dc6b>] worker_thread+0x4b/0x500 [102004.855114] [<ffffffffaa09dc20>] ? process_one_work+0x480/0x480 [102004.855115] [<ffffffffaa09dc20>] ? process_one_work+0x480/0x480 [102004.855116] [<ffffffffaa0a3ec9>] kthread+0xd9/0xf0 [102004.855117] [<ffffffffaa0a3df0>] ? kthread_park+0x60/0x60 [102004.855118] [<ffffffffaa8773b5>] ret_from_fork+0x25/0x30 [102004.855118] ---[ end trace cbb9abffe6127dc8 ]--- After some investigation I found that the attached patch will solve the warning. However, it does not solve my other problem, which is that sometimes, when turning the monitor on, the display will not wake; it will just display "No Signal". To make it wake up one has to turn the monitor off and on again a few times, unplug the cable, or (more recently; I'm not sure what changed), turn off the monitor, go to a TTY, and turn the monitor back on. I enabled debugging in /sys/module/drm/parameters/debug, and saw some messages like: dp_aux_ch flags not zero: 00000201 Which lead me to create another patch which I will attach in a reply. The patch does help the monitor consistently wake up as it should. Though the radeon_dp_link errors in dmesg still show up. Both of these issues have been touched on in one way or another in the past. The mutex issue in my first patch was discussed here: https://patchwork.kernel.org/patch/6430431/ And doing a web search for AUX_SW_RX_HPD_DISCON (from my second patch) yielded very little useful information except for an attachment to a similar bug from Alex: https://bugs.freedesktop.org/attachment.cgi?id=115885&action=edit I couldn't find any public documentation that describes what those error flags mean. But apparently removing AUX_SW_RX_HPD_DISCON from the set makes my monitor wake up properly.
Created attachment 130407 [details] [review] Fix for display not waking
Do you physically turn the monitor on/off with the button on the monitor or just let dpms do it's thing?
(In reply to Alex Deucher from comment #2) > Do you physically turn the monitor on/off with the button on the monitor or > just let dpms do it's thing? I'm turning it on and off with the button. I seem to recall that it would sometimes stay blank when the desktop environment would blank it (after the timeout), but I can't seem to reproduce it. Definitely happens with the button though.
It's possible that I just didn't leave it alone for long enough after it turned off (or after I turned it off with xset dpms force off). Maybe after a period of time with no signal, the monitor itself goes into its own sleep state that affects the DisplayPort connection in a way similar to turning it off completely. If it's important I can test it further.
Created attachment 130440 [details] dmesg
Created attachment 130441 [details] Xorg.log
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/drm/amd/issues/788.
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.