dri-devel March 2018

dri-devel@lists.freedesktop.org

263 participants
1856 discussions

[Bug 102048] Radeon module takes over two seconds to initialize on a Radeon HD 8470D (Richland)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=102048 Bug ID: 102048 Summary: Radeon module takes over two seconds to initialize on a Radeon HD 8470D (Richland) Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: paulepanter(a)users.sourceforge.net Created attachment 133255 --> https://bugs.freedesktop.org/attachment.cgi?id=133255&action=edit Output of `dmesg` Starting Linux with `initcall_debug` shows that the radeon module takes over two seconds to load on a Asus F2A85-M PRO. ``` initcall radeon_init+0x0/0xaf [radeon] returned 0 after 2278773 usecs ``` ``` $ lspci -s 0:01.0 -nn 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Richland [Radeon HD 8470D] [1002:9996] ``` Please find the Linux messages captured by running `dmesg` attached. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 101987] Loud fan and maximum GPU fan speed
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101987 Bug ID: 101987 Summary: Loud fan and maximum GPU fan speed Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: damian.szymanski.ds(a)gmail.com Created attachment 133152 --> https://bugs.freedesktop.org/attachment.cgi?id=133152&action=edit hw-info detalis log Hi. Sorry for all mistake but Im newbie ans sorry for my poor english. I have Radeon HD 5850 and I think something is wrong with him. So even with minimal GPU load, the fan seems to be spinning up to maximum speed, and the fan itself does not mercilessly make a lot of noise but only on open source driver with Mesa. On old legacy fglrx driver all is fine, same as on Windows OS. So I think worth to report this issue. For explain. >From last time I still use AMD Catalyst driver, because I have this issues with open source driver. My Linux distro Mageia 5 still provide fglrx driver, so I still use it but now they release Mageia 6 and old Mageia 5 is supported only for next 3 months. So I need to upgrade or swith distro. Trying few times install on second partitions other Linux distros like Ubuntu 16.04 and 17.04 and Mageia 6 and OpenMandriva LX3 but with this all distro I have still the same issue - noisy gpu fan and almost 100% speed on even low gpu load. So only old Mageia 5 with fglrx or Windows 7 OS can get me silence when I try watch movie, browse internet or playing games. For example, when I start game (e.g free) Dota 2 on Mageia 5 with fglrx, and play it my GPU is silence and the fan is barely audible. But when I boot to other Linux with open source driver with mesa like Ubuntu/Mageia6/OpenMandriva and just start game, even in dota2 main menu I hear the fan spin faster, and faster and faster causing a lot of noise. This is on all games and movies in vlc, smplayer or mpv, even on chromium/chrome or firefox. Trying various mesa version and few version of kernel. Still the same. So if on Linux with fglrx is all fine and if on Windows 7 all is fine and only with Linux with Radeon+Mesa have issue, so it is a bug? Sorry guys, Im newbie and I don't know what I should doing with. Bug? Not a bug? Any solution or fix? Or maybe should I get more info? Help :) -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 101723] hdmi unplug not changing connector status
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101723 Bug ID: 101723 Summary: hdmi unplug not changing connector status Product: DRI Version: unspecified Hardware: All OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: aki.lemmetyinen(a)gmail.com Created attachment 132558 --> https://bugs.freedesktop.org/attachment.cgi?id=132558&action=edit Small patch to fix the problem I made a quick script for my HP Pavilion dv7 to automatically switch audio to hdmi and back at hotplug event, but I noticed that the driver do not react properly to plug/unplug. /sys/class/drm/card0-HDMI-A-1/status was "connected" even after unplugging the cable. After looking at the code it seemed that in case of cable disconnected there is not point where hotplug state is polled. Function radeon_connector_hotplug do not do much with hdmi and radeon_hotplug_work_func cals drm_helper_hpd_irq_event which calls radeon_dvi_detect where, in case of disconnected cable, it return with connector_status_connected, just throwing an error for missing EDID. It looks like there would maybe be a need for a bigger rewrite of hotplug code, but just to get connector state working properly, I added these few lines to radeon_connectors.c. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 101671] "classic" *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101671 Bug ID: 101671 Summary: "classic" *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD) Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: lyssdod(a)gmail.com Hi guys, This error goes for a very long time. I have a hybrid graphics laptop (sandy bridge + radeon), and the only case radeon worked was fglrx. I'm using Gentoo and they have recently dropped any support for fglrx (mostly because AMD and Xorg had), so I tried fresh installation just to get some luck - and it failed exactly as before. Trivia: - radeon and i915 as modules; - power on; - after login manager shows a pic, everything hangs deadly; - using netconsole I was able to get dmesg error when everything freezes: [ 470.521009] [drm] PCIE gen 2 link speeds already enabled [ 470.522846] radeon 0000:01:00.0: No VRAM object for PCIE GART. [ 470.523493] [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume I provide detailed system info shortly. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 101593] Display errors with a R9 290x and a resolution of 3840x2160
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101593 Bug ID: 101593 Summary: Display errors with a R9 290x and a resolution of 3840x2160 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: tardingens(a)googlemail.com Using the radeon driver with an AMD R9 290x and a 4k monitor causes display corruption when set to the native resolution. The problem was introduced with this change: drm/radeon: change vblank_times calculation method to reduce computational error. https://patchwork.kernel.org/patch/9403897/ The issue is very easy to see when the mclk speed is forced to low, but it occurs in normal usage too. Before the patch mclk switching was disabled at 4k and the bug was not there. The Windows driver has no such problems and does fine, even with mclk switching. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 101491] Can't wake up the dedicated graphics card unless power management is disabled
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101491 Bug ID: 101491 Summary: Can't wake up the dedicated graphics card unless power management is disabled Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: drkdfndr(a)rocketmail.com Created attachment 132031 --> https://bugs.freedesktop.org/attachment.cgi?id=132031&action=edit dmesg output I have a ASUS K53TK with a AMD A6-3420M. It has an integrated graphics card the AMD HD 6520G, and a dedicated one HD 7670M. I am only able to use the dedicated card if I set the parameter "radeon.runpm=0". Otherwise xrandr only sees one provider, and DRI_PRIME=1 can't render any program. At boot time, if I don't disable the power management I get several error like [ 458.460874] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xFFFFFFFF). -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 101290] Radeon R9 390X regression - No output (CVT) or corruption (CVT-R) at 4096x2160@60Hz over DisplayPort
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=101290 Bug ID: 101290 Summary: Radeon R9 390X regression - No output (CVT) or corruption (CVT-R) at 4096x2160@60Hz over DisplayPort Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: freedesktop(a)nuclearsunshine.com I had thought I had filed this bug a long time ago on here, but I can't find it... Graphics card: Radeon R9 390X (Saphhire 11241-04-20G) Display: LG 31MU97 (via DisplayPort) With Linux 4.4.x, 4096 x 2160 @ 60 Hz progressive output was working with standard CVT timing. With Linux 4.5.x onwards, standard CVT timing at that resolution fails (no signal) with the following dmesg output: kernel: [drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed kernel: [drm:radeon_dp_link_train [radeon]] *ERROR* channel eq failed: 5 tries CVT-R timing results in output, but with a flickering/corrupted full-height band down the right hand side (it approximates the intended output, but pixels seem be to be corrupt in single-pixel horizontal bands and/or flicker in horizontal single-pixel bands) It could be complete coincidence, but the width of the corrupt band seems to be the difference in width vs. 3840x2160, i.e. aobut 256 pixels. With this timing there are no messages in dmesg. There's a downstream Fedora bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=1353341 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 100941] Improve time to suspend on
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100941 Bug ID: 100941 Summary: Improve time to suspend on Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: paulepanter(a)users.sourceforge.net Created attachment 131223 --> https://bugs.freedesktop.org/attachment.cgi?id=131223&action=edit TML page generated by pm-graph (`sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg`) The ASRock E350M1 has a Radeon HD 6310. ``` $ sudo lspci -s 0:01.0 -nn -v 00:01.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Wrestler [Radeon HD 6310] [1002:9802] Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at e0000000 (32-bit, prefetchable) [size=256M] I/O ports at 2000 [size=256] Memory at f0100000 (32-bit, non-prefetchable) [size=256K] [virtual] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [100] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Kernel driver in use: radeon Kernel modules: radeon ``` With Debian Sid/unstable with Linux 4.9.25 suspend and resume times are benchmarked with pm-graph [1], and the command below. ``` sudo ./analyze_suspend.py -config config/suspend-callgraph.cfg ``` It turns out that with 258 ms the radeon module takes the majority of the time during suspend. In that cycle one `radeon_bo_evict_vram` call takes the longest with 198 ms. ``` […] 459.186778 | 0) kworker-1495 | 0.974 us | radeon_fence_wait_empty [radeon](); 459.186780 | 0) kworker-1495 | 0.440 us | radeon_fence_wait_empty [radeon](); 459.186783 | 0) kworker-1495 | 0.501 us | radeon_fence_wait_empty [radeon](); 459.186785 | 0) kworker-1495 | 5.424 us | radeon_save_bios_scratch_regs [radeon](); 459.186793 | 0) kworker-1495 | 7625.511 us | evergreen_suspend [radeon](); 459.194422 | 0) kworker-1495 | 10.158 us | evergreen_hpd_fini [radeon](); 459.194434 | 0) kworker-1495 | 198203.3 us | radeon_bo_evict_vram [radeon](); […] ``` Please see the attached files for more details. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 100800] With KMS:No link with displayport and A6-3600 APU from 4.4.x to 4.11.0.rc8, unless nomodeset kernel boot parameter
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100800 Bug ID: 100800 Summary: With KMS:No link with displayport and A6-3600 APU from 4.4.x to 4.11.0.rc8, unless nomodeset kernel boot parameter Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: abittner(a)opensuse.org With KMS:No link with displayport and A6-3600 APU from 4.4.x to 4.11.0.rc8, unless nomodeset kernel boot parameter Please see my original distribution bugreport at <https://bugzilla.opensuse.org/show_bug.cgi?id=1035240> Tested with OpenSuSE Leap 42.2 (all x64) kernels 4.4.x up to 4.11.0.rc8 kernels Hardware: Motherboard: F1A75-V PRO by Asus, with AMD cpu/gpu/apu all-in-one: AMD A6-3600 APU with Radeon(tm) HD Graphics hdmi port on motherboard and on the same monitor with hdmi cable works and produces link, same motherboard with displayport cable and ports and same monitor at its displayport port gives no link, unless one uses the "nomodeset" kernel boot parameter. Thank you. -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 100712] ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=100712 Bug ID: 100712 Summary: ring 0 stalled after bytes_moved_threshold reached - Cap Verde - HD 7770 Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: julien.isorce(a)gmail.com Kernel 4.9 from https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-4.9 and latest mesa. (same result with drm-next-4.12 branch) Same result with kernel 4.8 and mesa 12.0.6. In kernel radeon_object.c::radeon_bo_list_validate, once "bytes_moved > bytes_moved_threshold" is reached (this is the case for 850 bo in the same list_for_each_entry loop), I can see that radeon_ib_schedule emits a fence that it takes more than the radeon.lockup_timeout to be signaled. In radeon_fence_activity, I checked that the "last_emitted" is the seq number for this last emited fence. And last_seq is equal to last_emitted-1. Then the next call to ttm_wait_bo blocks (15 * HZ > radeon.lockup_timeout) until gpu lockup which leads to a gpu reset. Also it seems the fence is signaled by swapper after more than 10 seconds but it is too late. I requires to reduce the "15" param above to 4 to see that. Is it normal that radeon_bo_list_validate still tries to move the bo if bytes_moved_threshold is reached ? Indeed ttm_bo_validate is always called (it blits from vram to vram). Is it also normal that ttm_bo_validate is called with evict flag as true once bytes_moved_threshold is reached ? -- You are receiving this mail because: You are the assignee for the bug.

1 10

← Newer
1
2
3
4
5
6
7
8
9
...
186
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2018