dri-devel September 2017

dri-devel@lists.freedesktop.org

210 participants
1526 discussions

[Bug 99049] Machine freeze when clock are set to defaults
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=99049 Bug ID: 99049 Summary: Machine freeze when clock are set to defaults 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: ls(a)maxux.net My laptop contains theses cards: ---- 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07) 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Sun XT [Radeon HD 8670A/8670M/8690M / R5 M330] (rev 81) ---- Under Gentoo, I enabled radeon and radeonsi as videos cards, everything looks fine. According to xrandr, I have providers: ---- Provider 0: id: 0x76 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 4 outputs: 3 associated providers: 0 name:Intel Provider 1: id: 0x4f cap: 0xd, Source Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 0 name:HAINAN @ pci:0000:01:00.0 ---- I found on the internet that DPM could cause issue, I tried: radeon.runpm=0 radeon.dpm=0 (see below) Using theses settings, I don't have any freeze when I try to use the Radeon Card (using DRI_PRIME=1), but I found that everything was slow. I checked, and I saw: --- cat /sys/class/drm/card1/device/power_method profile cat /sys/class/drm/card1/device/power_profile default cat /sys/kernel/debug/dri/65/radeon_pm_info default engine clock: 1070000 kHz current engine clock: 299990 kHz default memory clock: 900000 kHz current memory clock: 298990 kHz voltage: 1150 mV PCIE lanes: 4 --- The card is running in low profile by default, don't know why. Setting power_profile to high, mid or low doesn't change anything, but if I set power_profile back to default again, the clock is set to full speed. When clock is set to full speed, my system freeze if I try to run any 3D application (glxgears or a game using wine). Here is the dmesg log: --- radeon 0000:01:00.0: ring 0 stalled for more than 10436msec radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000014f4 last fence id 0x00000000000014f6 on ring 0) radeon 0000:01:00.0: Saved 49 dwords of commands on ring 0. radeon 0000:01:00.0: GPU softreset: 0x00000049 radeon 0000:01:00.0: GRBM_STATUS = 0xE5D04028 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0xEE400000 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000006 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00018000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00008000 radeon 0000:01:00.0: R_008680_CP_STAT = 0x80030243 radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x00000000 radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x00000000 radeon 0000:01:00.0: GRBM_SOFT_RESET=0x0000DDFF radeon 0000:01:00.0: SRBM_SOFT_RESET=0x00000100 radeon 0000:01:00.0: GRBM_STATUS = 0x00003028 radeon 0000:01:00.0: GRBM_STATUS_SE0 = 0x00000006 radeon 0000:01:00.0: GRBM_STATUS_SE1 = 0x00000006 radeon 0000:01:00.0: SRBM_STATUS = 0x200000C0 radeon 0000:01:00.0: SRBM_STATUS2 = 0x00000000 radeon 0000:01:00.0: R_008674_CP_STALLED_STAT1 = 0x00000000 radeon 0000:01:00.0: R_008678_CP_STALLED_STAT2 = 0x00000000 radeon 0000:01:00.0: R_00867C_CP_BUSY_STAT = 0x00000000 radeon 0000:01:00.0: R_008680_CP_STAT = 0x00000000 radeon 0000:01:00.0: R_00D034_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: R_00D834_DMA_STATUS_REG = 0x44C83D57 radeon 0000:01:00.0: GPU reset succeeded, trying to resume [drm] probing gen 2 caps for device 8086:9d10 = 1724843/e [drm] PCIE gen 3 link speeds already enabled [drm] PCIE GART of 2048M enabled (table at 0x0000000000040000). radeon 0000:01:00.0: WB enabled radeon 0000:01:00.0: fence driver on ring 0 use gpu addr 0x0000000100000c00 and cpu addr 0xffff88046c66dc00 radeon 0000:01:00.0: fence driver on ring 1 use gpu addr 0x0000000100000c04 and cpu addr 0xffff88046c66dc04 radeon 0000:01:00.0: fence driver on ring 2 use gpu addr 0x0000000100000c08 and cpu addr 0xffff88046c66dc08 radeon 0000:01:00.0: fence driver on ring 3 use gpu addr 0x0000000100000c0c and cpu addr 0xffff88046c66dc0c radeon 0000:01:00.0: fence driver on ring 4 use gpu addr 0x0000000100000c10 and cpu addr 0xffff88046c66dc10 [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x850C)=0xCAFEDEAD) [drm:si_resume [radeon]] *ERROR* si startup failed on resume --- I found out with theses steps that, if I don't set dpm=0, I hit exactly the same issue, I guess using DPM the clock is set to high when the card is used and it crash. When the card is stuck on that loop, I need to reset the machine (but network still works). I'm using mesa-13.0.2 with a 4.7.6 kernel, I have the same issue using mesa 12.0.1 -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 98988] [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=98988 Bug ID: 98988 Summary: [Regression, bisected] New BONAIRE UVD firmware causes DPM problems and extremely slow performance 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: falaca(a)gmail.com Created attachment 128327 --> https://bugs.freedesktop.org/attachment.cgi?id=128327&action=edit Kernel bisect log I have a 2GB Radeon R7 260X (BONAIRE). With kernel 4.7 and above, I was experiencing extremely slow performance. Even desktop animations on Ubuntu 16.04 w/ Unity desktop are extremely choppy, probably about 10fps. dmesg produces several instances of the following error message: [drm:ci_dpm_set_power_state [radeon]] *ERROR* ci_upload_dpm_level_enable_mask failed I did a kernel bisect, and narrowed the problem to the following commit: http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/… The bisect log is attached. It seems that the commit adds support for a new firmware file, "bonaire_uvd.bin". If the driver fails in loading the new firmware file, it falls back to the legacy file, "BONAIRE_uvd.bin". To confirm that the issue is caused by the new firmware, I deleted bonaire_uvd.bin, and performance is restored to normal with the latest stable kernel (4.9.0-rc7). For what it's worth, here are the contents of /sys/kernel/debug/dri/64/radeon_pm_info while idling on the Ubuntu desktop with the new firmware: uvd disabled vce disabled power level avg sclk: 115774 mclk: 15000 And the old firmware: uvd disabled vce disabled power level avg sclk: 30248 mclk: 165000 -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 98987] [RS690] BUG: soft lockup when radeon modesetting
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=98987 Bug ID: 98987 Summary: [RS690] BUG: soft lockup when radeon modesetting Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: critical Priority: high Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: vaclav.ovsik(a)gmail.com Created attachment 128323 --> https://bugs.freedesktop.org/attachment.cgi?id=128323&action=edit logged using netconsole - kernel 4.8.7 (Debian kernel) Dear developers, I'm unable to boot into functional system with KMS radeon. When radeon.modeset=0 on kernel command-line system it starts and run OK. Without disabled modeset the kernel 4.7, 4.8, 4.9-rc7 with 90% probability locks or crash. I'm running Debian unstable and tried Debian kernels 4.7, 4.8 from Debian and compile 4.9rc7 vanilla kernel. Attached logs through netconsole. Any idea what I can test? Thanks -- Zito ref: debian bug #845382 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845382 -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 98620] radeon kernel module NULL pointer dereference on Radeon 9550 at shut-down
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=98620 Bug ID: 98620 Summary: radeon kernel module NULL pointer dereference on Radeon 9550 at shut-down 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: arthur.marsh(a)internode.on.net Created attachment 127808 --> https://bugs.freedesktop.org/attachment.cgi?id=127808&action=edit full dmesg when crashing At shut-down: [ 2515.296325] BUG: unable to handle kernel NULL pointer dereference at 000007b4 [ 2515.300025] IP: [<f8593b36>] radeon_connector_unregister+0x6/0x40 [radeon] [ 2515.300025] *pde = 00000000 [ 2515.300025] Oops: 0000 [#1] PREEMPT SMP [ 2515.300025] Modules linked in: eata cpufreq_conservative cpufreq_powersave cp ufreq_userspace binfmt_misc nls_utf8 nls_cp437 vfat fat hwmon_vid tun cuse fuse iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi lp ppdev powernow_k8 amd64_ edac_mod edac_mce_amd edac_core snd_via82xx snd_ac97_codec pcspkr ac97_bus snd_m pu401_uart radeon snd_pcm snd_timer snd_rawmidi evdev snd_seq_device gameport sn d ttm drm_kms_helper soundcore serio_raw drm k8temp i2c_algo_bit fb_sys_fops i2c _viapro syscopyarea sysfillrect sysimgblt sg parport_pc parport asus_atk0110 acp i_cpufreq button tpm_tis tpm_tis_core tpm ext4 crc16 jbd2 mbcache sr_mod cdrom a ta_generic uas sd_mod usb_storage psmouse via_rhine mii pata_via ehci_pci uhci_h cd ehci_hcd usbcore usb_common libata scsi_mod [last unloaded: eata] [ 2515.300025] CPU: 0 PID: 7439 Comm: reboot Not tainted 4.9.0-rc4 #520 [ 2515.300025] Hardware name: System manufacturer System Product Name/A8V-MX, BI OS 0503 12/06/2005 [ 2515.300025] task: f2cc6080 task.stack: f3934000 [ 2515.300025] EIP: 0060:[<f8593b36>] EFLAGS: 00010286 CPU: 0 [ 2515.300025] EIP is at radeon_connector_unregister+0x6/0x40 [radeon] [ 2515.300025] EAX: f73a1000 EBX: f73a1000 ECX: 00000006 EDX: 00000000 [ 2515.300025] ESI: f5a09c64 EDI: f5a09800 EBP: f3935db4 ESP: f3935dac [ 2515.300025] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 2515.300025] CR0: 80050033 CR2: 000007b4 CR3: 33dbc000 CR4: 000006d0 [ 2515.300025] Stack: [ 2515.300025] f83471d7 f73a1000 f3935dc4 f8347967 f5a09800 f5a09c8c f3935dd8 f 83383b3 [ 2515.300025] f5a09800 f5a09800 f86a0000 f3935dec f8332ff7 f5a09800 f61d3000 f 86a0000 [ 2515.300025] f3935e04 f8333640 f8358dca 00000001 f8358dc8 f61d3068 f3935e0c f 85702ee [ 2515.300025] Call Trace: [ 2515.300025] [<f83471d7>] ? drm_connector_unregister.part.6+0x17/0x30 [drm] [ 2515.300025] [<f8347967>] drm_connector_unregister_all+0x37/0x50 [drm] [ 2515.300025] [<f83383b3>] drm_modeset_unregister_all+0x13/0x50 [drm] [ 2515.300025] [<f8332ff7>] drm_dev_unregister+0x97/0xa0 [drm] [ 2515.300025] [<f8333640>] drm_put_dev+0x30/0x70 [drm] [ 2515.300025] [<f85702ee>] radeon_pci_shutdown+0xe/0x10 [radeon] [ 2515.300025] [<c134da9d>] pci_device_shutdown+0x2d/0x70 [ 2515.300025] [<c140b834>] device_shutdown+0xb4/0x170 [ 2515.300025] [<c108126d>] kernel_restart_prepare+0x2d/0x30 [ 2515.300025] [<c10812fe>] kernel_restart+0xe/0x60 [ 2515.300025] [<c108162f>] SYSC_reboot+0x1bf/0x200 [ 2515.300025] [<c10cd2ea>] ? debug_lockdep_rcu_enabled+0x1a/0x20 [ 2515.300025] [<c10cd2ea>] ? debug_lockdep_rcu_enabled+0x1a/0x20 [ 2515.300025] [<c11f9c50>] ? mnt_get_count+0x40/0x40 [ 2515.300025] [<c11f9cbf>] ? mntput_no_expire+0x6f/0x3a0 [ 2515.300025] [<c11f9cd9>] ? mntput_no_expire+0x89/0x3a0 [ 2515.300025] [<c11f9c50>] ? mnt_get_count+0x40/0x40 [ 2515.300025] [<c11fa00b>] ? mntput+0x1b/0x30 [ 2515.300025] [<c11d7963>] ? __fput+0x153/0x1d0 [ 2515.300025] [<c107ca4f>] ? task_work_run+0x6f/0x80 [ 2515.300025] [<c10b02ac>] ? trace_hardirqs_on_caller+0xec/0x1d0 [ 2515.300025] [<c10ad2eb>] ? trace_hardirqs_off+0xb/0x10 [ 2515.300025] [<c10816da>] SyS_reboot+0x1a/0x20 [ 2515.300025] [<c1001c7a>] do_fast_syscall_32+0x9a/0x220 [ 2515.300025] [<c15ae2ec>] sysenter_past_esp+0x45/0x74 [ 2515.300025] Code: d8 e8 df 36 db ff 89 d8 e8 f8 36 db ff 89 d8 e8 11 58 c2 c8 5b 5d c3 8d b4 26 00 00 00 00 8d bc 27 00 00 00 00 8b 90 d4 02 00 00 <80> ba b4 07 00 00 00 75 01 c3 55 89 e5 53 89 c3 8d 82 e8 03 00 [ 2515.300025] EIP: [<f8593b36>] [ 2515.300025] radeon_connector_unregister+0x6/0x40 [radeon] [ 2515.300025] SS:ESP 0068:f3935dac [ 2515.300025] CR2: 00000000000007b4 [ 2516.877047] ---[ end trace 076c5e2ae2d51112 ]--- Full dmesg from boot to crash is attached. # lspci -vv -s 01:00 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9550] (prog-if 00 [VGA controller]) Subsystem: Gigabyte Technology Co., Ltd RV350 [Radeon 9550] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (2000ns min), Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: Memory at a0000000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at b000 [size=256] Region 2: Memory at ff4f0000 (32-bit, non-prefetchable) [size=64K] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [58] AGP version 3.0 Status: RQ=256 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW+ AGP3+ Rate=x4,x8 Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x8 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: radeon Kernel modules: radeonfb, radeon 01:00.1 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] RV350 [Radeon 9550] (Secondary) Subsystem: Gigabyte Technology Co., Ltd RV350 [Radeon 9550] (Secondary) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64 (2000ns min), Cache Line Size: 64 bytes Region 0: Memory at 90000000 (32-bit, prefetchable) [size=256M] Region 1: Memory at ff4e0000 (32-bit, non-prefetchable) [size=64K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- git-bisect revealed: git bisect bad b0c80bd5d2e317f7596fe2badc1a3379fb3211e5 is the first bad commit commit b0c80bd5d2e317f7596fe2badc1a3379fb3211e5 Author: Alex Deucher <alexander.deucher(a)amd.com> Date: Tue Oct 11 10:44:24 2016 -0400 drm/radeon: fix up dp aux tear down (v2) Port the amdgpu fixes from Grazvydas to radeon. v2: drop unrelated whitespace change. bug: https://bugs.freedesktop.org/show_bug.cgi?id=98200 Reviewed-and-Tested-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> :040000 040000 b187ce6d75761c9e2eed71b385c8e0f085dbfd55 aca34c667d6253da66e824b2 a624f308841555b0 M drivers Rebuilding and running the kernel with that commit removed confirmed normal shutdown. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 98481] [Hawaii] Radeon kernel oops with vfio-pci
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=98481 Bug ID: 98481 Summary: [Hawaii] Radeon kernel oops with vfio-pci Product: DRI Version: XOrg git Hardware: PowerPC OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: kb9vqf(a)pearsoncomputing.net When DPM is enabled (dpm=1) and a Hawaii card (Radeon R9 290X) is passed to a QEMU virtual machine via vfio, the guest kernel oopses with the following output: [ 1298.394440] [drm] Initialized drm 1.1.0 20060810 [ 1298.426253] [drm] radeon kernel modesetting enabled. [ 1298.426284] checking generic (100a0000000 1d4c00) vs hw (10130000000 10000000) [ 1298.427014] [drm] initializing kernel modesetting (HAWAII 0x1002:0x67B0 0x1002:0x0B00 0x00). [ 1298.427030] [drm] register mmio base: 0xE0000000 [ 1298.427034] [drm] register mmio size: 262144 [ 1298.427038] [drm] doorbell mmio base: 0x40000000 [ 1298.427042] [drm] doorbell mmio size: 8388608 [ 1298.427082] [drm:radeon_device_init [radeon]] *ERROR* Unable to find PCI I/O BAR [ 1298.917871] [drm:radeon_atombios_init [radeon]] *ERROR* Unable to find PCI I/O BAR; using MMIO for ATOM IIO [ 1298.917880] ATOM BIOS: C67101 [ 1298.917971] radeon 0000:00:03.0: VRAM: 4096M 0x0000000000000000 - 0x00000000FFFFFFFF (4096M used) [ 1298.917975] radeon 0000:00:03.0: GTT: 2048M 0x0000000100000000 - 0x000000017FFFFFFF [ 1298.917978] [drm] Detected VRAM RAM=4096M, BAR=256M [ 1298.917980] [drm] RAM width 512bits DDR [ 1298.918085] [TTM] Zone kernel: Available graphics memory: 33505984 kiB [ 1298.918088] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 1298.918091] [TTM] Initializing pool allocator [ 1298.918119] [drm] radeon: 4096M of VRAM memory ready [ 1298.918122] [drm] radeon: 2048M of GTT memory ready. [ 1298.918141] [drm] Loading hawaii Microcode [ 1298.918151] [drm] Internal thermal controller with fan control [ 1298.918206] Unable to handle kernel paging request for data at address 0x0000003c [ 1298.918210] Faulting instruction address: 0xd00000000b3bff68 [ 1298.918214] Oops: Kernel access of bad area, sig: 11 [#1] [ 1298.918216] SMP NR_CPUS=2048 NUMA pSeries [ 1298.918220] Modules linked in: radeon(E+) ttm(E) drm_kms_helper(E) drm(E) fuse(E) sg(E) snd_hda_codec_hdmi(E) evdev(E) snd_hda_intel(E) snd_hda_codec(E) snd_hda_core(E) snd_hwdep(E) snd_pcm(E) snd_timer(E) snd(E) ghash_generic(E) gf128mul(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) fb_sys_fops(E) vmx_crypto(E) i2c_algo_bit(E) soundcore(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) jbd2(E) crc32c_generic(E) fscrypto(E) ecb(E) mbcache(E) sd_mod(E) sr_mod(E) cdrom(E) hid_generic(E) usbhid(E) hid(E) ibmvscsi(E) scsi_transport_srp(E) virtio_net(E) virtio_pci(E) virtio_ring(E) virtio(E) xhci_pci(E) xhci_hcd(E) usbcore(E) usb_common(E) [last unloaded: drm] [ 1298.918268] CPU: 32 PID: 2466 Comm: modprobe Tainted: G W E 4.8.0-trunk-powerpc64le #1 Debian 4.8.4-1~exp1 [ 1298.918273] task: c000000fea6b9b80 task.stack: c000000fe123c000 [ 1298.918276] NIP: d00000000b3bff68 LR: d00000000ba30c88 CTR: d00000000b3bff20 [ 1298.918280] REGS: c000000fe123ede0 TRAP: 0300 Tainted: G W E (4.8.0-trunk-powerpc64le Debian 4.8.4-1~exp1) [ 1298.918284] MSR: 800000010280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 84228428 XER: 20000000 [ 1298.918296] CFAR: c0000000000acea8 DAR: 000000000000003c DSISR: 40000000 SOFTE: 1 GPR00: d00000000ba30c88 c000000fe123f060 d00000000b40af90 c000000fea554000 GPR04: c000000fe123f140 0000000000000000 c000000fe2c6c000 c000000fff528050 GPR08: 0000000ffea30000 c000000fee70e000 0000000000000000 d00000000ba58d80 GPR12: d00000000b3bff20 c00000000fb92000 0000000020000000 c000000fe123fdec GPR16: c000000fe8f60000 c0000000008552c0 00000000000011d9 d00000000baf0000 GPR20: d00000000baf0000 c00000000017de10 0000000000000000 0000000000000124 GPR24: c000000fe2c6a000 c000000fe23df100 d00000000bab1640 d00000000bab1e48 GPR28: c000000fe8f61b70 c000000fe8f61b70 0000000000000000 c000000fe123f140 [ 1298.918345] NIP [d00000000b3bff68] drm_pcie_get_speed_cap_mask+0x48/0x150 [drm] [ 1298.918376] LR [d00000000ba30c88] ci_dpm_init+0xa8/0x13b0 [radeon] [ 1298.918379] Call Trace: [ 1298.918383] [c000000fe123f060] [c000000fe123f0e0] 0xc000000fe123f0e0 (unreliable) [ 1298.918413] [c000000fe123f0e0] [d00000000ba30c88] ci_dpm_init+0xa8/0x13b0 [radeon] [ 1298.918445] [c000000fe123f1f0] [d00000000b981a58] radeon_pm_init+0x628/0x910 [radeon] [ 1298.918480] [c000000fe123f290] [d00000000b9e0f84] cik_init+0x324/0x790 [radeon] [ 1298.918509] [c000000fe123f300] [d00000000b8f2c38] radeon_device_init+0x5a8/0xc70 [radeon] [ 1298.918539] [c000000fe123f390] [d00000000b8f6014] radeon_driver_load_kms+0xc4/0x280 [radeon] [ 1298.918548] [c000000fe123f410] [d00000000b3be15c] drm_dev_register+0xfc/0x140 [drm] [ 1298.918555] [c000000fe123f450] [d00000000b3c0798] drm_get_pci_dev+0xf8/0x220 [drm] [ 1298.918574] [c000000fe123f4e0] [d00000000b8f0664] radeon_pci_probe+0x134/0x1b0 [radeon] [ 1298.918580] [c000000fe123f570] [c00000000050471c] local_pci_probe+0x6c/0x140 [ 1298.918583] [c000000fe123f600] [c0000000005055a8] pci_device_probe+0x168/0x200 [ 1298.918588] [c000000fe123f660] [c0000000005b4900] driver_probe_device+0x240/0x550 [ 1298.918591] [c000000fe123f6f0] [c0000000005b4d7c] __driver_attach+0x16c/0x170 [ 1298.918595] [c000000fe123f770] [c0000000005b100c] bus_for_each_dev+0x9c/0x110 [ 1298.918598] [c000000fe123f7c0] [c0000000005b3b5c] driver_attach+0x3c/0x60 [ 1298.918626] [c000000fe123f7f0] [c0000000005b33a8] bus_add_driver+0x308/0x390 [ 1298.918630] [c000000fe123f880] [c0000000005b5d1c] driver_register+0x9c/0x180 [ 1298.918633] [c000000fe123f8f0] [c0000000005038dc] __pci_register_driver+0x6c/0x90 [ 1298.918640] [c000000fe123f930] [d00000000b3c0a24] drm_pci_init+0x164/0x1b0 [drm] [ 1298.918659] [c000000fe123f9c0] [d00000000ba53440] radeon_init+0xc8/0xf8 [radeon] [ 1298.918663] [c000000fe123fa30] [c00000000000b74c] do_one_initcall+0x6c/0x1d0 [ 1298.918667] [c000000fe123faf0] [c000000000822b50] do_init_module+0x94/0x254 [ 1298.918671] [c000000fe123fb80] [c0000000001821b0] load_module+0x2380/0x2b30 [ 1298.918674] [c000000fe123fd30] [c000000000182ca0] SyS_finit_module+0xf0/0x170 [ 1298.918678] [c000000fe123fe30] [c000000000009560] system_call+0x38/0x108 [ 1298.918680] Instruction dump: [ 1298.918682] f821ff81 7c7e1b78 7c9f2378 48000008 e8410018 39200000 913f0000 e93e01e8 [ 1298.918688] 2fa90000 41de0044 e9290010 ebc90038 <a13e003c> 2b891106 419e0030 2b891166 [ 1298.918696] ---[ end trace 6c565dbe73743fb5 ]--- Setting dpm=0 allows the radeon driver to load normally and the card functions as expected under Xorg. -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 98410] Applications crash when exiting
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=98410 Bug ID: 98410 Summary: Applications crash when exiting Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: cismalescumlord(a)programmer.net closing various applications leads to a crash. A couple of examples below. I set DRI_PRIME=1 as that uses the Radeon card and not the Intel. My laptop runs faster, cooler and quieter when I use this. Setting DRI_PRIME=0 does prevent the crashes. Firefox, Thunderbird and PyCharm all run and close just fine with DRI_PRIME=1. kate No docs r (or the only) opened right now --> disable menu radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000000800000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x800000 radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000000800000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x800000 radeonsi: Failed to create a context. No docs r (or the only) opened right now --> disable menu We got some errors while running testparm "Load smb config files from /etc/samba/smb.conf\nLoaded services file OK.\nWARNING: The 'netbios name' is too long (max. 15 chars).\n\n" 0x1f61ce0 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. KCrash: Application 'kate' crashing... konsole radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000000800000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x800000 radeon: Failed to allocate virtual address for buffer: radeon: size : 65536 bytes radeon: alignment : 4096 bytes radeon: domains : 4 radeon: va : 0x0000000000800000 radeon: Failed to deallocate virtual address for buffer: radeon: size : 65536 bytes radeon: va : 0x800000 radeonsi: Failed to create a context. KCrash: Application 'konsole' crashing... This works fine with Kernel 4.7 $ kate No docs r (or the only) opened right now --> disable menu No docs r (or the only) opened right now --> disable menu We got some errors while running testparm "Load smb config files from /etc/samba/smb.conf\nLoaded services file OK.\nWARNING: The 'netbios name' is too long (max. 15 chars).\n\n" 0x1515460 deleted without having been removed from the factory first. This will leak standalone popupmenus and could lead to crashes. $ uname -a Linux andromeda-ascendant 4.7.6-1-default #1 SMP PREEMPT Fri Sep 30 12:22:14 UTC 2016 (fb37fcc) x86_64 x86_64 x86_64 GNU/Linux -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 97896] RADEON DisplayPort - Monitor shows out of range in some modes
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97896 Bug ID: 97896 Summary: RADEON DisplayPort - Monitor shows out of range in some modes Product: DRI Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: jan.burgmeier(a)unicon-software.com Created attachment 126733 --> https://bugs.freedesktop.org/attachment.cgi?id=126733&action=edit dmesg output with drm.debug=0x1e log_buf_len=1M Hi, I have two monitors connected to my PC one via DVI and one via DP. The monitor connected via DP shows "frequency out of range" when some modes including the preferred one are used. This happens in X and in the KMS framebuffer. For example on the attached logs the preferred mode of 1680x1050 does not work where as 1680x945 works perfectly fine. Kernel: 4.4.11 Xorg: 1.18.2 xf86-video-radeon: 7.7.0 Last working kernel: 3.19 First broken kernel: 4.0 Here is the bisect info, the 4.0 release segfaulted in the radeon driver but the change which broke this was before so I hope the bisect is right: # first bad commit: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio After finding the bad commit I tried booting with radeon.audio=0 this made the display work for 3.19 kernel with that commit but did not work for the 4.4.11 kernel. Attached log files: - dmesg output with drm.debug=0x1e log_buf_len=1M - lspci -vv output - video card bios - Xorg.0.log - xrander --verbose output -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 97856] Computer restart playing 3D games (possibly overheating)
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97856 Bug ID: 97856 Summary: Computer restart playing 3D games (possibly overheating) 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: tukkek(a)gmail.com Hello, sorry if I'm reporting this to the wrong product but the bug report procedures on the wiki are pretty hard to understand https://www.x.org/wiki/RadeonFeature/#index11h2 I have an onboard Radeon HD 3000 (ATI RS780L). I am primarily using Debian testing ("stretch"). I believe the open source drivers for it are providade by the following packages: linux-image-4.6.0-1-amd64 (4.6.4-1, radeon.ko) xserver-xorg-video-ati (1:7.7.0-1) xserver-xorg-video-radeon (1:7.7.0-1, radeon_drv.so, due to update in a few days) The problem I'm having is that when playing 3D games the computer will randomly crash and reboot after anywhere from 10 minutes into the game, to over an hour of gameplay without rebooting (mostly around 10-30 minutes with a crash). It seems to be heat-related because when it's cooler it seems the game has less chance of crashing and when a crash happens and I try playing again after the reboot is complete, the crash seems to happen more rapidly - maybe after 5 minutes or so playing. The crash seems to be some sort of hardware failure because there are no trace in the journald persistent logs that I can find. For this, I can't also be sure what is happening. Let me know if there is something I can do to help debug this. To verity if the error was the driver's fault I installed a new Debian system (oldstable, Debian 7 "wheezy"), which allowed me to install the fglrx legacy driver with Radeon HD 3000 support. In this new system I haven't experienced a single reboot so far - which establishes the cause isn't hardware-only related but very likely a driver issue. Being an entirely new system means it could be something else too but since I have very frequent crashes/reboots in my primary system and none so far in the alternate system while running games for an hour or so frequently on a hot day, would indicate that the fault is indeed coming from the Radeon open-source criver. I haven't done any 3D gaming in this computer before a couple of weeks from now so I can't say that this bug only happens on recent driver versions or not. Watching videos in a browser or in a video application (such as VLC) and 2D games like http://littlewargame.com or rendering videos (via kdenlive or such) do not cause reboots, even though they can be relatively heavy on the GPU. I haven't had any random crashes in a very long while as well except when doing 3D gaming. I've installed a few games to test it out and whenever 3D gaming the crashes do happen frequently. Some of the games I've used to test this are Heroes of Newerth and Runescape (both free to download and play) and very lightweigth in the low settings, so it shouldn't be a quesiton of me stressing the card too much either (HoN for example works fine with the fglrx legacy driver on my alternate system). I have run memtest86, CPU and memory stress (stress-ng 0.06.15-1) in the hopes of catching a spike in my machine's temperature as the culprit for these random crashes but I've found the temperature to be stable and low even during heavy load for a long time. I've ran the Geeks3D GpuTest, which puts a heavier load than these games on the graphics card but haven't been able to cause a crash, even though in this case my tests haven't been extensible - I can run them for longer though if it would help debug the issue. I undestand that there have been recent updates on the graphics drivers on the new Linux kernel update. I will try the new drivers as they come out since it's somewhat of a bother having to reboot the computer (and maintain a legacy system) whenever I want to play 3D games and if the problem is solved I'll report back here. If I don't comment on this issue in the near future it's because the problem persists even with the new drivers. My guess about what is happening: since the problem seems to be heat-related maybe there is some sort of temperature sensor that the open source driver isn't able to read on my card - which I was expecting to be able to see using lmsensors (version 1:3.4.0-3) while maybe the fglrx is able to read and handle heat properly. I don't usually report bugs to trackers that already have many reports open but since I've spent a long time in tracking this issue and was able to fix it, I thought that I should share all the information I've gathered in the hope it's useful. It's an older, onboard graphics card model, probably getting to the end of its lifespan soon but I hope this report is valuable in some way, anyway. Thank you for the good work on these open drivers. If I were able to use them on my primary system I'd certainly do it, even if the fglrx legacy system is a little bit smoother, since it would be a lot more convenient than maitaning a separare gaming system in my machine. Thanks again for the contributions to the FOSS community and for the time reading this report! -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 97838] Hang on resume [AMD/ATI] RV515/M54 [Mobility Radeon X1400]
by bugzilla-daemon＠freedesktop.org 19 Nov '19

19 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97838 Bug ID: 97838 Summary: Hang on resume [AMD/ATI] RV515/M54 [Mobility Radeon X1400] Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: mar.kolya(a)gmail.com I've got Dell Inspiron 6400 with Ubuntu 16.04, oibaf drivers and kernel 4.7.3. The box doesn't seem to be able to come out of STR - it just hangs with black screen. I've tried 'echo devices > /sys/power/pm_test; echo mem > /sys/power/state' and on resume I often get to see my desktop but then box completely freezes - no keyboard, no mouse, no net. I've tried suspending/resumeing in console mode and could not reproduce this problem. On previous Ubuntu kernels (stock) it hangs often, but sometimes it is able to resume, in 4.7.3 it seems to be handging close to 100% percent of the time. Unfortunately I'm not really able to get any debug logs since box gets totally frozen. Is there any way I can provide any more information or debug this? Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 3

[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

← Newer
1
...
4
5
6
7
8
9
10
...
153
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2017