dri-devel October 2016

dri-devel@lists.freedesktop.org

215 participants
1390 discussions

[Bug 97635] radeon fails to initialize some DisplayPort monitors
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97635 Bug ID: 97635 Summary: radeon fails to initialize some DisplayPort monitors Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: nybbles2bytes(a)gmail.com Created attachment 126301 --> https://bugs.freedesktop.org/attachment.cgi?id=126301&action=edit Logs to compare all screens properly booted to some not It took a mistake or two but I have been directed that this is the place to report this issue. I believe I am in a unique position to help with DisplayPort issues (and want to do so) because I have been able to generate both working and non-working logs and because I have a significant quantity of DisplayPorts on my system, 6 in total. Also, I put a wealth of information together (automated for completeness and consistency) that should help the development team nail down the cause of this issue. Here's everything I have been able to determine but first the hardware setup: My graphics card is "HD 5870 Eyefinity 6" which has 6 DisplayPorts. I have them setup in a grid of 3 across by 2 down. Each display is at a resolution of 2560x1440 creating a total work area of 7680x2880 in a Xinerama setup running on the KDE4 desktop. I currently have 3 kernels in my grub list which are: kernel-3.16.7 kernel-4.7.0 kernel-4.7.2 These are all with suse's Tumbleweed however kernel-3.16.7 came with openSUSE 13.2. I have no evidence that my problem is related to so many screens of DisplayPorts but it does allow me to see more variations of the problem than most do which helps pinpoint what the real problem is (hopefully!) Focusing on kernel-4.7.2 the kernel would only turn on the first two displays. That happens during boot long before Xorg gets loaded. In Xorg the behavior is a little strange when it gets DisplayPorts off from the kernel. Xorg will acknowledge all 6 displays but it is not able to turn on any that are initially off when the kernel was handling them. E.g.: the last 4 monitors in the case of the 4.x kernels. The upshot is that when I go to the multidisplay setup part of KDE all 6 displays are showing as active even though only the first two are turned on in reality. If I disable and re-enable the displays turned off, they don't turn on. If I use xrandr to turn them on, no dice. That is, if they are off when the kernel was handling them they are off for good, nothing in Xorg or KDE can change it that I have found. That said, adding radeon.audio=0 to the boot makes things better but doesn't fix the issue completely. With that settings sometimes I'll get all 6 boot good, more often I'll get 5 out of six boot good and one bad. Usually, the last one (DisplayPort 5) is the one that fails when one does, however, not always. I went to the trouble to write a script to gather information and I think I got enough to show where things are going wrong. At least enough to show a difference between a good and bad boot and I will help with more information as needed. I really want to get this problem solved and I'll do whatever I can to help. In the tarred file, to see what's different between a good and bad boot all you have to do is a diff on the files: ./logs/timing-stripped/filtered-drm/ screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt screens-0-5-good_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt Anybody who wanted to also gather comprehensive information for the developers could take the file ./gather-info-for-diagnostics.sh in the tarred file and modify as needed for their own system. That said, below explains in detail what's in the tarred compressed file. Directory structure =================== . +-- logs +-- filtered-drm +-- timing-stripped +-- filtered-drm This structure is as follows: . = The script that creates the log files and script to turn on any screens that are off during boot (more on this one later). ./logs ====== The raw log files the script gathered which include: dmsg.txt - from dmesg proc-cmdline.txt - from /proc/cmdline module-kernel-parameters.txt - from /sys/module/kernel/parameters/* module-processor-parameters.txt - from /sys/module/processor/parameters/* sys-module-radeon-parameters.txt - from /sys/module/radeon/parameters/* Xorg.0.log.txt - from /var/log/Xorg.0.log ./logs/filtered-drm =================== Some of the above raw log files with lines that do not contain radeon information removed - makes it easier to see what's relevant. If you want to know exactly how the lines were filtered you can look at the script ./gather-info-for-diagnostics.sh. ./logs/timing-stripped ====================== The above raw log files with the timing at the beginning of each line removed. This makes using diff programs easier (I use meld on Linux). If you want to know exactly how this was done you can look at the script ./gather-info-for-diagnostics.sh. ./logs/timing-stripped/filtered-drm =================================== Some of the above raw log files with the timing at the beginning of each line removed and lines that do not contain radeon information removed. Again, makes it easier to see what's relevant. If you want to know exactly how this was done you can look at the script ./gather-info-for-diagnostics.sh. Scripts ======= ./gather-info-for-diagnostics.sh -------------------------------- Does all the heavy lifting in gathering the info. ./display-on.sh --------------- This was a curious discovery and may make fixing the issue easier. This is because I found when the script was like this: xrandr --output DisplayPort-${1} --mode 1920x1080 xrandr --output DisplayPort-${1} --mode 2560x1440 it sometimes it would turn the display on but others it would turn it off. To consistantly turn the display on I had to change it to this: xrandr --output DisplayPort-${1} --mode 1920x1080 sleep 5 xrandr --output DisplayPort-${1} --mode 2560x1440 suggesting there might be a timing problem that needs to be addressed. Even though running this script can turn the display on that was erroneously off during boot the display will turn itself back off after a few seconds or so so it's not a usable workaround. I guess there is some status flag during boot in the kernel that ultimately can't be changed or overridden that eventually reasserts itself. Update: It may not be that the 5 second delay solved the issue. It may be that just running it again was the solution. Perhaps the first time some cache got cleared, I'm not really sure, some experimenting is in need on this one. File Names ========== File names take the form of: <what happened to the screens at boot>_<partial command line when booting the kernel>_<the file name>.txt E.g. The file: screens-0-4-good-5-bad_kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects_dmsg.txt can be broken down to: screens-0-4-good-5-bad = The first 5 of the 6 screens came on as they should during boot but the 6th one (number 5) did not. kernel-4.7.2-1-default_logo.nologo-radeon.audio=0-debug-debug_objects = shows most of the boot command line dmsg = A key indicating the file contents, from dmesg in this case .txt = That this is a text file If the file starts off with something like this: screens-0-5-good-after-5-fixed-with_display-on.sh it means after booting and logging in I ran the script ./display-on.sh to turn on the display and then gathered all the log information. I will have gathered the log information prior to running the script as well so you will also see files prefixed with just screens-0-5-good in such a case. Let me know what else I can do to help. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 97530] [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97530 Bug ID: 97530 Summary: [HD5650][REDWOOD] kernel commit 8c70e1cda04b966b50ddfefafbd0ea376ed8edd5 causing multiple delays during X server start 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: Heiko.Lechner(a)ruhr-uni-bochum.de Created attachment 126096 --> https://bugs.freedesktop.org/attachment.cgi?id=126096&action=edit log before reverting the patch Hi! https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=… is causing a very long boot delay for me. I attached a Xorg log before and after reverting the patch in the current linux kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 97303] battery mode for dpm state froze
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97303 Bug ID: 97303 Summary: battery mode for dpm state froze Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: ce-ce-mel(a)hotmail.fr I try to use the dpm state, but when I set: echo 'battery' > /sys/class/drm/card0/device/power_dpm_state while on battery power, laptop freezes after a time. I tried to add radeon.dpm=1 and (radeon.bapm=1 or radeon.bapm=0) but it does not fix. Originally, I discovered this issue using TLP (where you can find the ticket https://github.com/linrunner/TLP/issues/186). -- You are receiving this mail because: You are the assignee for the bug.

1 7

[Bug 97249] R290x combined with Mg279q, Dp link fail in ubuntu, in multihead setup.
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97249 Bug ID: 97249 Summary: R290x combined with Mg279q, Dp link fail in ubuntu, in multihead setup. Product: Mesa Version: 11.2 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: ramsland(a)hotmail.com QA Contact: dri-devel(a)lists.freedesktop.org Epuigpment: CPU Amd fx8350, Mboard: Gigabyte GA-990FXA-UD3, Ram 16 gb. Sapphire R9 290x. Monitor setup: 2 monitors, 1 right side (DP-0) Asus MG279q, 1 left(HDMI-0)pb279. Both are 1440p monitors, with the Mq279q have high refreshrate 144hz. Using randr for multihead. OS: Ubuntu 16.04, kernel 4.4.0-31-generic PPA:Obiaf. Problem: The right screen is blank, as long as I try to use standard resolution, meaning 1440p. Can only get it to work in 1080p, at 60hz. It worked perfectly in the old fgrlx when running ubuntu 14.4, and with radeon in ubuntu 14.4, though it might have been both screens at 60hz with the radeon driver. When trying with livecd's, the fedora 24 is working at 1440p at 60 hz, but fails if i try to increase the refresh rate. Ubuntu live 16.04, fails the same way as my install. I think its releated to the radeon driver, but i cant be sure. -- You are receiving this mail because: You are the assignee for the bug.

1 10

[Bug 97084] BUG: scheduling while atomic
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97084 Bug ID: 97084 Summary: BUG: scheduling while atomic 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: amarildosjr(a)riseup.net Created attachment 125330 --> https://bugs.freedesktop.org/attachment.cgi?id=125330&action=edit dmesg Overview: After simulating with X-Plane for a few minutes (can take hours sometimes), the whole OS freezes upon exiting the simulator. Steps to Reproduce: 1) Simulate with X-Plane (currently 10.45) with the "AS350 B3+" helicopter. It could take a few minutes, or it could take several hours (which is normal for a flight Sim). 2) Exit the Simulator. Actual Results: The entire OS froze, requiring a hard-reboot. Expected Results: The Simulator should've just closed. Build Date & Hardware: Don't remember, but started happening almost a year ago. Additional Builds and Platforms: Any Linux distro with Kernel 4.1 and onwards (not being precise on Kernel versioning). Arch, Ubuntu, Mint, Debian Testing/Sid, OpenSUSE, etc. Additional Info: Seems related to https://bugzilla.kernel.org/show_bug.cgi?id=110121 -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 96964] R290X stuck at 100% GPU load / full core clock on non-x86 machines
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96964 Bug ID: 96964 Summary: R290X stuck at 100% GPU load / full core clock on non-x86 machines 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: kb9vqf(a)pearsoncomputing.net Our twin Radeon 290X cards are stuck at 100% GPU load (according to radeontop and Gallium) and full core clock (according to radeon_pm_info) on non-x86 machines such as our POWER8 compute server. The identical card does not show this behaviour on a test x86 machine. Forcibly crashing the GPU (causing a soft reset) fixes the issue. Relevant dmesg output starts at line 4 in this pastebin: https://bugzilla.kernel.org/show_bug.cgi?id=70651 It is unknown if simply triggering a soft reset without the GPU crash would also resolve the issue. I suspect this is related to the atombios x86-specific oprom code only executing on x86 machines, and related setup therefore not being finalized by the radeon driver itself on non-x86 machines. However, this is just an educated guess. radeontop output of stuck card: gpu 100.00%, ee 0.00%, vgt 0.00%, ta 0.00%, sx 0.00%, sh 0.00%, spi 0.00%, sc 0.00%, pa 0.00%, db 0.00%, cb 0.00% radeontop output of "fixed" card after GPU crash / reset, running 3D app: gpu 4.17%, ee 0.00%, vgt 0.00%, ta 3.33%, sx 3.33%, sh 0.00%, spi 3.33%, sc 3.33%, pa 0.00%, db 3.33%, cb 3.33%, vram 11.72% 479.87mb Despite the "100% GPU load" indication, there is no sign of actual load being placed on the GPU. 3D-intensive applications function 100% correctly with no apparent performance degradation, so it seems the reading is a.) spurious and b.) causing the core clock to throttle up needlessly. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[Bug 96838] No console/display output on front/secondary VGA
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96838 Bug ID: 96838 Summary: No console/display output on front/secondary VGA 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: ck(a)claudiokuenzler.com Created attachment 124939 --> https://bugs.freedesktop.org/attachment.cgi?id=124939&action=edit dmesg I originally filed this bug at Ubuntu (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1565679). It turned out to be an upstream bug, because it also happens with the latest mainline kernel. To sum it up: On a Dell PowerEdge 1850 server both Ubuntu trusty and xenial (and as mentioned the mainstream kernel, 4.7-rc6, too) fail to properly show video output on the front (secondary) VGA connector. It works during boot but as soon as Ubuntu/Linux is completely loaded and the login prompt should appear, the screen goes dark. When I then connect the screen on the back (primary) VGA connector of the server, I can see everything. Plug it back to the front VGA, screen goes dark. In dmesg I can see the following entries: Right after boot: ---------------------------- [...] [ 3.179546] [drm] radeon kernel modesetting enabled. [ 3.193916] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3 [ 3.210245] uhci_hcd 0000:00:1d.1: detected 2 ports [ 3.218133] checking generic (f0000000 12c000) vs hw (f0000000 8000000) [ 3.218142] fb: switching to radeondrmfb from simple [ 3.226015] Console: switching to colour dummy device 80x25 [ 3.226024] uhci_hcd 0000:00:1d.1: irq 19, io base 0x0000bcc0 [ 3.226224] usb usb3: New USB device found, idVendor=1d6b, idProduct=0001 [ 3.226237] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 3.226254] usb usb3: Product: UHCI Host Controller [ 3.226265] usb usb3: Manufacturer: Linux 4.7.0-040700rc6-generic uhci_hcd [ 3.226277] usb usb3: SerialNumber: 0000:00:1d.1 [ 3.227514] [drm] initializing kernel modesetting (RV100 0x1002:0x5159 0x1028:0x016C 0x00). [ 3.227557] [drm] register mmio base: 0xFE1F0000 [ 3.227567] [drm] register mmio size: 65536 [ 3.227723] radeon 0000:09:0d.0: VRAM: 128M 0x00000000F0000000 - 0x00000000F7FFFFFF (16M used) [ 3.227742] radeon 0000:09:0d.0: GTT: 512M 0x00000000D0000000 - 0x00000000EFFFFFFF [ 3.227771] [drm] Detected VRAM RAM=128M, BAR=128M [ 3.227781] [drm] RAM width 32bits DDR [ 3.227922] [TTM] Zone kernel: Available graphics memory: 509720 kiB [ 3.227934] [TTM] Initializing pool allocator [ 3.227957] [TTM] Initializing DMA pool allocator [ 3.228055] [drm] radeon: 16M of VRAM memory ready [ 3.228066] [drm] radeon: 512M of GTT memory ready. [ 3.228121] [drm] GART: num cpu pages 131072, num gpu pages 131072 [...] [ 3.250891] [drm] PCI GART of 512M enabled (table at 0x0000000034F00000). [ 3.250975] radeon 0000:09:0d.0: WB disabled [ 3.250987] radeon 0000:09:0d.0: fence driver on ring 0 use gpu addr 0x00000000d0000000 and cpu addr 0xffff8800352ce000 [ 3.250997] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 3.251002] [drm] Driver supports precise vblank timestamp query. [ 3.251024] [drm] radeon: irq initialized. [ 3.251046] [drm] Loading R100 Microcode [ 3.251269] [drm] radeon: ring at 0x00000000D0001000 [ 3.251301] [drm] ring test succeeded in 1 usecs [ 3.251490] [drm] ib test succeeded in 0 usecs [ 3.252447] [drm] No TV DAC info found in BIOS [ 3.252703] [drm] Radeon Display Connectors [ 3.252715] [drm] Connector 0: [ 3.252725] [drm] VGA-1 [ 3.252735] [drm] DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60 [ 3.252744] [drm] Encoders: [ 3.252753] [drm] CRT1: INTERNAL_DAC1 [ 3.252763] [drm] Connector 1: [ 3.252771] [drm] VGA-2 [ 3.252780] [drm] DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c [ 3.252790] [drm] Encoders: [ 3.252797] [drm] CRT2: INTERNAL_DAC2 [ 3.252807] [drm] Connector 2: [ 3.252816] [drm] DVI-I-1 [ 3.252823] [drm] HPD1 [ 3.252834] [drm] DDC: 0x64 0x64 0x64 0x64 0x64 0x64 0x64 0x64 [ 3.252843] [drm] Encoders: [ 3.252851] [drm] CRT2: INTERNAL_DAC2 [ 3.252859] [drm] DFP1: INTERNAL_TMDS1 [ 3.298340] e1000 0000:07:08.0 eth1: (PCI:66MHz:32-bit) 00:11:43:d7:76:29 [ 3.298358] e1000 0000:07:08.0 eth1: Intel(R) PRO/1000 Network Connection [ 3.300843] e1000 0000:06:07.0 enp6s7: renamed from eth0 [ 3.337522] [drm] fb mappable at 0xF0040000 [ 3.337540] [drm] vram apper at 0xF0000000 [ 3.337547] [drm] size 786432 [ 3.337554] [drm] fb depth is 8 [ 3.337562] [drm] pitch is 1024 [ 3.338028] e1000 0000:07:08.0 enp7s8: renamed from eth1 [ 3.338140] fbcon: radeondrmfb (fb0) is primary device [ 3.452030] usb 2-3: new high-speed USB device number 2 using ehci-pci [ 3.482857] clocksource: Switched to clocksource tsc [ 3.482891] Console: switching to colour frame buffer device 128x48 [ 3.491157] radeon 0000:09:0d.0: fb0: radeondrmfb frame buffer device [ 3.500049] [drm] Initialized radeon 2.45.0 20080528 for 0000:09:0d.0 on minor 0 ---------------------------- And when I switched the VGA connectors: ---------------------------- [ 6613.913005] [drm:drm_edid_block_valid [drm]] *ERROR* EDID checksum is invalid, remainder is 92 [ 6613.913151] Raw EDID: [ 6613.913183] 00 ff ff ff ff ff ff 00 10 ac 07 a0 4c 4b 34 30 [ 6613.913255] 04 0f 01 03 0e 29 1f ff ff ff ff ff ff ff ff ff [ 6613.913333] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.913405] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.913484] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.913562] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.913633] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.913711] ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 6613.914978] [drm:radeon_vga_detect [radeon]] *ERROR* VGA-2: probed a monitor but no|invalid EDID ---------------------------- Let me know if you need more information. Attached is the full dmesg output. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 96789] Black screen with R9 290 and Apple Cinema Display 23"
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96789 Bug ID: 96789 Summary: Black screen with R9 290 and Apple Cinema Display 23" 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: benh(a)kernel.crashing.org With Radeon (any recent distro version including upstream 4.7-rc5), my Apple Cinema Display 23" gives a black screen when radeon loads. The monitor is a fairly old DVI LCD 1920x1200x60. It has a fixed timing, ie, no scaler. It used to work with earlier versions of radeons but I haven't used it on a Linux machine for a couple of hears at least. It works using the agd5f's current amdgpu, but not upstream which doesn't support the HAWAII. I isolated the difference that makes it work to the PPLL setting. This one liner fixes it: --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -953,7 +953,7 @@ static void avivo_get_fb_ref_div(unsigned nom, unsigned den, unsigned post_div, unsigned *fb_div, unsigned *ref_div) { /* limit reference * post divider to a maximum */ - ref_div_max = max(min(100 / post_div, ref_div_max), 1u); + ref_div_max = max(min(128 / post_div, ref_div_max), 1u); /* get matching reference and feedback divider */ *ref_div = min(max(DIV_ROUND_CLOSEST(den, post_div), 1u), ref_div_max); Here's a log of the working vs. non-working versions of the calculations in radeon_compute_pll_avivo(). Note that when I did these, I also changed radeon's max_feedback_div to match amdgpu's value of 0xfff instead of 0x7ff in current radeon, though that didn't impact the results. [ 3.471131] fb_div_min/max=4/4095 pll_flags=400 [ 3.471132] by 10 ! fb_div_min/max=40/40950 [ 3.471133] ref_div_min=2 (from 0/2) [ 3.471133] ref_div_max=1023 (from 0/1023) [ 3.471134] vco_min/max=600000/1200000 [ 3.471134] post_div_min/max=4/7 [ 3.471135] initial nom=153970, den=2700 [ 3.471136] reduced nom=15397, den=270 [ 3.471136] - trying post_div 4, ref_div_max=32 [ 3.471137] tentative ref_div=32m, fb_div=7299 [ 3.471137] adjusted ref_div=32m, fb_div=7299 [ 3.471138] diff=7, diff_best=-1 [ 3.471138] - trying post_div 5, ref_div_max=25 [ 3.471139] tentative ref_div=25m, fb_div=7128 [ 3.471139] adjusted ref_div=25m, fb_div=7128 [ 3.471139] diff=6, diff_best=7 [ 3.471140] - trying post_div 6, ref_div_max=21 [ 3.471140] tentative ref_div=21m, fb_div=7185 [ 3.471141] adjusted ref_div=21m, fb_div=7185 [ 3.471141] diff=6, diff_best=6 [ 3.471141] - trying post_div 7, ref_div_max=18 [ 3.471142] tentative ref_div=18m, fb_div=7185 [ 3.471142] adjusted ref_div=18m, fb_div=7185 [ 3.471150] diff=6, diff_best=6 [ 3.471150] post_div_best=7 [ 3.471151] - trying post_div 7, ref_div_max=18 [ 3.471151] tentative ref_div=18m, fb_div=7185 [ 3.471152] adjusted ref_div=18m, fb_div=7185 [ 3.471153] [drm:amdgpu_pll_compute] 153970 - 153960, pll dividers - fb: 239.5 ref: 6, post 7 Now this is with radeon *NOTE: I have bumped the max fb div to the same as AMD GPU when taking that trace but that had no effect: [ 4.718126] fb_div_min/max=4/4095 pll_flags=410 [ 4.718126] by 10 ! fb_div_min/max=40/40950 [ 4.718127] ref_div_min=2 (from 0/2) [ 4.718128] ref_div_max=1023 (from 0/1023) [ 4.718128] vco_min/max=600000/1200000 [ 4.718129] post_div_min/max=4/7 [ 4.718129] initial nom=153970, den=2700 [ 4.718130] reduced nom=15397, den=270 [ 4.718130] - trying post_div 4, ref_div_max=25 [ 4.718131] tentative ref_div=25m, fb_div=5703 [ 4.718131] adjusted ref_div=25m, fb_div=5703 [ 4.718132] diff=11, diff_best=-1 [ 4.718133] - trying post_div 5, ref_div_max=20 [ 4.718133] tentative ref_div=20m, fb_div=5703 [ 4.718133] adjusted ref_div=20m, fb_div=5703 [ 4.718134] diff=11, diff_best=11 [ 4.718134] - trying post_div 6, ref_div_max=16 [ 4.718135] tentative ref_div=16m, fb_div=5474 [ 4.718135] adjusted ref_div=16m, fb_div=5474 [ 4.718136] diff=14, diff_best=11 [ 4.718136] - trying post_div 7, ref_div_max=14 [ 4.718136] tentative ref_div=14m, fb_div=5589 [ 4.718137] adjusted ref_div=14m, fb_div=5589 [ 4.718137] diff=12, diff_best=11 [ 4.718138] post_div_best=5 [ 4.718138] - trying post_div 5, ref_div_max=20 [ 4.718139] tentative ref_div=20m, fb_div=5703 [ 4.718139] adjusted ref_div=20m, fb_div=5703 [ 4.718141] [drm:radeon_compute_pll_avivo] 153970 - 153980, pll dividers - fb: 570.3 ref: 20, post 5 The modeline is: Modeline 55:"1920x1200" 60 153970 1920 1968 2000 2080 1200 1203 1209 1235 0x48 0x9 And is consistent between the 2 drivers (different mode number but same values). -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 96712] Kernel hard LOCKUP related to radeon driver
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96712 Bug ID: 96712 Summary: Kernel hard LOCKUP related to radeon driver 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: lebedev.ri(a)gmail.com Created attachment 124765 --> https://bugs.freedesktop.org/attachment.cgi?id=124765&action=edit dmesg of all that boot This is debian testing, fully updated as of 28 jun 2016 (today) I believe the lockup happened while rendering video via kdenlive (all multithreading options set to 6, gpu acceleration on (not sure it works)), and then trying to change a page in google chrome. $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 6 On-line CPU(s) list: 0-5 Thread(s) per core: 1 Core(s) per socket: 6 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 16 Model: 10 Model name: AMD Phenom(tm) II X6 1075T Processor Stepping: 0 CPU MHz: 3000.000 CPU max MHz: 3000.0000 CPU min MHz: 800.0000 BogoMIPS: 6019.74 Virtualization: AMD-V L1d cache: 64K L1i cache: 64K L2 cache: 512K L3 cache: 6144K NUMA node0 CPU(s): 0-5 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid aperfmperf eagerfpu pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr cpb hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 96487] Cannot force power_dpm_force_performance_level to high
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=96487 Bug ID: 96487 Summary: Cannot force power_dpm_force_performance_level to high Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: ltjbour(a)gmail.com Created attachment 124464 --> https://bugs.freedesktop.org/attachment.cgi?id=124464&action=edit Information about the supported gpu states Linux 4.6.2-1-ARCH #1 SMP PREEMPT Wed Jun 8 08:40:59 CEST 2016 x86_64 GNU/Linux I thought my problem was perhaps a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=70654 but I'm pretty sure that this isn't the same problem. The problem I'm having is that I can't set the highest frequency state from my gpu (AMD A8-4500M APU + HD 7640G), in a consistent and persistent way. And this is regardless of whether uvd is enabled or not (as I assume this is enabled automatically and I haven't been running any application that requires it) In other words I would like to be able to set the dpm level to 'high' so that it stays in the higher frequency state, but I can't set the power_dpm_force_performance variable to anything other than 'auto' and 'low'. I get the following output: λ echo high | sudo tee /sys/class/drm/card0/device/power_dpm_force_performance_level high tee: /sys/class/drm/card0/device/power_dpm_force_performance_level: Invalid argument It turns out that after some testing, I have noticed that it's more stable to set 'performance' dpm state and force it to 'low', which leaves the GPU frequency at ~335MHz, than setting it to auto which makes the frequencies jump between modes [335/490/655]MHz depending on the load. I would obviously like to be able to set a single mode and have a constant frequency. If I can set 655MHz permanently that would be ideal. I've already tried using 'dynpm' and 'profile' modes, but they don't work. I tried a bunch of times, even enabled/disabled some radeon parameters to see if they were somehow conflicting but I wasn't able to succesfully change states a single time. It would permanently stay at 200MHz with either of these two profile modes set. That left me with the single choice of using 'dpm', as it was the only mode that was able to at least change the states. I was told in IRC that the reason I couldn't set the 'high' value permanently was due to a hardware limitation of Trinity chips. I don't see how this can possibly be true as I can get this same GPU to be consistently at its highest frequency state in Windows 8. So if anything this is a limitation of the driver? I've attached the kernel info about the available states, the list of radeon parameters and their values in my system, and the output of /proc/cpuinfo. As of now I don't know what else to add so feel free to ask for any additional information, I'll make it available as soon as I can. -- You are receiving this mail because: You are the assignee for the bug.

1 7

← Newer
1
2
3
4
5
6
7
...
139
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2016