Kernel Bug Tracker – Bug 16249
HDMI doesn't work on Radeon RS690M
Last modified: 2012-07-20 13:12:04 UTC
If I connect my laptop with Radeon RS690M IGP to Philips LCD HDTV over HDMI, TV is properly detected by xrandr (with right modes). But after activating it by xrandr (setting it to clone or any other mode), TV screen stays black and says "unknown video format". I have tried all supported resolutions/refresh rates without success.
I have also desktop with Radeon RS780G IGP which is connected to this HDTV over HDMI and everything works without problems, so this is clearly problem with RS690M.
This has been tested on kernel 2.6.35-rc3 with latest libdrm, mesa and xf86-video-ati from Git repositories (running under KMS). But I have tried it also about year ago on some stable kernel (running under UMS, not KMS) with same results.
There is one relevant error in dmesg after connecting HDMI:
radeon 0000:01:05.0: Could not find HDMI block for 0x19 encoder
Please attach your dmesg (grep | drm) and xrandr output.
Error message you cited is important for HDMI audio, nothing about standard video output.
Created attachment 26852 [details]
First patch attempt by glisse (this doesn't work)
I have already discussed this issue on #radeon IRC channel with glisse and he gave me this patch, but unfortunately it doesn't work.
After applying this patch and recompiling kernel, everything seems good (HDTV is again properly detected by xrandr) until I try to activate HDMI output with xrandr. After it main laptop LVDS screen get garbled and graphics system completely freezes (but I still can SSH into system).
This is relevant error from dmesg:
------------[ cut here ]------------
kernel BUG at kernel/timer.c:662!
invalid opcode: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A03:00/device:14/PNP0C09:00/PNP0C0A:00/power_supply/BAT1/charge_full
Modules linked in: rfcomm sco bridge stp llc bnep l2cap crc16 snd_hda_codec_atihdmi arc4 fuse ecb tun cpufreq_powersave cpufreq_ondemand snd_seq_dummy powernow_k8 freq_table snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_hda_codec_realtek video mperf output ac battery snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd ath5k soundcore snd_page_alloc sdhci_pci sdhci mmc_core processor thermal mac80211 button btusb ath radeon bluetooth joydev cfg80211 uvcvideo videodev v4l1_compat rfkill led_class ttm k8temp drm_kms_helper ati_agp i2c_piix4 psmouse evdev r8169 mii pcspkr sg shpchp pci_hotplug serio_raw drm agpgart i2c_algo_bit i2c_core rtc_cmos rtc_core rtc_lib jfs ohci_hcd ehci_hcd usbcore sd_mod sr_mod ahci libahci cdrom ata_generic pata_atiixp pata_acpi libata scsi_mod
Pid: 4113, comm: X Not tainted 2.6.35-rc3-rc #1 MS-1222/PR210
EIP: 0060:[<c1051e58>] EFLAGS: 00213246 CPU: 1
EIP is at mod_timer+0x278/0x2a0
EAX: 00000000 EBX: f695b788 ECX: 00000000 EDX: 00000000
ESI: 0001aaa8 EDI: 0001aaa8 EBP: f53f1b68 ESP: f53f1b4c
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process X (pid: 4113, ti=f53f0000 task=f66fd590 task.ti=f53f0000)
0000018f f53f1bb0 00000000 00000000 f6012200 f695a000 00007400 f53f1b8c
<0> f8e8b77c 00000001 f8eb6a2e f8ea5af0 f8eb6a10 00000000 f695a000 f6012200
<0> f53f1bc4 f8e8ca5f f8e2eb79 f53f1bb0 f695a000 f695a000 f7353700 f53f1bc4
[<f8e8b77c>] ? r600_audio_enable_polling+0x6c/0x80 [radeon]
[<f8e8ca5f>] ? r600_hdmi_enable+0x1cf/0x490 [radeon]
[<f8e2eb79>] ? atom_execute_table+0x49/0x60 [radeon]
[<f8e3c8d7>] ? radeon_atom_encoder_mode_set+0x227/0x2e0 [radeon]
[<f8b42d58>] ? drm_crtc_helper_set_mode+0x3c8/0x3f0 [drm_kms_helper]
[<f8b435f8>] ? drm_crtc_helper_set_config+0x758/0x7e0 [drm_kms_helper]
[<c12e0eda>] ? __mutex_lock_slowpath+0x1ea/0x2b0
[<f89a1010>] ? drm_mode_setcrtc+0x260/0x330 [drm]
[<c118a010>] ? __copy_from_user_ll+0x40/0xf0
[<f89a1cae>] ? drm_mode_gamma_set_ioctl+0x3e/0xf0 [drm]
[<f89952fe>] ? drm_ioctl+0x1ae/0x410 [drm]
[<f89a0db0>] ? drm_mode_setcrtc+0x0/0x330 [drm]
[<c115d6df>] ? security_file_permission+0xf/0x20
[<c10f5d1d>] ? rw_verify_area+0x5d/0xd0
[<c1103b74>] ? vfs_ioctl+0x34/0xa0
[<f8995150>] ? drm_ioctl+0x0/0x410 [drm]
[<c1104286>] ? do_vfs_ioctl+0x66/0x560
[<c10498b1>] ? __do_softirq+0xe1/0x1e0
[<c10f68cf>] ? vfs_writev+0x4f/0x60
[<c11047df>] ? sys_ioctl+0x5f/0x80
[<c100379f>] ? sysenter_do_call+0x12/0x28
Code: 12 8b 0e 8b 46 04 83 c6 08 89 da ff d1 8b 0e 85 c9 75 f0 89 e0 25 00 e0 ff ff 83 68 14 01 f6 40 08 08 75 18 8b 03 e9 03 fe ff ff <0f> 0b 8b 55 04 89 d8 e8 ac fa ff ff e9 be fd ff ff e8 c2 de 28
EIP: [<c1051e58>] mod_timer+0x278/0x2a0 SS:ESP 0068:f53f1b4c
---[ end trace 376f66ebcc7033eb ]---
Created attachment 26853 [details]
dmesg | egrep "drm|radeon" output on incriminated laptop
Created attachment 26855 [details]
dmesg | egrep "drm|radeon" output on incriminated laptop (right one)
Previous attachment was wrong file, sorry for my mistake...
Created attachment 26856 [details]
xrandr --verbose output on RS690M based laptop
(output after connecting HDMI cable, but not activating it)
Created attachment 26857 [details]
xrandr --verbose output on RS780G based desktop (for comparison)
(output from desktop connected to same Philips LCD HDTV over HDMI - everything works without problems in this case)
(In reply to comment #2)
> Created an attachment (id=26852) [details]
> First patch attempt by glisse (this doesn't work)
> I have already discussed this issue on #radeon IRC channel with glisse and he
> gave me this patch, but unfortunately it doesn't work.
> After applying this patch and recompiling kernel, everything seems good (HDTV
> is again properly detected by xrandr) until I try to activate HDMI output with
> xrandr. After it main laptop LVDS screen get garbled and graphics system
> completely freezes (but I still can SSH into system).
So do you mean it actually improved anything about output in xrandr? I don't really see the way how it could be achieved.
Crash you saw in dmesg is caused because of using times that was not setup. It should be addressed anyway.
There are two issues here:
1. hdmi video not working
Might be fixed by:
2. hdmi audio not working
May be addressed by:
Alex Deucher: Are all those patches already in drm-radeon-testing? I have tried latest drm-radeon-testing (2c4fcfba8453c680830f8363208f0eb7a4272a10), but HDMI still doesn't work. In fact it is worse than before - after activating HDMI output by xrandr (setting it to clone mode), X server and all graphics locks up (main LVDS screen turns black and I can't do anything, even KMS console is frozen and I can't switch to it - I have tried SysRq+R and "chvt 1" over SSH without success). TV connected through HDMI still says "unknown video format". It is similar behavior as with first patch by glisse.
Created attachment 26892 [details]
dmesg | egrep "drm|radeon" output after trying drm-radeon-testing
(In reply to comment #9)
> Alex Deucher: Are all those patches already in drm-radeon-testing? I have tried
> latest drm-radeon-testing (2c4fcfba8453c680830f8363208f0eb7a4272a10), but HDMI
only the audio patches are in d-r-t. the video patch (http://lists.freedesktop.org/archives/dri-devel/2010-June/001234.html) is not. Also, as for just getting video working, try booting with radeon.audio=0
Alex Deucher: I have tried booting with radeon.audio=0 (and also setting "options radeon audio=0" in modprobe.conf), but it doesn't seems to work, I still see "card 1: HDMI [HDA ATI HDMI], device 3: ATI HDMI [ATI HDMI]" in aplay -l output (on the other hand, "[drm] Enabling audio support" line is now missing in dmesg output, so maybe it really is disabled?).
Anyway I have tried HDMI with radeon.audio=0 and after activating HDMI output with xrandr, it didn't lock up for the first time (when I tried clone mode) but TV stayed black and displayed "unknown video format". I have tried several resolutions without success and when I tried dual screen setup (instead of clone mode) LVDS finally went also black and lock up. But I could still get into system over SSH and there is still that "[drm:r600_audio_set_clock] *ERROR* Unsupported encoder type 0x19" line in dmesg.
This was tested on drm-radeon-testing kernel. Unfortunately I didn't have time to compile new kernel with that "disable frac fb dividers for rs6xx" patch to try it out yet.