I just bought a new radeon (1002:682c), to pair with my shiny new displayport monitor. It shows a display during through the BIOS POST, and grub, but when the kernel starts up, it's a coin toss whether or not I get anything. Sometimes it just goes straight into power saving.
When I do get something on the console, it continues to boot and then X starts up and puts it into power saving too. Trying to flip back to tty1 doesn't light up the display again.
I'm running On debian stable, with copied-by-hand verde_* firmware files from the linux-firmware git tree. Here's a log from the 4.0-rc2 kernel.
Any other info I can provide ?
Dave
[drm] register mmio base: 0xFBE00000 [drm] register mmio size: 262144 radeon 0000:01:00.0: Invalid ROM contents ATOM BIOS: C755 radeon 0000:01:00.0: VRAM: 2048M 0x0000000000000000 - 0x000000007FFFFFFF (2048M used) radeon 0000:01:00.0: GTT: 1024M 0x0000000080000000 - 0x00000000BFFFFFFF [drm] Detected VRAM RAM=2048M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 16400232 kiB [TTM] Zone dma32: Available graphics memory: 2097152 kiB [TTM] Initializing pool allocator [TTM] Initializing DMA pool allocator [drm] radeon: 2048M of VRAM memory ready [drm] radeon: 1024M of GTT memory ready. [drm] Loading verde Microcode [drm] Internal thermal controller with fan control [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e input: HDA ATI HDMI HDMI as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card0/input4 input: HDA ATI HDMI HDMI as /devices/pci0000:00/0000:00:03.0/0000:01:00.1/sound/card0/input5 [drm] radeon: dpm initialized [drm] GART: num cpu pages 262144, num gpu pages 262144 [drm] probing gen 2 caps for device 8086:2f08 = 77a3103/e [drm] PCIE gen 3 link speeds already enabled [drm] PCIE GART of 1024M enabled (table at 0x0000000000277000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000080000c00 and cpu addr 0xffff880807d0ac00 radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000080000c04 and cpu addr 0xffff880807d0ac04 radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000080000c08 and cpu addr 0xffff880807d0ac08 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000080000c0c and cpu addr 0xffff880807d0ac0c radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000080000c10 and cpu addr 0xffff880807d0ac10 radeon 0000:01:00.0: fence driver on ring 5 use gpu addr 0x0000000000075a18 and cpu addr 0xffffc90001035a18 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [drm] Driver supports precise vblank timestamp query. radeon 0000:01:00.0: radeon: MSI limited to 32-bit radeon 0000:01:00.0: radeon: using MSI. [drm] radeon: irq initialized. [drm] ring test on 0 succeeded in 1 usecs [drm] ring test on 1 succeeded in 1 usecs [drm] ring test on 2 succeeded in 1 usecs [drm] ring test on 3 succeeded in 9 usecs [drm] ring test on 4 succeeded in 3 usecs [drm] ring test on 5 succeeded in 2 usecs [drm] UVD initialized successfully. [drm] ib test on ring 0 succeeded in 0 usecs [drm] ib test on ring 1 succeeded in 0 usecs [drm] ib test on ring 2 succeeded in 0 usecs [drm] ib test on ring 3 succeeded in 0 usecs [drm] ib test on ring 4 succeeded in 0 usecs [drm] ib test on ring 5 succeeded [drm] Radeon Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x6540 0x6540 0x6544 0x6544 0x6548 0x6548 0x654c 0x654c [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] DP-2 [drm] HPD5 [drm] DDC: 0x6530 0x6530 0x6534 0x6534 0x6538 0x6538 0x653c 0x653c [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY1 [drm] Connector 2: [drm] DP-3 [drm] HPD1 [drm] DDC: 0x6560 0x6560 0x6564 0x6564 0x6568 0x6568 0x656c 0x656c [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY1 [drm] Connector 3: [drm] DP-4 [drm] HPD2 [drm] DDC: 0x6580 0x6580 0x6584 0x6584 0x6588 0x6588 0x658c 0x658c [drm] Encoders: [drm] DFP4: INTERNAL_UNIPHY [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed [drm] fb mappable at 0xD047A000 [drm] vram apper at 0xD0000000 [drm] size 3145728 [drm] fb depth is 24 [drm] pitch is 4096 fbcon: radeondrmfb (fb0) is primary device [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed Console: switching to colour frame buffer device 128x48 radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device radeon 0000:01:00.0: registered panic notifier [drm] Initialized radeon 2.42.0 20080528 for 0000:01:00.0 on minor 0 [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
The link training with the monitor seems to fail periodically. You may have to play with the timing in the link training sequence. It looks like you also have some power management related issues. Does booting with radeon.dpm=0 on the kernel command line in grub help? Also does the monitor support audio? You might also try radeon.audio=0.
Alex
On Fri, May 08, 2015 at 01:23:59PM +0000, Deucher, Alexander wrote:
Pretty much the same story with those options..
[ 8.162285] [drm:si_dpm_set_power_state [radeon]] *ERROR* si_enable_smc_cac failed [ 8.170753] [drm:radeon_dp_link_train [radeon]] *ERROR* displayport link status failed [ 8.170778] [drm:radeon_dp_link_train [radeon]] *ERROR* clock recovery failed
I did manage to get it to display something for a while. By disabling DP1.2 with the LCDs OSD, but then it would only do a maximum of 1024x768. And after a reboot, I saw the same messages above, and straight to power saving.
Dave
On Fri, May 08, 2015 at 11:40:55AM -0400, Dave Jones wrote:
On Fri, May 08, 2015 at 01:23:59PM +0000, Deucher, Alexander wrote:
I tried tweaking the delays in drm_dp_link_train_clock_recovery_delay, without any noticable difference. Is there something else I can try to make it try harder before giving up?
Dave
On Mon, May 11, 2015 at 2:40 PM, Dave Jones davej@codemonkey.org.uk wrote:
Can you attach your boot dmesg output with drm.debug=0xf set?
You might also check the dpcd values in the driver during boot up and link training. There appears to be an issue where that data gets corrupted in some cases: https://bugs.freedesktop.org/show_bug.cgi?id=73530
Alex
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
Sure. Attached. I noticed some of the printks are garbled. Hopefully the important parts lie elsewhere.
Hm, I'll try out some of the patches in that report later (Assuming they aren't already in the 4.1rc kernel)
thanks for the pointers.
Dave
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
Can you attach your boot dmesg output with drm.debug=0xf set?
Strange, haven't seen this happen before.
[ 8.437431] [drm:drm_calc_vbltimestamp_from_scanoutpos] crtc 5: Noop due to uninitialized mode. [ 8.437433] [drm:drm_update_vblank_count] updating vblank count on crtc 5, missed 0 [ 8.437444] [drm:drm_helper_probe_single_connector_modes_merge_bits] [CONNECTOR:40:DP-1] [ 8.437506] [drm:si_irq_process] si_irq_process start: rptr 208, wptr 224 [ 8.437523] [drm:si_irq_process] si_irq_process start: rptr 224, wptr 224 [ 8.440711] [drm:radeon_dp_getdpcd] DPCD: 12 14 c4 01 01 01 01 81 02 00 06 00 00 00 00 [ 8.441242] [drm:radeon_dp_aux_transfer_native] dp_aux_ch flags not zero: 04001001 [ 8.441758] [drm:radeon_dp_probe_oui] Branch OUI: 00e04c [ 8.442204] [drm:radeon_dp_mst_probe] Sink is MST capable [ 8.742140] Oops: 0000 [#1] PREEMPT SMP [ 8.742150] CPU: 3 PID: 418 Comm: systemd-udevd Not tainted 4.1.0-rc3-wopr+ #3 [ 8.742156] task: ffff88080a09f290 ti: ffff880808224000 task.ti: ffff880808224000 [ 8.742160] RIP: 0010:[<ffffffff863baf70>] [<ffffffff863baf70>] __list_add+0x50/0xe0 [ 8.742167] RSP: 0018:ffff8808082276b8 EFLAGS: 00010246 [ 8.742170] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000000 [ 8.742173] RDX: ffff880805871720 RSI: 0000000000000000 RDI: ffff8808082276f8 [ 8.742175] RBP: ffff8808082276e8 R08: ffff880808224000 R09: 0000000000000000 [ 8.742178] R10: 000000000000003d R11: 000000000000053e R12: ffff880805871720 [ 8.742181] R13: ffff88080a09f290 R14: 00000000ffffffff R15: ffff880805871720 [ 8.742184] FS: 00007f16f77bd880(0000) GS:ffff88080f2c0000(0000) knlGS:0000000000000000 [ 8.742188] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 8.742190] CR2: 0000000000000000 CR3: 000000080820b000 CR4: 00000000001407e0 [ 8.742193] Stack: [ 8.742195] 0000000000000001 ffff880805871718 0000000000000001 ffff880805871718 [ 8.742200] ffff88080587171c ffff88080a09f290 ffff880808227748 ffffffff866ec970 [ 8.742205] ffff880808227758 ffffffff866e5488 0000000000000018 00000000bea51cc4 [ 8.742210] Call Trace: [ 8.742216] [<ffffffff866ec970>] __mutex_lock_slowpath+0x80/0x150 [ 8.742220] [<ffffffff866e5488>] ? printk+0x55/0x6b [ 8.742223] [<ffffffff866eca5b>] mutex_lock+0x1b/0x30 [ 8.742230] [<ffffffffc04667da>] drm_dp_mst_topology_mgr_set_mst+0x3a/0x3e0 [drm_kms_helper] [ 8.742251] [<ffffffffc075591a>] radeon_dp_mst_probe+0xaa/0x100 [radeon] [ 8.742268] [<ffffffffc068e04d>] radeon_dp_detect+0x26d/0x2f0 [radeon] [ 8.742273] [<ffffffffc0462de8>] drm_helper_probe_single_connector_modes_merge_bits+0x2c8/0x510 [drm_kms_helper] [ 8.742278] [<ffffffffc0463043>] drm_helper_probe_single_connector_modes+0x13/0x20 [drm_kms_helper] [ 8.742285] [<ffffffffc046ce40>] drm_fb_helper_probe_connector_modes.isra.3+0x50/0x70 [drm_kms_helper] [ 8.742291] [<ffffffffc046e26a>] drm_fb_helper_initial_config+0x5a/0x410 [drm_kms_helper] [ 8.742304] [<ffffffffc049c3f2>] ? drm_modeset_unlock_all+0x42/0x70 [drm] [ 8.742321] [<ffffffffc069a4a4>] radeon_fbdev_init+0xf4/0x120 [radeon] [ 8.742335] [<ffffffffc0693704>] radeon_modeset_init+0x484/0xa60 [radeon] [ 8.742354] [<ffffffffc075231a>] ? radeon_ib_ring_tests+0x5a/0xc0 [radeon] [ 8.742368] [<ffffffffc06684e0>] radeon_driver_load_kms+0x140/0x250 [radeon] [ 8.742375] [<ffffffffc0485aa5>] drm_dev_register+0xb5/0x110 [drm] [ 8.742382] [<ffffffffc0488b9d>] drm_get_pci_dev+0x8d/0x200 [drm] [ 8.742394] [<ffffffffc064a4b3>] radeon_pci_probe+0xa3/0xd0 [radeon] [ 8.742398] [<ffffffff863d96fc>] pci_device_probe+0x8c/0xf0 [ 8.742402] [<ffffffff864bd049>] driver_probe_device+0x159/0x4c0 [ 8.742405] [<ffffffff864bd48b>] __driver_attach+0x9b/0xa0 [ 8.742408] [<ffffffff864bd3f0>] ? __device_attach+0x40/0x40 [ 8.742412] [<ffffffff864bac53>] bus_for_each_dev+0x73/0xc0 [ 8.742415] [<ffffffff864bc9de>] driver_attach+0x1e/0x20 [ 8.742418] [<ffffffff864bc5b0>] bus_add_driver+0x180/0x250 [ 8.742421] [<ffffffff864bd8f4>] driver_register+0x64/0xf0 [ 8.742425] [<ffffffff863d8b0b>] __pci_register_driver+0x4b/0x50 [ 8.742432] [<ffffffffc0488e0a>] drm_pci_init+0xfa/0x130 [drm] [ 8.742436] [<ffffffffc082d000>] ? 0xffffffffc082d000 [ 8.742448] [<ffffffffc082d0dd>] radeon_init+0xdd/0xdf [radeon] [ 8.742454] [<ffffffff860002f8>] do_one_initcall+0xd8/0x200 [ 8.742458] [<ffffffff86194ee2>] ? __vunmap+0xa2/0x100 [ 8.742462] [<ffffffff861a8003>] ? kfree+0x173/0x180 [ 8.742465] [<ffffffff866e56e2>] do_init_module+0x61/0x1cc [ 8.742469] [<ffffffff860f2970>] load_module+0x1f90/0x23b0 [ 8.742472] [<ffffffff860ee260>] ? store_uevent+0x70/0x70 [ 8.742476] [<ffffffff860eed65>] ? copy_module_from_fd.isra.48+0xe5/0x1a0 [ 8.742479] [<ffffffff860eedb2>] ? copy_module_from_fd.isra.48+0x132/0x1a0 [ 8.742483] [<ffffffff8610c43b>] ? __acct_update_integrals+0x8b/0x120 [ 8.742486] [<ffffffff860f2fa6>] SyS_finit_module+0xa6/0xe0 [ 8.742490] [<ffffffff866eed57>] system_call_fastpath+0x12/0x6a [ 8.742493] Code: c1 30 cc 84 86 31 c0 48 c7 c2 38 83 a3 86 be 1a 00 00 00 48 c7 c7 b8 7d a3 86 e8 cc d8 cb ff 48 83 c4 18 5b 41 5c 41 5d 5d c3 90 <4c> 8b 0e 4c 39 ca 74 38 48 89 34 24 49 89 d0 48 c7 c1 30 cc 84
On Mon, May 11, 2015 at 03:59:55PM -0400, Alex Deucher wrote:
I tried both the 'disable spread spectrum' and 'grab dpcd info from vbios for eDP' patches from that bug. Again, no obvious difference.
Log from kernel with both applied attached.
Also a log file from after I woke up the LCD when it was in sleep mode.
Something else curious is how it only discovers a maximum mode from the LCD of 1024x768.
Dave
On Tue, May 12, 2015 at 8:04 PM, Dave Jones davej@codemonkey.org.uk wrote:
I looks like the monitor is not responding. I'm not entirely sure what's going on. I posted a new debugging patch on the bug report that will dump the dpcd at various times to see if and when it's getting corrupt. Fixing that should at least get the monitor to come up reliably (assuming you are experiencing the same issue).
Alex
On Thu, May 14, 2015 at 09:49:52AM -0400, Alex Deucher wrote:
Thanks to some back-and-forth on irc, airlied got this mostly working. The working combo seems to be..
- Switch monitor to DP 1.2 - boot with radeon.mst=1 - apply the patch below
With all that, it boots up, and X starts up in 2560x1440 like it should.
The only remaining problem is there are some visible glitches, mostly noticable while scrolling a terminal.
Happy to continue applying further debug patches if you have any more ideas.
thanks, Dave
diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c b/drivers/gpu/drm/radeon/radeon_dp_auxch.c index bf1fecc6cceb..3b401cc8d209 100644 --- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c +++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c @@ -30,7 +30,6 @@ AUX_SW_RX_HPD_DISCON | \ AUX_SW_RX_PARTIAL_BYTE | \ AUX_SW_NON_AUX_MODE | \ - AUX_SW_RX_MIN_COUNT_VIOL | \ AUX_SW_RX_INVALID_STOP | \ AUX_SW_RX_SYNC_INVALID_L | \ AUX_SW_RX_SYNC_INVALID_H | \
On 15.05.2015 12:52, Dave Jones wrote:
The only remaining problem is there are some visible glitches, mostly noticable while scrolling a terminal.
What kind of glitches? If it's tearing, with current xf86-video-ati Git you can try Option "TearFree".
On Fri, May 15, 2015 at 06:16:59PM +0900, Michel Dänzer wrote:
Hard to describe, just sort of.. bursts of coloured sparkle noise in random positions. They don't remain part of the image permanently, and only appear for a split second. They are pretty constant when scrolling though.
I'll see if I can get video of it when I'm in front of it again on Monday.
One other bug I noticed: Once it goes into DPMS, I can't wake it up again and need to reboot. Likewise if I power off the monitor and back on, it goes into power saving again.
Dave
On Thu, May 14, 2015 at 11:52 PM, Dave Jones davej@codemonkey.org.uk wrote:
I think the attached patch should get aux working as reliably as the old atom code. The atom code ignores bits 12-14 when checking the transaction flags.
Alex
dri-devel@lists.freedesktop.org
-
Alex Deucher -
Dave Jones -
Deucher, Alexander -
Michel Dänzer