dri-devel October 2016

dri-devel@lists.freedesktop.org

215 participants
1390 discussions

[Bug 97157] MST displays fail to wake
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=97157 Bug ID: 97157 Summary: MST displays fail to wake 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: dan.doel(a)gmail.com Created attachment 125450 --> https://bugs.freedesktop.org/attachment.cgi?id=125450&action=edit dmesg output Since moving to kernel 4.6, I've been having regular problems with my MST monitors failing to wake after being put to sleep. This only seems to occur after the machine has been on for a sufficient amount of time, but I usually experience it within a day of booting, and typically after the displays have been powered off for an extended period of time. There are two MST monitors, but typically only one fails to wake. Also, it is more often that the secondary display is the one that fails. However, I have had the primary display fail to come back (while the secondary one succeeds), and I have had both fail to come back as well. Sometimes, only a complete power off is able to make the monitors wake up; a reboot is not always sufficient. The dmesg displays some errors, and I've poked around a bit. It seems likely that this is related to commit f3d58dccdbf9f8c0a229d555d4b295d52e743039, which was first included in 4.6. This commit basically causes dpms to work at all with MST monitors; before it was a no-op that didn't actually put the monitors into power saving. That doesn't help narrow the problem down much, though, since a significant portion of the mst dpms code probably wasn't being exercised before that. Also, it seems notable that the error message (which seems more like a debug message) in the STANDBY/SUSPEND/OFF case keeps reporting higher numbers, as though it keeps going through the ON case, which increments the variable, but not making it through the portion of the OFF case that decrements the variable. I'll attach dmesg journal output that might be relevant. I believe the error/debug messages timestamped 'Jul 31 11:03:49' correspond to the first time one of the displays failed to wake up. I tried various ways of toggling the dpms off and on after that, so those are the subsequent error messages in the log. As far as specs go, I have: Radeon HD7870 (Pitcairn) Kernel 4.6.4 (4.6.3 also affected) 2 UP2414Q mst displays xorg-server 1.18.4 Modesetting driver Let me know if there's any more information I can try to provide. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 94153] Unresponsive system on boot with radeon + HD 3870
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=94153 Bug ID: 94153 Summary: Unresponsive system on boot with radeon + HD 3870 Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: blocker Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: g47qk(a)ukr.net Created attachment 121755 --> https://bugs.freedesktop.org/attachment.cgi?id=121755&action=edit dmesg.log saved via the serial port I'm using a HD 3870 with Debian 9 Stretch x64 (Testing). When booting to a command line, when drivers are loaded, the screen goes into power saving mode, and the system becomes unresponsive. Booting with `nomodeset' works OK. If I run "#modprobe radeon modeset=1", the screen goes power saving mode, the system stops responding and the caps lock key no longer works (kernel panic?). I've also tested with a Fedora 23 Workstation Live-CD (64-bit), Ubuntu 15.10 Desktop (64-bit) Live-CD, SystemRescueCd-x86-4.7.0 with the same results (unresponsive on driver load). I've tested a ATI X1600 Pro in the same system, and everything works fine. #lspci -nnn | grep VGA 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV670 [Radeon HD 3870] [1002:9501] -- You are receiving this mail because: You are the assignee for the bug.

1 13

[Bug 89971] HDMI out *not* working with radeon (mobile 8550g)
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=89971 Bug ID: 89971 Summary: HDMI out *not* working with radeon (mobile 8550g) Product: DRI Version: DRI 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: adrianovidiugabor(a)gmail.com Created attachment 114999 --> https://bugs.freedesktop.org/attachment.cgi?id=114999&action=edit screen's content Hi all. If I'm connecting my laptop's HDMI out to my TV I get a black screen with garbage on top (see attached pic). This is with mirror mode on. If making the second screen primary, the pc blocks and I have to restart it. It won't unblock even if I disconnect the cable. If switching to one of the virtual consoles, everything works correctly as it should, so the problem seems to be related somehow to the display server. The Tv is recognized correctly by xrandr. Specs: Asus laptop, with AMD A8-5550M, Radeon 8550G(Aruba)/8670M(Hainan), OS ArchLinux(x64) Xorg-xerver 1.17, kernel 3.19.3, Mesa-git, xf86-ati-git, llvm-svn. This doesn't seem to be a regression (experienced it with older versions of the kernel and userspace components) and it's reproducible on another machine. HDMI out works on Windows and ChromeOS. Didn't try Catalyst on Linux. -- You are receiving this mail because: You are the assignee for the bug.

1 15

[Bug 80531] New: 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750]
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=80531 Priority: medium Bug ID: 80531 Assignee: dri-devel(a)lists.freedesktop.org Summary: 3.16-rc2 hdmi output resolution out of range Cape Verde PRO [Radeon HD 7750] Severity: normal Classification: Unclassified OS: Linux (All) Reporter: fredrik(a)obra.se Hardware: x86-64 (AMD64) Status: NEW Version: XOrg CVS Component: DRM/Radeon Product: DRI Created attachment 101759 --> https://bugs.freedesktop.org/attachment.cgi?id=101759&action=edit dmesg with drm.debug=1 With 3.16-rc2 my tripple screen setup breaks. DisplayPort-0 connected 1920x1200 <- ok HDMI-0 connected 1920x1080 <- (tv) resolution out of range DVI-0 connected 1680x1050 <- ok All screens work during bootup before X starts. ddx driver 7.3.0. -- You are receiving this mail because: You are the assignee for the bug.

1 14

[Bug 75992] New: Display freezes & corruption with an r7 260x on 3.14-rc6
by bugzilla-daemon＠freedesktop.org 20 Nov '19

20 Nov '19

https://bugs.freedesktop.org/show_bug.cgi?id=75992 Priority: medium Bug ID: 75992 Assignee: dri-devel(a)lists.freedesktop.org Summary: Display freezes & corruption with an r7 260x on 3.14-rc6 Severity: major Classification: Unclassified OS: Linux (All) Reporter: edt(a)aei.ca Hardware: x86-64 (AMD64) Status: NEW Version: unspecified Component: DRM/Radeon Product: DRI Created attachment 95520 --> https://bugs.freedesktop.org/attachment.cgi?id=95520&action=edit log of boot I recently added a R7 260X to my system. While the card works with 3.13 its supposed work much better with 14-rc. This is not the case. My system is unstable without radeon.dpm=0 which was the default in .13. linux 3.14-rc6 (with an up to date arch, stable X and mesa-git (10.2) mesa 10.1 and 10.0 also show very similar problems. When X started I did notice some corruption. There are sets of two rectangles about of a height of 2 or 3 mm, width of 25m or so with a second about a cm below. The often occurs in chomium especially when scrolling. Runing the unigine-sanctuary or unigine-tropics demo/benchmark programs also produce the above problems and eventually stall. -- You are receiving this mail because: You are the assignee for the bug.

1 61

[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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel October 2016