[Bug 117171] New: Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 Bug ID: 117171 Summary: Radeon GPU lockup in X windows after resuming from blank screen Product: Drivers Version: 2.5 Kernel Version: 4.6 rc5 from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5 -wily/ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: erik.brangs at gmx.de Regression: No Created attachment 213991 --> https://bugzilla.kernel.org/attachment.cgi?id=213991&action=edit dmesg output acquired from frozen system with GPU lockup I'm using Ubuntu 16.04 with the 4.6 rc5 kernel build from http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc5-wily/ . AFAIK this is a mainline kernel with an Ubuntu configuration. Sometimes, when I'm using X windows and resuming from a blank screen, X windows freezes: The previous screen content is properly restored but X windows locks up and ceases to process inputs. The system isn't completely frozen, though: I can still SSH into it. In this case, the dmesg log doesn't have any message about the lockup at the end and the of the Xorg log only has entries about mieq overflowing. This behaviour has been present as long as I have actually tried to get some debugging output. At other times, I can still attempt to switch to the terminal. In that case, the system locks up after the X windows screen content has been removed but before the terminal is shown, e.g. the screen content consists of a single colour. In that case, the tail of the dmesg output contained some lines about GPU lockup: [ 9553.364081] radeon :01:00.0: ring 0 stalled for more than 10440msec [ 9553.364093] radeon :01:00.0: GPU lockup (current fence id 0x9b9e last fence id 0x9b9f on ring 0) [ 9553.368211] radeon :01:00.0: Saved 215675 dwords of commands on ring 0. [ 9553.369258] radeon :01:00.0: GPU reset succeeded, trying to resume [ 9553.369272] radeon :01:00.0: 880035298800 unpin not necessary [ 9553.385589] [drm] radeon: 1 quad pipes, 1 z pipes initialized. [ 9553.386659] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 9553.38] radeon :01:00.0: WB enabled [ 9553.386672] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x0800 and cpu addr 0x880034dee000 [ 9553.386721] [drm] radeon: ring at 0x08001000 [ 9553.941187] [drm:r100_ring_test [radeon]] *ERROR* radeon: ring test failed (scratch(0x15E8)=0xCAFEDEAD) [ 9553.941220] [drm:r100_cp_init [radeon]] *ERROR* radeon: cp isn't working (-22). [ 9553.941224] radeon :01:00.0: failed initializing CP (-22). I don't think that this is a regression because I haven seen freezes like this for a long time (since before the 4.x series). The basic problem (i.e. lockup of X windows) hasn't changed in that time. The frequency of occurence and the timing of the lockup seem to vary based on the kernel version. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 --- Comment #1 from erik.brangs at gmx.de --- Created attachment 214001 --> https://bugzilla.kernel.org/attachment.cgi?id=214001&action=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 --- Comment #2 from erik.brangs at gmx.de --- Created attachment 214011 --> https://bugzilla.kernel.org/attachment.cgi?id=214011&action=edit glxinfo from working system -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #6 from Alex Deucher --- Your system is muxless so there is no mux to switch. The displays are only connected to the IGP. You need to use the xserver PRIME stuff to render with the dGPU. The dGPU renders offscreen and then the result is copied to the IGP for display. See: https://wiki.archlinux.org/index.php/PRIME -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117111] Quitting X with xrandr rotation enabled freezes vt
https://bugzilla.kernel.org/show_bug.cgi?id=117111 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117111] Quitting X with xrandr rotation enabled freezes vt
https://bugzilla.kernel.org/show_bug.cgi?id=117111
MichaÅ Pecio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from MichaÅ Pecio ---
OK, so I checked Xorg log and it's missing the final line indicating clean
shutdown. strace revealed that X is aborting for some reason:
<... futex resumed> ) = 0
ioctl(12, DRM_IOCTL_GEM_CLOSE, 0x7ffdfee3d4e0) = 0
close(12) = 0
close(11) = 0
munmap(0x7f1fa4a69000, 13890560)= 0
munmap(0x7f1fa5bef000, 2126232) = 0
munmap(0x7f1fa4861000, 2126248) = 0
munmap(0x7f1fa4649000, 2191808) = 0
write(2, "Xorg: ../include/privates.h:122:"..., 89) = 89
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f1fad47c000
rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0
tgkill(2858, 2858, SIGABRT) = 0
--- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=2858, si_uid=1000} ---
+++ killed by SIGABRT +++
So much for a kernel bug, I guess.
--
You are receiving this mail because:
You are watching the assignee of the bug.
[Bug 117181] New: graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 Bug ID: 117181 Summary: graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake Product: Drivers Version: 2.5 Kernel Version: 4.5.2 Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: yves.dufournaud at gmail.com Regression: No I am on an Asus UX305UA-FC057T - Intel Core i7-6500U - Intel HD Graphics 5500 when using kernel above > 4.2, I observe punctual screen glitch similar to those seen on image linked. This happens through the usage of cinamon (3d) on linux mint. But still I do use version 4.5.2 compiled by myself. uname -a Linux yves-asus 4.5.2 #2 SMP Sun Apr 24 20:17:09 CEST 2016 x86_64 x86_64 x86_64 GNU/Linux The glitch happens only with new kernel, previous kernel like 4.2.xxx are working fine for display with same system (they have othere issues). And seems (as a user point of view) be linked to a certain pattern: menu compositing + mouse hovering. Image showing the issue https://forums.linuxmint.com/download/file.php?id=26842&sid=ae05af439953d8fac51a9658d2eba0c1&mode=view it's flickering: so the screen is scrambled, and then normal Thank you for your time, Yves -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #7 from Jason Vas Dias --- (In reply to Alex Deucher from comment #6) > Your system is muxless so there is no mux to switch. The displays are only > connected to the IGP. You need to use the xserver PRIME stuff to render > with the dGPU. The dGPU renders offscreen and then the result is copied to > the IGP for display. See: > https://wiki.archlinux.org/index.php/PRIME Thanks for the info, Alex . But that page seems mainly to be a reference for xrandr usage, which as I understand it works only with a running X-server , which I do not have : $ unset DISPLAY; xrandr --listproviders Can't open display $ I am trying to get the X-server running, which it refuses to do because it cannot probe for display modes, and seemingly cannot be configured not to do so without major reworking. The modes cannot be determined because it seems the card is not in the fully 'powered on' state , and because whenever I attempt to switch into graphics mode, the radeon driver fails to execute this ACPI callout : [ 474.269102] ACPI Error: No handler for Region [EC81] (88041d8d9bd0) [EmbeddedControl] (20160108/evregion-166) [ 474.269724] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160108/exfldio-299) [ 474.270325] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP.SGOF] (Node 88041d8fca50), AE_NOT_EXIST (20160108/psparse-542) [ 474.270940] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP._OFF] (Node 88041d8fce88), AE_NOT_EXIST (20160108/psparse-542) [ 474.271548] ACPI Error: Method parse/execution failed [\_SB.PCI0.GFX0.ATPX] (Node 88041d9034b0), AE_NOT_EXIST (20160108/psparse-542) [ 474.272164] failed to evaluate ATPX got AE_NOT_EXIST I think the Linux radeon driver needs to be fixed to make the ACPI calls correctly - if anyone can please decode what it is trying to do by invoking this ACPI method, please let me know . If you or anyone could please suggest how to start the X-server with the xf86-video-ati driver controlling the Radeon Card, as it claims to be able to do, I'd be most appreciative of any tips . My xorg.conf as shown above was largely copied from the https://wiki.archlinux.org/index.php/PRIME page, and still does not work to enable me to start the X-server - the X-server cannot determine the display modes of the card and will not allow the modes to be specified in any other way - I guess I'll have to hack it to forget trying to determine the modes and use a hard-coded mode table. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #8 from Jason Vas Dias --- As stated on the web-page quoted above , ( https://wiki.archlinux.org/index.php/PRIME ) an example xorg.conf to use the discrete card as primary GPU is: # Discrete Card as Primary GPU Section "ServerLayout" Identifier "layout" Screen 0 "nouveau" Inactive "intel" EndSection Section "Device" Identifier "nouveau" Driver "nouveau" BusID "PCI:x:x:x" # Sample: "PCI:1:0:0" EndSection Section "Screen" Identifier "nouveau" Device "nouveau" EndSection Section "Device" Identifier "intel" Driver "intel" BusID "PCI:x:x:x" # Sample: "PCI:0:2:0" EndSection Section "Screen" Identifier "intel" Device "intel" EndSection My xorg.conf is basically the same with the string 'nouveau' replaced by 'ati' . It started out as simple as this, but then grew as I tried every conceivable method to specify the modes , but still the X-server exits with a 'No modes.' error in every case . The reason the X-server cannot determine the modes is because of this Linux bug - the radeon DRM driver makes incorrect ACPI calls. Also I think that if vga_switcheroo does not work or is incapable of working , as it provably is in the above example, it should return EIO on the write to the debugfs control 'switch' file , and not proceed to display spurious data in that file. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #9 from Alex Deucher --- (In reply to Jason Vas Dias from comment #8) > As stated on the web-page quoted above , > ( https://wiki.archlinux.org/index.php/PRIME ) > an example xorg.conf to use the discrete card > as primary GPU is: > This is only possible if there are displays physically connected to the dGPU (e.g., laptop panel is connected to IGP and HDMI is connected to dGPU). I'd need to see your full dmesg output, but I suspect there are no displays physically connected to the dGPU on your system. As such, there is no way to make it the primary. > > > My xorg.conf is basically the same with the string 'nouveau' > replaced by 'ati' . > > It started out as simple as this, but then grew as I tried > every conceivable method to specify the modes , but still > the X-server exits with a 'No modes.' error in every case . > > The reason the X-server cannot determine the modes is because > of this Linux bug - the radeon DRM driver makes incorrect ACPI > calls. No. There are no displays or display connectors actually wired to the dGPU. This is what is called a mux-less laptop. mux-less in that there is no mux to switch the display connections between the IGP and the dGPU. > > Also I think that if vga_switcheroo does not work or is > incapable of working , as it provably is in the above > example, it should return EIO on the write to the > debugfs control 'switch' file , and not proceed to > display spurious data in that file. vag-switcheroo should only be used on old muxed laptops where there was a mux to switch the display routing. As I said, the only way to use the dGPU on your system is to follow the "PRIME GPU offloading" section of that page. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #10 from Jason Vas Dias --- OK, fine, I have to use FGLRX to use the Radeon as the primary display as I do under OEL7 (Linux 3.10) - what a terrific new open source radeon driver Linux 4.5 has. But I cannot even get the Intel card to go into graphics mode under Linux 4.5.0, owing to the failure of the radeon module to call that ACPI method . My xorg.conf now has no references to radeon driver : Section "ServerLayout" Identifier "X Radeon" Screen 0 "Screen0" 0 0 InputDevice"Mouse0" "CorePointer" InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "Files" ModulePath "/usr/lib64/xorg/modules" FontPath "/usr/share/fonts/X11/misc/" FontPath "/usr/share/fonts/X11/TTF/" FontPath "/usr/share/fonts/X11/OTF/" FontPath "/usr/share/fonts/X11/Type1/" FontPath "/usr/share/fonts/X11/100dpi/" FontPath "/usr/share/fonts/X11/75dpi/" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "evdev" EndSection Section "InputDevice" Identifier "Mouse0" Driver "synaptics" Option "Protocol" "auto" Option "Device" "/dev/input/mice" EndSection Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName"Monitor Model" Option "DPMS" "true" EndSection Section "Device" Identifier "Intel" Screen 0 Driver "intel" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Intel" Monitor"Monitor0" SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection Now, I boot only with the 'i915.modeset=1' kernel boot parameter . I do : $ dmesg -c >/var/log/dmesg-4.5.0.boot.log # available on request $ export DISPLAY=:0 $ Xorg -logverbose 7 :0 vt04 & (sleep 2; xterm &) Now the X-server gets a segmentation violation in the xf86-video-intel driver, and the following dmesgs are generated : $ dmesg [ 121.166547] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e [ 121.167141] [drm] PCIE gen 3 link speeds already enabled [ 121.171391] [drm] PCIE GART of 2048M enabled (table at 0x002E8000). [ 121.172068] radeon :01:00.0: WB enabled [ 121.172638] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x880414eb5c00 [ 121.173232] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x880414eb5c04 [ 121.173821] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x880414eb5c08 [ 121.174409] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x880414eb5c0c [ 121.174990] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x880414eb5c10 [ 121.175941] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc9435a18 [ 121.196617] radeon :01:00.0: fence driver on ring 6 use gpu addr 0x00010c18 and cpu addr 0x880414eb5c18 [ 121.197169] radeon :01:00.0: fence driver on ring 7 use gpu addr 0x00010c1c and cpu addr 0x880414eb5c1c [ 121.344986] [drm] ring test on 0 succeeded in 2 usecs [ 121.345536] [drm] ring test on 1 succeeded in 1 usecs [ 121.346090] [drm] ring test on 2 succeeded in 1 usecs [ 121.346659] [drm] ring test on 3 succeeded in 4 usecs [ 121.347202] [drm] ring test on 4 succeeded in 2 usecs [ 121.524819] [drm] ring test on 5 succeeded in 2 usecs [ 121.525345] [drm] UVD initialized successfully. [ 121.635907] [drm] ring test on 6 succeeded in 13 usecs [ 121.636449] [drm] ring test on 7 succeeded in 4 usecs [ 121.636978] [drm] VCE initialized successfully. [ 121.637570] f 0#2: signaled from fence_wait [ 121.638109] [drm] ib test on ring 0 succeeded in 0 usecs [ 121.638641] f 1#2: signaled from fence_wait [ 121.639152] [drm] ib test on ring 1 succeeded in 0 usecs [ 121.639722] f 2#2: signaled from fence_wait [ 121.640233] [drm] ib test on ring 2 succeeded in 0 usecs [ 121.640801] f 3#2: signaled from fence_wait [ 121.641313] [drm] ib test on ring 3 succeeded in 0 usecs [ 121.641878] f 4#2: signaled from fence_wait [ 121.642404] [drm] ib test on ring 4 succeeded in 0 usecs [ 122.295105] f 5#4: signaled from fence_wait [ 122.295672] [drm] ib test on ring 5 succeeded [ 122.797067] f 6#4: signaled from fence_wait [ 122.797648] [drm] ib test on ring 6 succeeded [ 123.299048] f 7#4: signaled from fence_wait [ 123.299662] [drm] ib test on ring 7 succeeded [ 123.387817] device: 'vcs4': device_add [ 123.387832] PM: Adding info for No Bus:vcs4 [ 123.387875] device: 'vcsa4': device_add [ 123.387893] PM: Adding info for
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #11 from Alex Deucher --- (In reply to Jason Vas Dias from comment #10) > OK, fine, I have to use FGLRX to use the Radeon as the primary display > as I do under OEL7 (Linux 3.10) - > what a terrific new open source radeon driver Linux 4.5 has. fglrx still uses the intel card for display, it just hacks a bunch of stuff under the covers rather than using the PRIME infrastructure. > > But I cannot even get the Intel card to go into graphics mode under Linux > 4.5.0, > owing to the failure of the radeon module to call that ACPI method . > > My xorg.conf now has no references to radeon driver : > Please remove your xorg config completely. You shouldn't need one, and some older xservers didn't properly handle multi-GPU with one in place. > > > Now, I boot only with the 'i915.modeset=1' kernel boot parameter . > > I do : > > $ dmesg -c >/var/log/dmesg-4.5.0.boot.log # available on request > $ export DISPLAY=:0 > $ Xorg -logverbose 7 :0 vt04 & (sleep 2; xterm &) > > Now the X-server gets a segmentation violation in the xf86-video-intel > driver, > and the following dmesgs are generated : > > $ dmesg > [ 121.166547] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e > [ 121.167141] [drm] PCIE gen 3 link speeds already enabled > [ 121.171391] [drm] PCIE GART of 2048M enabled (table at > 0x002E8000). > [ 121.172068] radeon :01:00.0: WB enabled > [ 121.172638] radeon :01:00.0: fence driver on ring 0 use gpu addr > 0x00010c00 and cpu addr 0x880414eb5c00 > [ 121.173232] radeon :01:00.0: fence driver on ring 1 use gpu addr > 0x00010c04 and cpu addr 0x880414eb5c04 > [ 121.173821] radeon :01:00.0: fence driver on ring 2 use gpu addr > 0x00010c08 and cpu addr 0x880414eb5c08 > [ 121.174409] radeon :01:00.0: fence driver on ring 3 use gpu addr > 0x00010c0c and cpu addr 0x880414eb5c0c > [ 121.174990] radeon :01:00.0: fence driver on ring 4 use gpu addr > 0x00010c10 and cpu addr 0x880414eb5c10 > [ 121.175941] radeon :01:00.0: fence driver on ring 5 use gpu addr > 0x00075a18 and cpu addr 0xc9435a18 > [ 121.196617] radeon :01:00.0: fence driver on ring 6 use gpu addr > 0x00010c18 and cpu addr 0x880414eb5c18 > [ 121.197169] radeon :01:00.0: fence driver on ring 7 use gpu addr > 0x00010c1c and cpu addr 0x880414eb5c1c > [ 121.344986] [drm] ring test on 0 succeeded in 2 usecs > [ 121.345536] [drm] ring test on 1 succeeded in 1 usecs > [ 121.346090] [drm] ring test on 2 succeeded in 1 usecs > [ 121.346659] [drm] ring test on 3 succeeded in 4 usecs > [ 121.347202] [drm] ring test on 4 succeeded in 2 usecs > [ 121.524819] [drm] ring test on 5 succeeded in 2 usecs > [ 121.525345] [drm] UVD initialized successfully. > [ 121.635907] [drm] ring test on 6 succeeded in 13 usecs > [ 121.636449] [drm] ring test on 7 succeeded in 4 usecs > [ 121.636978] [drm] VCE initialized successfully. > [ 121.637570] f 0#2: signaled from fence_wait > [ 121.638109] [drm] ib test on ring 0 succeeded in 0 usecs > [ 121.638641] f 1#2: signaled from fence_wait > [ 121.639152] [drm] ib test on ring 1 succeeded in 0 usecs > [ 121.639722] f 2#2: signaled from fence_wait > [ 121.640233] [drm] ib test on ring 2 succeeded in 0 usecs > [ 121.640801] f 3#2: signaled from fence_wait > [ 121.641313] [drm] ib test on ring 3 succeeded in 0 usecs > [ 121.641878] f 4#2: signaled from fence_wait > [ 121.642404] [drm] ib test on ring 4 succeeded in 0 usecs > [ 122.295105] f 5#4: signaled from fence_wait > [ 122.295672] [drm] ib test on ring 5 succeeded > [ 122.797067] f 6#4: signaled from fence_wait > [ 122.797648] [drm] ib test on ring 6 succeeded > [ 123.299048] f 7#4: signaled from fence_wait > [ 123.299662] [drm] ib test on ring 7 succeeded > [ 123.387817] device: 'vcs4': device_add > [ 123.387832] PM: Adding info for No Bus:vcs4 > [ 123.387875] device: 'vcsa4': device_add > [ 123.387893] PM: Adding info for No Bus:vcsa4 > [ 123.400978] Xorg (4385) used greatest stack depth: 12016 bytes left > [ 129.273612] ACPI Error: No handler for Region [EC81] (88041d8d9bd0) > [EmbeddedControl] (20160108/evregion-166) > [ 129.274317] ACPI Error: Region EmbeddedControl (ID=3) has no handler > (20160108/exfldio-299) > [ 129.275027] ACPI Error: Method parse/execution failed > [\_SB.PCI0.PEG0.PEGP.SGOF] (Node 88041d8fca50), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.275779] ACPI Error: Method parse/execution failed > [\_SB.PCI0.PEG0.PEGP._OFF] (Node 88041d8fce88), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.276495] ACPI Error: Method parse/execution failed > [\_SB.PCI0.GFX0.ATPX] (Node 88041d9034b0), AE_NOT_EXIST > (20160108/psparse-542) > [ 129.277229] failed to evaluate ATPX got AE_NOT_EXIST > > It seems even when I specify Intel driver should be used, the Intel driver > is still hooking into
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #12 from Jason Vas Dias --- Created attachment 214151 --> https://bugzilla.kernel.org/attachment.cgi?id=214151&action=edit dmesg boot log Boot DMESG log as requested -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #13 from Jason Vas Dias --- Yes, radeon.runpm=0 has stopped the ACPI problem - but the latest Xorg xf86-video-intel driver ( 2.99.917 ) apparently does not work with the latest xorg server (1.18.3) and gets a segmentation violation on initialization - S.N.A.F.U . So, still no graphics mode under 4.5.0 until Xorg gets fixed or I can bother building each previous Xorg server to find one that works with the intel driver. So, please confirm: In order to use the Radeon 8970M at all, currently I have no choice but to run FGLRX closed source drivers and OpenGL user-space library stack, and the open-source radeon drivers (both kernel and Xorg) are of no use to me? There is no way I can use any open-source driver or OpenGL implementation to control the card for X-Windows display use ? Is there any xorg.conf that might potentially let me use the Radeon GPU for display on the laptop LCD without using FGLRX ? I can't see how any xorg.conf can load the Radeon driver for the card, since that driver cannot determine the display modes . I'll see about getting the 8970M card removed from my laptop so I can sell it on ebay - it is of no use to me in the computer. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #1 from yves.dufournaud at gmail.com --- there is another issue: resuming from suspend to ram is failing, I would have filled a separate bug, but apparently it can be linked to graphics. following the instruction here: https://01.org/linuxgraphics/documentation/development/how-debug-suspend-resume-issues S3 suspend (a.k.a Suspend To RAM): dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after the machine go to sleep : led blinking after pressing power button, make machine reboot. but dmesg_after exists with same content as dmesg_before, so quoting source: "If dmesg_after exists, it means that the system can be resumed from BIOS, so it's likely to be a graphics issue. Otherwise, it's not related to graphics and don't report it to freedesktop.org bugzilla." will try to set Enable "CONFIG_PM_DEBUG" for next test -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #14 from Alex Deucher --- It sounds like it's a bug in the intel driver. The radeon driver appears to be loading fine. Can you get any display on the intel card at all? You can blacklist the radeon driver (append modeprobe.blanklist=radeon to the kernel command line in grub) to get that out of the way. If you can't get any display on the intel card, I'd suggest updating the intel xorg driver or trying a different kernel to get a different intel kernel driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #15 from 3pb33h+1ymmkx54pslys at sharklasers.com --- Seems like alex made an typo i think it should be modprobe.blacklist=radeon -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #16 from Alex Deucher --- (In reply to 3pb33h+1ymmkx54pslys from comment #15) > Seems like alex made an typo i think it should be modprobe.blacklist=radeon Yes you are correct, sorry about that. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #2 from yves.dufournaud at gmail.com --- tested with CONFIG_PM_DEBUG with core/processors/device dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after machine resume after few second, but mouse pointer is lost (not visible/not acting) joined dmesg_after -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 --- Comment #3 from yves.dufournaud at gmail.com --- Created attachment 214301 --> https://bugzilla.kernel.org/attachment.cgi?id=214301&action=edit dmesg_after.txt output of dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #17 from Jason Vas Dias --- OK, I tried appending modprobe.blacklist=radeon to the kernel command line - that had no effect - the radeon module is built-in ; only using radeon.runpm=0 stops the ACPI error messages . RE: > I'd suggest updating the intel xorg driver or trying a different kernel > to get a different intel kernel driver. The intel xorg driver is at its latest GIT version : 2.99.917 as is the X-Server : 1.18.3 . I have raised Freedesktop.org bug # 95140 : https://bugs.freedesktop.org/show_bug.cgi?id=95140 about the failure of the latest version of the Xorg intel driver to work with the latest version of the Xorg X-server . What is the latest known version of Linux known to work with the Intel Integrated HD Graphics card ( PCI: 8086:0416 ) ? Are you sure that card is capable of driving the display on its own on my laptop? I have never been able to get the display into graphics mode using any other driver than FGLRX - all OS installers eg. anaconda / ARCH Linux also failed to even get it into VESA mode, forcing me to use the terminal dialog interface for configuration . I don't like using FGLRX because it forces me to use a distro that is 100% binary compatible with its OpenGL libraries and does not allow me to investigate OpenGL development with Mesa or to build my own libraries or to use the latest Linux kernel . It is a shame that it appears Linux has lost graphics capability in a large segment of the modern laptop market because of issues like this - it always used to work fine up until @ 2010 . -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 51381] [drm:atom_op_jump] *ERROR* atombios stuck in loop for more than 5secs aborting, when disabled via vgaswitcheroo
https://bugzilla.kernel.org/show_bug.cgi?id=51381 Peter Uchno changed: What|Removed |Added CC||peter.uchno at gmail.com --- Comment #41 from Peter Uchno --- I've started seeing this on a Dell Latitude E6540 with a Radeon 8790M and Intel hybrid graphics. I'm using vgaswitcheroo to disable the Radeon in Linux. I'm on Arch Linux, I wasn't seeing the problem in kernel 4.5.0 but I'm seeing it now in 4.5.1. The kernel spits out errors about the atombios being stuck in a loop and then fills dmesg with messages about "ring 3 stalled". After about a full minute of this, X starts on the Intel GPU and the system seems to run normally. The kernel continues to spit out error messages during operation. Adding radeon.runpm=0 to the kernel parameters results in a normal boot, where the driver starts up normally and X starts up much more quickly. I do see that a patch related to runtime PM (e64c952efb8e0c15ae82cec8e455ab4910690ef1) went into the kernel recently. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 116251] radeon 5a427809cd9143bef89ee3110f45e84f37484218 "drm/radeon: disable runtime pm on PX laptop" makes dGPU never stop
https://bugzilla.kernel.org/show_bug.cgi?id=116251 Kertesz Laszlo changed: What|Removed |Added CC||laszlo.kertesz at gmail.com --- Comment #6 from Kertesz Laszlo --- The issue is present on Dell Latitude E6540 (Debian Testing installed). 00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06) 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Mars XTX [Radeon HD 8790M] (rev ff) Some more discussions about this here: https://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/867738-kernel-4-5-radeon-runpm-not-working-properly-on-debian-testing -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 116251] radeon 5a427809cd9143bef89ee3110f45e84f37484218 "drm/radeon: disable runtime pm on PX laptop" makes dGPU never stop
https://bugzilla.kernel.org/show_bug.cgi?id=116251 --- Comment #7 from Alex Deucher --- The patch has been reverted: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=bfaddd9fc8ac048b99475f000dbef6f08297417f and will be reverted in stable branches as well. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #18 from Jason Vas Dias --- I think FGLRX is evidently able to run my laptop's display in dual-driver mode whereby the Intel IGP card runs the LCD in some sort of "slave" mode under the control of the fglrx Radeon 8970M controller module, to display frames produced by the Radeon card. It would be nice if Linux would either A) fully support this configuration OR B) detect that this configuration is not supported and refuse to attempt to go into graphics mode at all on the radeon card. - this would include things like vga_switcheroo complaining / returning an error when asked to switch without a MUX . Linux is evidently not doing either yet . I'm not convinced the intel driver can "go it alone" either in this scenario - see: https://bugs.freedesktop.org/show_bug.cgi?id=95078 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #19 from Jason Vas Dias --- Oops, the link should have been: https://bugs.freedesktop.org/show_bug.cgi?id=95140 but as it turns out, that other bug could be equally relevant. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #20 from Jason Vas Dias --- When I look at linux 4.5.0 boot dmesg log messages like : [3.115380] vga_switcheroo: enabled [3.115463] ATPX version 1, functions 0x0033 [3.115541] [drm] DMAR active, disabling use of stolen memory I think 'you lie, Linux' ! vga_switcheroo can never be enabled on this platform because it has no MUX , and the logs above show the quality of the ACPI ATPX support. I think this is the core linux relevant issue here - plus, I think it should in the case where only one card has control of the actual laptop display: [3.115580] device: 'i2c-8': device_add [3.115587] bus: 'i2c': add device i2c-8 [3.115598] PM: Adding info for i2c:i2c-8 [3.115607] i2c i2c-8: adapter [i915 gmbus ssc] registered [3.115706] device: 'i2c-9': device_add [3.115710] bus: 'i2c': add device i2c-9 [3.115720] PM: Adding info for i2c:i2c-9 [3.115724] i2c i2c-9: adapter [i915 gmbus vga] registered [3.115730] device: 'i2c-10': device_add [3.115734] bus: 'i2c': add device i2c-10 [3.115742] PM: Adding info for i2c:i2c-10 [3.115746] i2c i2c-10: adapter [i915 gmbus panel] registered [3.115751] device: 'i2c-11': device_add [3.115755] bus: 'i2c': add device i2c-11 [3.115762] PM: Adding info for i2c:i2c-11 [3.115767] i2c i2c-11: adapter [i915 gmbus dpc] registered [3.115772] device: 'i2c-12': device_add [3.115776] bus: 'i2c': add device i2c-12 [3.115784] PM: Adding info for i2c:i2c-12 [3.115787] i2c i2c-12: adapter [i915 gmbus dpb] registered [3.115792] device: 'i2c-13': device_add [3.115796] bus: 'i2c': add device i2c-13 [3.115804] PM: Adding info for i2c:i2c-13 [3.115807] i2c i2c-13: adapter [i915 gmbus dpd] registered [3.115843] vgaarb: device changed decodes: PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=none [3.115848] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=none:owns=io+mem [3.116170] device: 'card1-VGA-1': device_add [3.116188] PM: Adding info for No Bus:card1-VGA-1 [3.116212] device: 'card1-eDP-1': device_add [3.116231] PM: Adding info for No Bus:card1-eDP-1 [3.116251] device: 'i2c-14': device_add [3.116257] bus: 'i2c': add device i2c-14 [3.116265] PM: Adding info for i2c:i2c-14 [3.116269] i2c i2c-14: adapter [DPDDC-A] registered [3.116961] i2c i2c-14: master_xfer[0] W, addr=0x50, len=1 [3.116962] i2c i2c-14: master_xfer[1] R, addr=0x50, len=1 [3.118007] i2c i2c-14: master_xfer[0] W, addr=0x50, len=1 [3.118009] i2c i2c-14: master_xfer[1] R, addr=0x50, len=128 [3.137993] device: 'card1-DP-1': device_add [3.138011] PM: Adding info for No Bus:card1-DP-1 [3.138023] device: 'i2c-15': device_add [3.138028] bus: 'i2c': add device i2c-15 [3.138037] PM: Adding info for i2c:i2c-15 [3.138042] i2c i2c-15: adapter [DPDDC-B] registered [3.138062] device: 'card1-HDMI-A-1': device_add [3.138076] PM: Adding info for No Bus:card1-HDMI-A-1 [3.138091] device: 'card1-HDMI-A-2': device_add [3.138104] PM: Adding info for No Bus:card1-HDMI-A-2 [3.138124] device: 'card1-DP-2': device_add [3.138142] PM: Adding info for No Bus:card1-DP-2 [3.138154] device: 'i2c-16': device_add [3.138162] bus: 'i2c': add device i2c-16 [3.138171] PM: Adding info for i2c:i2c-16 [3.138176] i2c i2c-16: adapter [DPDDC-D] registered [3.138203] device: 'card1-HDMI-A-3': device_add [3.138216] PM: Adding info for No Bus:card1-HDMI-A-3 [3.161200] device: 'intel_backlight': device_add [3.161224] PM: Adding info for No Bus:intel_backlight [3.161286] bus: 'acpi': add driver video [3.161319] bus: 'acpi': driver_probe_device: matched device LNXVIDEO:00 with driver video [3.161322] bus: 'acpi': really_probe: probing driver video with device LNXVIDEO:00 [3.161327] video LNXVIDEO:00: no default pinctrl state [3.161333] devices_kset: Moving LNXVIDEO:00 to end of list [3.161349] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [3.161394] ACPI: Video Device [PEGP] (multi-head: yes rom: no post: no) [3.161559] device: 'input4': device_add [3.161597] PM: Adding info for No Bus:input4 [3.161615] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:4d/LNXVIDEO:00/input/input4 [3.161625] driver: 'video': driver_bound: bound to device 'LNXVIDEO:00' [3.161627] bus: 'acpi': really_probe: bound device LNXVIDEO:00 to driver video [3.161631] bus: 'acpi': driver_probe_device: matched device LNXVIDEO:01 with driver video [3.161633] bus: 'acpi': really_probe: probing driver video with device LNXVIDEO:01 [3.161636] video LNXVIDEO:01: no default pinctrl state [3.161640] devices_kset: Moving LNXVIDEO:01 to end of list [3.161710] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [3.161923] device: 'input5': device_add [3.161959] PM:
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #21 from Jason Vas Dias --- Aha! It was : Section "Device" Identifier "Intel" Driver "intel" Option "Monitor-eDP-1" "eDP-1" Option "Monitor-DisplayPort-0" "eDP-1" EndSection and also : Section "ServerLayout" Identifier "X Intel" Screen 0 "Screen0" 0 0 Inactive "Radeon" ... EndSection That did it! X-Server now initializes & xterm displays OK ! ( with patch applied to latest xf86-video-intel driver, see : https://bugs.freedesktop.org/show_bug.cgi?id=95140 ) The Monitor-DisplayPort-0 xorg.conf Device section option appears to only be documented in online blogs, eg: https://wiki.archlinux.org/index.php/multihead It is not mentioned in any manual page installed by any Xorg package. Let us eagerly anticipate the release of X11 7.8 and complete documentation ... But still there are these dmesgs after successfully switching into graphics mode with the Intel driver: [ 173.684435] [drm] probing gen 2 caps for device 8086:c01 = 261ad03/e [ 173.684460] [drm] PCIE gen 3 link speeds already enabled [ 173.688244] [drm] PCIE GART of 2048M enabled (table at 0x002E8000). [ 173.688390] radeon :01:00.0: WB enabled [ 173.688405] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x00010c00 and cpu addr 0x880414fb6c00 [ 173.688436] radeon :01:00.0: fence driver on ring 1 use gpu addr 0x00010c04 and cpu addr 0x880414fb6c04 [ 173.688465] radeon :01:00.0: fence driver on ring 2 use gpu addr 0x00010c08 and cpu addr 0x880414fb6c08 [ 173.688495] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x00010c0c and cpu addr 0x880414fb6c0c [ 173.689306] radeon :01:00.0: fence driver on ring 4 use gpu addr 0x00010c10 and cpu addr 0x880414fb6c10 [ 173.690471] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00075a18 and cpu addr 0xc9435a18 [ 173.711357] radeon :01:00.0: fence driver on ring 6 use gpu addr 0x00010c18 and cpu addr 0x880414fb6c18 [ 173.712128] radeon :01:00.0: fence driver on ring 7 use gpu addr 0x00010c1c and cpu addr 0x880414fb6c1c [ 173.860206] [drm] ring test on 0 succeeded in 2 usecs [ 173.860941] [drm] ring test on 1 succeeded in 1 usecs [ 173.861661] [drm] ring test on 2 succeeded in 1 usecs [ 173.862381] [drm] ring test on 3 succeeded in 1 usecs [ 173.863045] [drm] ring test on 4 succeeded in 3 usecs [ 174.040803] [drm] ring test on 5 succeeded in 2 usecs [ 174.041484] [drm] UVD initialized successfully. [ 174.152209] [drm] ring test on 6 succeeded in 15 usecs [ 174.152884] [drm] ring test on 7 succeeded in 4 usecs [ 174.153545] [drm] VCE initialized successfully. [ 174.154235] f 0#2: signaled from fence_wait [ 174.154923] [drm] ib test on ring 0 succeeded in 0 usecs [ 174.155606] f 1#2: signaled from fence_wait [ 174.156273] [drm] ib test on ring 1 succeeded in 0 usecs [ 174.156960] f 2#2: signaled from fence_wait [ 174.157611] [drm] ib test on ring 2 succeeded in 0 usecs [ 174.158282] f 3#2: signaled from fence_wait [ 174.158959] [drm] ib test on ring 3 succeeded in 0 usecs [ 174.159604] f 4#2: signaled from fence_wait [ 174.160242] [drm] ib test on ring 4 succeeded in 0 usecs [ 174.812851] f 5#4: signaled from fence_wait [ 174.813666] [drm] ib test on ring 5 succeeded [ 175.314798] f 6#4: signaled from fence_wait [ 175.315606] [drm] ib test on ring 6 succeeded [ 175.816796] f 7#4: signaled from fence_wait [ 175.817602] [drm] ib test on ring 7 succeeded [ 175.898550] device: 'vcs4': device_add [ 175.898567] PM: Adding info for No Bus:vcs4 [ 175.898612] device: 'vcsa4': device_add [ 175.898621] PM: Adding info for No Bus:vcsa4 [ 181.380548] ACPI Error: No handler for Region [EC81] (88041d8d9bd0) [EmbeddedControl] (20160108/evregion-166) [ 181.380553] ACPI Error: Region EmbeddedControl (ID=3) has no handler (20160108/exfldio-299) [ 181.380557] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP.SGOF] (Node 88041d8fca50), AE_NOT_EXIST (20160108/psparse-542) [ 181.380561] ACPI Error: Method parse/execution failed [\_SB.PCI0.PEG0.PEGP._OFF] (Node 88041d8fce88), AE_NOT_EXIST (20160108/psparse-542) [ 181.380564] ACPI Error: Method parse/execution failed [\_SB.PCI0.GFX0.ATPX] (Node 88041d9034b0), AE_NOT_EXIST (20160108/psparse-542) [ 181.380569] failed to evaluate ATPX got AE_NOT_EXIST [ 264.565810] i2c i2c-9: master_xfer[0] W, addr=0x50, len=1 [ 264.565813] i2c i2c-9: master_xfer[1] R, addr=0x50, len=1 It looks like the Intel driver cannot execute that ATPX method either - I definitely did specify 'radeon.runpm=0' , so this time it must be something else invoking it . Do I need to specify 'intel.runpm=0' ? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #22 from Jason Vas Dias --- It looks like the Intel driver is actually internally using the Radeon driver? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #23 from Jason Vas Dias --- Xorg server log of successful session [ 173.214] X.Org X Server 1.18.3 Release Date: 2016-04-04 [ 173.214] X Protocol Version 11, Revision 0 [ 173.214] Build Operating System: Linux 4.5.0 x86_64 [ 173.214] Current Operating System: Linux jvdlux 4.5.0 #3 SMP PREEMPT Fri Apr 22 23:01:54 GMT 2016 x86_64 [ 173.214] Kernel command line: BOOT_IMAGE=/vmlinuz-4.5.0 root=/dev/OS/linux rd.lvm.lv=OS/linux ro i915.modeset=1 radeon.runpm=1 [ 173.214] Build Date: 23 April 2016 08:17:36PM [ 173.214] [ 173.214] Current version of pixman: 0.34.0 [ 173.214]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 173.214] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 173.215] (==) Log file: "/usr/var/log/Xorg.0.log", Time: Tue Apr 26 19:03:03 2016 [ 173.216] (==) Using config file: "/etc/X11/xorg.conf" [ 173.216] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 173.217] (==) ServerLayout "X Intel" [ 173.217] (**) |-->Screen "Screen0" (0) [ 173.217] (**) | |-->Monitor "Monitor0" [ 173.217] (**) | |-->Device "Intel" [ 173.217] (**) | |-->GPUDevice "Radeon" [ 173.217] (**) |-->Inactive Device "Radeon" [ 173.217] (**) |-->Input Device "Mouse0" [ 173.217] (**) |-->Input Device "Keyboard0" [ 173.217] (==) Automatically adding devices [ 173.217] (==) Automatically enabling devices [ 173.217] (==) Automatically adding GPU devices [ 173.217] (==) Max clients allowed: 256, resource mask: 0x1f [ 173.220] (**) FontPath set to: ... [ 173.220] (II) Module ABI versions: [ 173.220]X.Org ANSI C Emulation: 0.4 [ 173.220]X.Org Video Driver: 20.0 [ 173.220]X.Org XInput driver : 22.1 [ 173.220]X.Org Server Extension : 9.0 [ 173.220] (II) xfree86: Adding drm device (/dev/dri/card0) [ 175.811] (II) xfree86: Adding drm device (/dev/dri/card1) [ 175.812] (--) PCI:*(0:0:2:0) 8086:0416:1558:5106 rev 6, Mem @ 0xf740/4194304, 0xd000/268435456, I/O @ 0xf000/64 [ 175.812] (--) PCI: (0:1:0:0) 1002:6801:1558:5106 rev 0, Mem @ 0xe000/268435456, 0xf7b0/262144, I/O @ 0xe000/256, BIOS @ 0x/131072 [ 175.812] (II) Open ACPI successful (/var/run/acpid.socket) [ 175.812] (II) "glx" will be loaded by default. [ 175.812] (II) LoadModule: "dri2" [ 175.812] (II) Module "dri2" already built-in [ 175.812] (II) LoadModule: "glamoregl" [ 175.816] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 175.830] (II) Module glamoregl: vendor="X.Org Foundation" [ 175.830]compiled for 1.18.3, module version = 1.0.0 [ 175.830]ABI class: X.Org ANSI C Emulation, version 0.4 [ 175.830] (II) LoadModule: "glx" [ 175.830] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 175.848] (II) Module glx: vendor="X.Org Foundation" [ 175.848]compiled for 1.18.3, module version = 1.0.0 [ 175.848]ABI class: X.Org Server Extension, version 9.0 [ 175.848] (==) AIGLX enabled [ 175.848] (II) LoadModule: "intel" [ 175.848] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 175.859] (II) Module intel: vendor="X.Org Foundation" [ 175.859]compiled for 1.18.3, module version = 2.99.917 [ 175.859]Module class: X.Org Video Driver [ 175.859]ABI class: X.Org Video Driver, version 20.0 [ 175.859] (II) LoadModule: "ati" [ 175.859] (II) Loading /usr/lib64/xorg/modules/drivers/ati_drv.so [ 175.867] (II) Module ati: vendor="X.Org Foundation" [ 175.867]compiled for 1.18.3, module version = 7.7.0 [ 175.867]Module class: X.Org Video Driver [ 175.867]ABI class: X.Org Video Driver, version 20.0 [ 175.867] (II) LoadModule: "radeon" [ 175.867] (II) Loading /usr/lib64/xorg/modules/drivers/radeon_drv.so [ 175.878] (II) Module radeon: vendor="X.Org Foundation" [ 175.878]compiled for 1.18.3, module version = 7.7.0 [ 175.878]Module class: X.Org Video Driver [ 175.879]ABI class: X.Org Video Driver, version 20.0 [ 175.879] (II) LoadModule: "synaptics" [ 175.879] (II) Loading /usr/lib64/xorg/modules/input/synaptics_drv.so [ 175.881] (II) Module synaptics: vendor="X.Org Foundation" [ 175.881]compiled for 1.18.3, module version = 1.8.3 [ 175.881]Module class: X.Org XInput Driver [ 175.881]ABI class: X.Org XInput driver, version 22.1 [ 175.881] (II) LoadModule: "evdev" [ 175.881] (II) Loading /usr/lib64/xorg/modules/input/evdev_drv.so [ 175.884] (II) Module evdev: vendor="X.Org Foundation" [ 175.884]compiled for 1.18.3, module version = 2.10.1 [ 175.884]Module class: X.Org XInput Driver [ 175.884]ABI class: X.Org XInput driver, version 22.1 [ 175.884] (II) intel: Driver for Intel(R) Integrated Graphi
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #24 from Alex Deucher --- (In reply to Jason Vas Dias from comment #20) > When I look at linux 4.5.0 boot dmesg log messages like : > > [3.115380] vga_switcheroo: enabled > [3.115463] ATPX version 1, functions 0x0033 > [3.115541] [drm] DMAR active, disabling use of stolen memory > > > I think 'you lie, Linux' ! The driver reads the supported ATPX functions from ACPI. So it's a bios bug. > > vga_switcheroo can never be enabled on this platform because > it has no MUX , and the logs above show the quality of the > ACPI ATPX support. > vga_switcheroo and ATPX are used on muxed and mux-less platforms to powerdown the dGPU dynamically when it's not in use. The ATPX error messages are harmless though as they are not checked anywhere. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #25 from Alex Deucher --- Please attach you logs rather than pasting them in the comments, it's much harder to follow with them inline. Also, as per comment 11, please try removing your xorg config file completely. The drivers are able to auto detect everything they need and having the file generally causes more problems than good as you saw for yourself. It may be preventing the radeon x driver from loading if you have having problems selecting it for render offload. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117131] vga_switcheroo does not switch IGP -> DIS ( IGP == i915 , DIS == radeon )
https://bugzilla.kernel.org/show_bug.cgi?id=117131 --- Comment #26 from Alex Deucher --- (In reply to Jason Vas Dias from comment #22) > It looks like the Intel driver is actually internally using the Radeon > driver? No. The drivers are independent. vga_switcheroo provides the intermediary for alerting the drivers when the user has switched the mux for muxed laptops. For muxless laptops, the dGPU driver uses vga_switcheroo and ATPX to power down the dGPU when it's not in use. The IGP driver is not involved in that. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86351] HDMI audio garbled output on Radeon R9 280X
https://bugzilla.kernel.org/show_bug.cgi?id=86351 haakobja at gmail.com changed: What|Removed |Added CC||haakobja at gmail.com --- Comment #25 from haakobja at gmail.com --- I'm currently experiencing the same issue using a Radeon R9 270X. I've tried some of the tips discussed in the Arch Linux forums (https://bbs.archlinux.org/viewtopic.php?id=181764), but I've not been able to get it to work. If I remember correctly, the driver bundled with the Radeon Catalyst-driver fixed the issue. Due to the recent kernel I'm running, the driver will not install. I'm currently running the 4.5.2-kernel. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117181] graphic glitches for Kernel > 4.2 Intel HD 5xx and skylake
https://bugzilla.kernel.org/show_bug.cgi?id=117181 yves.dufournaud at gmail.com changed: What|Removed |Added Regression|No |Yes -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117151] amdgpu: Fails to initialize R7 260x (Bonaire)
https://bugzilla.kernel.org/show_bug.cgi?id=117151 --- Comment #1 from Parker Reed --- Created attachment 214661 --> https://bugzilla.kernel.org/attachment.cgi?id=214661&action=edit Full verbose lspci -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117171] Radeon GPU lockup in X windows after resuming from blank screen
https://bugzilla.kernel.org/show_bug.cgi?id=117171 --- Comment #3 from Erik Brangs --- The problem might be related to DPMS: I haven't seen any freezes after deactivating DPMS in xscreensaver. When I use DPMS with "Standby" in xscreensaver and set the times for "Suspend" and "Off" to a high value so that they won't be triggered, the problem still occurs. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117411] New: [radeon][HD5650][REDWOOD] radeon.dpm causing one minute boot delay
https://bugzilla.kernel.org/show_bug.cgi?id=117411 Bug ID: 117411 Summary: [radeon][HD5650][REDWOOD] radeon.dpm causing one minute boot delay Product: Drivers Version: 2.5 Kernel Version: 4.5.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: no.spam.to.me at ish.de Regression: No Created attachment 214751 --> https://bugzilla.kernel.org/attachment.cgi?id=214751&action=edit Xorg log for 4.4.0 kernel Hi there! I'm running Debian testing with kernel 4.5.0-1-amd64. Before this I ran Debian Jessie with 3.16.0-4-amd64. After upgrading to testing I noticed a highly increased boot delay of roughly one minute (that was already kernel 4.4.0). In Xorg log I can see that there is three times a gap of about roughly 12 seconds (maybe because my card has three connectors [HDMI/LVDS/VGA]?). When the kernel loads the radeon module there is also a long "black period". Now I found out that by setting radeon.dpm=0 the delay is gone- together with power management. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117411] [radeon][HD5650][REDWOOD] radeon.dpm causing one minute boot delay
https://bugzilla.kernel.org/show_bug.cgi?id=117411 --- Comment #1 from no.spam.to.me at ish.de --- Created attachment 214761 --> https://bugzilla.kernel.org/attachment.cgi?id=214761&action=edit dmesg for 4.4.0 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117411] [radeon][HD5650][REDWOOD] radeon.dpm causing one minute boot delay
https://bugzilla.kernel.org/show_bug.cgi?id=117411 --- Comment #2 from no.spam.to.me at ish.de --- Look here: [ 24.114256] Bluetooth: BNEP socket layer initialized [ 35.249644] Console: switching to colour frame buffer device 170x48 That seems to be the "black period" -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 141741] drm:radeon_get_bios [radeon]] *ERROR* Unable to locate a BIOS ROM
https://bugzilla.kernel.org/show_bug.cgi?id=141741 --- Comment #13 from Michael Schenaerts --- I did the bisect with no luck. Evrything was running fine I built the 4.6 and even the 4.7 with the config files from the 4.5 I set the other options to default and... it works. I'll try to build them with the 4.6 config as soon as I have the time. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 96721] radeon: unable to handle kernel paging request with counter strike: go
https://bugzilla.kernel.org/show_bug.cgi?id=96721 --- Comment #2 from Michel Dänzer --- It's not clear that those are both one and the same bug. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] New: AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 Bug ID: 151341 Summary: AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait Product: Drivers Version: 2.5 Kernel Version: 4.7.0 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: yshuiv7 at gmail.com Regression: No The system is still operational, and I was able to login remotely via ssh. Seems to happen more often when the CPU is under load. Relevant dmesg: INFO: task Xorg:539 blocked for more than 120 seconds. Not tainted 4.7.0 #5 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. XorgD 880085387a48 0 539537 0x00080084 880085387a48 880392f1ea40 880085388000 88045e658000 88045e658000 880062516840 7fff 880085387a60 815e5dd0 880085387ad8 Call Trace: [] schedule+0x30/0x80 [] schedule_timeout+0x159/0x1a0 [] ? __wake_up_locked+0xe/0x10 [] fence_default_wait+0x182/0x1d0 [] ? fence_free+0x20/0x20 [] fence_wait_timeout+0x4e/0x90 [] amdgpu_ctx_add_fence+0x5d/0x100 [amdgpu] [] amdgpu_cs_ioctl+0xbf0/0xff0 [amdgpu] [] drm_ioctl+0x14d/0x530 [] ? amdgpu_cs_find_mapping+0x90/0x90 [amdgpu] [] ? do_readv_writev+0x11a/0x200 [] amdgpu_drm_ioctl+0x47/0x80 [amdgpu] [] do_vfs_ioctl+0x8d/0x570 [] ? syscall_slow_exit_work+0xb5/0x100 [] ? __sys_recvmsg+0x5d/0x70 [] ? __audit_syscall_entry+0xa6/0xf0 [] SyS_ioctl+0x3c/0x70 [] do_syscall_64+0x5a/0x110 [] entry_SYSCALL64_slow_path+0x25/0x25 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 bastienphilbert at gmail.com changed: What|Removed |Added CC||bastienphilbert at gmail.com --- Comment #14 from bastienphilbert at gmail.com --- See if the below patch fixes the issue as it seems your not allocating memory for the cmap. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #15 from bastienphilbert at gmail.com --- Created attachment 227551 --> https://bugzilla.kernel.org/attachment.cgi?id=227551&action=edit Cmap Fix -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #16 from Christian Casteyde --- No, I still have this: [ 1215.037018] WARNING: kmemcheck: Caught 16-bit read from uninitialized memory (8801c307d020) [ 1215.037029] 2e032b012206070e0307373e033534262327353721171507111e031514062322 [ 1215.037038] u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u u [ 1215.037039] ^ [ 1215.037046] RIP: 0010:[] [] drm_fb_helper_setcmap+0x15b/0x420 [ 1215.037047] RSP: 0018:8801b9fc7a30 EFLAGS: 00010286 [ 1215.037048] RAX: 0010 RBX: 0010 RCX: [ 1215.037049] RDX: 00ff RSI: 0000 RDI: 8801c3064390 [ 1215.037050] RBP: 8801b9fc7ad8 R08: 8801c307c840 R09: 8801c307d200 [ 1215.037051] R10: 8801c307d022 R11: R12: 8801c307d220 [ 1215.037051] R13: 8801c307d420 R14: 8801c307c800 R15: 8801c3064000 [ 1215.037053] FS: 7f35566fd8c0() GS:8801c740() knlGS: [ 1215.037054] CS: 0010 DS: ES: CR0: 80050033 [ 1215.037055] CR2: 8801c29306c0 CR3: a8911000 CR4: 000406f0 [ 1215.037058] [] fb_set_cmap+0x49/0x130 [ 1215.037060] [] fb_set_var+0x279/0x460 [ 1215.037063] [] fbcon_blank+0x33b/0x380 [ 1215.037066] [] do_unblank_screen+0xc6/0x190 [ 1215.037069] [] vt_ioctl+0x533/0x1430 [ 1215.037071] [] tty_ioctl+0x38c/0xe90 [ 1215.037073] [] do_vfs_ioctl+0x8e/0x670 [ 1215.037075] [] SyS_ioctl+0x3c/0x70 [ 1215.037078] [] entry_SYSCALL_64_fastpath+0x18/0xa8 [ 1215.037080] [] 0x -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] New: AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 Bug ID: 151541 Summary: AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume Product: Drivers Version: 2.5 Kernel Version: 4.7.0 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: pastas4 at gmail.com Regression: No Created attachment 227711 --> https://bugzilla.kernel.org/attachment.cgi?id=227711&action=edit dmesg I am using an Acer Aspire 7560G laptop with muxless AMD-AMD hybrid graphics, officially 6520G integrated and 6720G dedicated: 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] BeaverCreek [Radeon HD 6520G] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] (rev ff) This configuration causes kernel errors whenever the dedicated card gets touched (usually by either running lspci - which takes a while to run - or turning the monitor off and back on again). Visually that shows up as flickering and parts of the screen not refreshing properly. If in the BIOS I turn off the dedicated card completely, I don't have this problem any more. I tested it with kernel 4.7 and 4.1, both had the same results. I'm running openSUSE Leap 42.1. Here's the relevant part of dmesg (full dmesg is attached): [ 668.895509] radeon :01:00.0: Refused to change power state, currently in D3 [ 668.971201] radeon :01:00.0: Refused to change power state, currently in D3 [ 668.987293] radeon :01:00.0: Refused to change power state, currently in D3 [ 668.988397] radeon :01:00.0: GPU softreset: 0x0BDD [ 668.988405] radeon :01:00.0: GRBM_STATUS = 0x [ 668.988412] radeon :01:00.0: GRBM_STATUS_SE0 = 0x [ 668.988417] radeon :01:00.0: GRBM_STATUS_SE1 = 0x [ 668.988423] radeon :01:00.0: SRBM_STATUS = 0x [ 668.988428] radeon :01:00.0: SRBM_STATUS2 = 0x [ 668.988434] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 668.988439] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 668.988445] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 668.988450] radeon :01:00.0: R_008680_CP_STAT = 0x [ 668.988456] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x [ 670.587759] radeon :01:00.0: Wait for MC idle timedout ! [ 670.587762] radeon :01:00.0: GRBM_SOFT_RESET=0x [ 670.587817] radeon :01:00.0: SRBM_SOFT_RESET=0x [ 670.588971] radeon :01:00.0: GRBM_STATUS = 0x [ 670.588973] radeon :01:00.0: GRBM_STATUS_SE0 = 0x [ 670.588976] radeon :01:00.0: GRBM_STATUS_SE1 = 0x [ 670.588978] radeon :01:00.0: SRBM_STATUS = 0x [ 670.588981] radeon :01:00.0: SRBM_STATUS2 = 0x [ 670.588983] radeon :01:00.0: R_008674_CP_STALLED_STAT1 = 0x [ 670.588986] radeon :01:00.0: R_008678_CP_STALLED_STAT2 = 0x [ 670.588988] radeon :01:00.0: R_00867C_CP_BUSY_STAT = 0x [ 670.588991] radeon :01:00.0: R_008680_CP_STAT = 0x [ 670.588993] radeon :01:00.0: R_00D034_DMA_STATUS_REG = 0x [ 675.594474] [drm:atom_op_jump [radeon]] *ERROR* atombios stuck in loop for more than 5secs aborting [ 675.594493] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing CE66 (len 62, WS 0, PS 0) @ 0xCE82 [ 675.594511] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BB66 (len 1036, WS 4, PS 0) @ 0xBC63 [ 675.594529] [drm:atom_execute_table_locked [radeon]] *ERROR* atombios stuck executing BAFC (len 76, WS 0, PS 8) @ 0xBB04 [ 675.594653] [drm:radeon_pm_resume [radeon]] *ERROR* radeon: dpm resume failed [ 677.087926] radeon :01:00.0: Wait for MC idle timedout ! [ 677.274849] radeon :01:00.0: Wait for MC idle timedout ! [ 677.292534] [drm] PCIE GART of 1024M enabled (table at 0x00162000). [ 677.292646] radeon :01:00.0: WB enabled [ 677.292651] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8800c6e69c00 [ 677.292654] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8800c6e69c0c [ 677.297315] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc90001c32118 [ 677.510244] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0x) [ 677.510268] [drm:evergreen_resume [radeon]] *ERR
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 Dainius Masiliūnas changed: What|Removed |Added Attachment #227711|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 --- Comment #1 from Dainius Masiliūnas --- Using radeon.dpm=0 doesn't change anything, only the "*ERROR* radeon: dpm resume failed" line is not there in that case. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 118611] Using the 4.6 Kernel causes one Radeon screen to intermittently power cycle.
https://bugzilla.kernel.org/show_bug.cgi?id=118611 K. Paden changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #7 from K. Paden --- The answer was to go into the display control screen, and lower the resolution of the screen that was powering off. I noticed in Kernel 4.5.3, this was a problem. But it is ok now with the one screen at a lower resolution. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- Does setting radeon.runpm=0 help? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 --- Comment #3 from Alex Deucher --- On the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 --- Comment #4 from Dainius Masiliūnas --- Yes, it does. With that setting, there are no errors either, and lspci runs quickly. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 --- Comment #5 from Alex Deucher --- Does it work any better with kernel 4.8? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 84431] Kernel crash when unloading radeon module for switcheroo card
https://bugzilla.kernel.org/show_bug.cgi?id=84431 --- Comment #10 from JoaquÃn AramendÃa --- > JoaquÃn, how does 97d30fa35 break nouveau vga-switcheroo? If you load > nouveau with runpm=0, then you can write OFF to debugfs' vga_switcheroo. > However runpm=1 (or -1 for Optimus systems) is recommended. Just tested removing nouveau module with Ubuntu 16.04 on mainline kernel v4.6.5 and it worked correctly. Also modprobed it after that and worked correctly. This bug should be marked as resolved. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151541] AMD hybrid graphics: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugzilla.kernel.org/show_bug.cgi?id=151541 --- Comment #6 from Dainius Masiliūnas --- Created attachment 227741 --> https://bugzilla.kernel.org/attachment.cgi?id=227741&action=edit 4.7.0-next-20160803 dmesg No. I tried the linux-next tree and it gave me the same errors even during boot itself. dmesg is attached. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #17 from bastienphilbert at gmail.com --- Can you find out what drm driver you are currently using as all of them link to the core function that is leaking memory and knowing which drive is doing it would be very helpful. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 36522] Caught 16-bit read from uninitialized memory in drm_fb_helper_setcmap
https://bugzilla.kernel.org/show_bug.cgi?id=36522 --- Comment #18 from Christian Casteyde --- See comment #3, #4 and #5. I think i'm using radeon driver with kms since the only graphic chip I have on my laptop is a Radeon 6650M (no intel graphic in CPU, has been deactivated by vendor). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 --- Comment #2 from yshuiv7 at gmail.com --- Created attachment 227861 --> https://bugzilla.kernel.org/attachment.cgi?id=227861&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 --- Comment #3 from yshuiv7 at gmail.com --- Created attachment 227871 --> https://bugzilla.kernel.org/attachment.cgi?id=227871&action=edit Xorg.log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 --- Comment #4 from yshuiv7 at gmail.com --- Previous dmesg is from 4.7.0, the attached one is from git HEAD. Using the _k_ firmware seems to make this happen much less frequently. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 --- Comment #5 from yshuiv7 at gmail.com --- I tried to reset the gpu by using /sys/kernel/debug/dri/0/amdgpu_gpu_reset, and the result is a NULL pointer dereference in the kernel. dmesg attached -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151341] AMDGPU Hawaii: screen freeze, Xorg blocked in fence_default_wait
https://bugzilla.kernel.org/show_bug.cgi?id=151341 --- Comment #6 from yshuiv7 at gmail.com --- Created attachment 227901 --> https://bugzilla.kernel.org/attachment.cgi?id=227901&action=edit Kernel Oops when resetting the GPU -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 118701] x86_64 GMA500 reports /dev/dri/card0: failed to set DRM interface version 1.4: Inappropriate ioctl for device
https://bugzilla.kernel.org/show_bug.cgi?id=118701 Stuart Foster changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|CODE_FIX|--- --- Comment #6 from Stuart Foster --- Hi Patrik, I have checked both linux-4.7 and linux-4.8-rc1 and this fix has not made it through, when do you think it will be included ? Thanks. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 100871] radeon fails to initialize one DisplayPort monitor
https://bugzilla.kernel.org/show_bug.cgi?id=100871 --- Comment #10 from Charles R. Anderson --- Problem still exists in Linux 4.6.4 in Fedora 24 (kernel-4.6.4-301.fc24.x86_64). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #3 from Jimi --- I've now confirmed this issue on Fiji (R9 Fury) as well. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #4 from Jimi --- Is this bug still happening? With my R9 Fury on amdgpu, cat /sys/class/hwmon/hwmon0/pwm1 (well, in my case, it's hwmon2 because I have another card), returns 35 on idle, not 0, but the fans are not running. Even when I'm running a AAA game, my card doesn't even reach 40°C, so my cooling system is too good for me to be able to actually see if the fans turn on when they should. When I first started my computer up, pwm1 was giving me 56, but it went down to 35 before I could finish opening my case and has stayed there no matter what I do. When the card is bound to vfio-pci instead of amdgpu (for a virtual machine), the fan is on all the time, even though the card's low idle temperatures must be similar. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #5 from Jimi --- I managed to check the fans while pwm1 was giving values like 68, 61, and 56, and they were not turned on. I don't know if that means anything, because the card was still <40 degrees and definitely not too hot to touch. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] New: Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 Bug ID: 151831 Summary: Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive. Product: Drivers Version: 2.5 Kernel Version: Crashes with kernel 4.6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: andros at all-ein.net Regression: No Created attachment 228051 --> https://bugzilla.kernel.org/attachment.cgi?id=228051&action=edit Sys log System ist A8 APU A8-3500M, HD 6620 Radeon, Dell Vostro 35 This happens every like every two days. Screen turns black and freezes, mouse cursor still movable. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 --- Comment #1 from Andre --- Created attachment 228061 --> https://bugzilla.kernel.org/attachment.cgi?id=228061&action=edit glxinfo -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- You are getting a GPU lockup. Is there any particular trigger? A specific app that tends to trigger it? Updating mesa may help if you are running an older version. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #6 from Stas Sergeev --- > Is this bug still happening? For me it is happening as a hell. And because fancontrol service also doesn't work on my PC (I've filled another reports about it), the problems are very real. > I managed to check the fans while pwm1 was giving values like You can write the values there, too. In fact, I wonder who changes them for you. Do you have the fancontrol set up and running? $ systemctl status fancontrol -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #7 from Jimi --- I do not have fancontrol set up or running (it's inactive on my system). I don't know anything about fancontrol at all. I'm running Arch Linux, so I pretty much only am running services that I know about. I tried writing values myself with echo, like 'echo 50 > /sys/class/hwmon/hwmon0/pwm1', but that didn't affect it at all. Is that not how you're supposed to change it? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #8 from Alex Deucher --- By default the hw controls the fan based on temperature, etc. Not all cards have a fan control. If you do, then the following standard HWMON pwm attributes should be available: * pwm1_enable: Current fan management mode (MANUAL or AUTO) * pwm1: Current PWM value (power percentage) * pwm1_min: The minimum PWM speed allowed * pwm1_max: The maximum PWM speed allowed (bypassed when hitting Fan_boost) The fan can be driven in different modes: * 1: The fan can be driven in manual (use pwm1 to change the speed); * 2; The fan is driven automatically depending on the temperature. See: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c#n644 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #9 from Stas Sergeev --- (In reply to Alex Deucher from comment #8) > By default the hw controls the fan based on temperature, etc. For me not. > Not all cards have a fan control. If you do, then the following standard > HWMON > pwm attributes should be available: > > * pwm1_enable: Current fan management mode (MANUAL or AUTO) I have always '1' there. Trying to write 0 or 2 there still leaves 1. It simply doesn't change. > * pwm1: Current PWM value (power percentage) Always 0, unless manually written. > The fan can be driven in different modes: > > * 1: The fan can be driven in manual (use pwm1 to change the speed); > * 2; The fan is driven automatically depending on the temperature. What should I write to pwm1_enable? '2'? It doesn't change. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #10 from Alex Deucher --- Please attach your dmesg output and xorg log (if running X). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #11 from Stas Sergeev --- Created attachment 228111 --> https://bugzilla.kernel.org/attachment.cgi?id=228111&action=edit dmesg -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #12 from Stas Sergeev --- Created attachment 228121 --> https://bugzilla.kernel.org/attachment.cgi?id=228121&action=edit Xorg log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 --- Comment #3 from Andre --- I'm using mesa 12.0.1 The only thing that works is downgrading kernel to 4.5 had the Problem with kernel 4.6.2 too I'm on Sabayon -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 --- Comment #4 from Alex Deucher --- (In reply to Andre from comment #3) > I'm using mesa 12.0.1 > The only thing that works is downgrading kernel to 4.5 Can you bisect? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 --- Comment #5 from Andre --- eh, do what? ..may if you give complete howto for my sabayon/gentoo system? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #13 from Jimi --- That's interesting. My pwm1_enable returns 1, and trying to change it to 0 or 2 does nothing, but my pwm1 value does indeed change on its own, and I've never seen it be 0. It sounds like I don't have this bug but do have some other less major one? If pwm1 is changing on its own, can I trust that the fan will turn on if my card ever gets too hot? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #14 from Jimi --- I should mention, my pwm1_min is 0 and pwm1_max is 255. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #15 from Stas Sergeev --- > I should mention, my pwm1_min is 0 and pwm1_max is 255. Same here. IMHO pwm1_min should contain the value that keeps the fan rotating at a minimal safe speed. Putting 0 there makes it entirely useless. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #16 from Jimi --- Not necessarily. Less fans means less power usage means money saved, and as we can see with my computer, you can keep the card cool without its own fans. I have 4 case fans that are plugged directly into power and so are less competent at knowing when to turn off. Something needs to be done about your fan not activating when it should, though. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 151831] Video freezes mouse moveable, video graphical errors like black strips an screen goes black sometimes, system almost unresponsive.
https://bugzilla.kernel.org/show_bug.cgi?id=151831 --- Comment #6 from Alex Deucher --- Bisecting is a process for determining which specific commit in a project caused a regression. Google for "linux kernel git bisect howto". -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 119211] amdgpu disables fan by default
https://bugzilla.kernel.org/show_bug.cgi?id=119211 --- Comment #17 from Stas Sergeev --- > Not necessarily. Less fans means less power usage means money saved You can set up fancontrol or put 0 into pwm1 manually to stop the fan. But putting 0 into pwm1_min is IMHO quite useless, it can as well just not exist at all. But if it will contain the minimum _safe_ value, then that can well be used. Currently fancontrol have to "evaluate" the minimal safe value by hands. It lowers the pwm1 value and looks when the fan have stopped by checking the value of fan1_input if that exists. And it doesn't exist for amdgpu, so you need to do such a probe by hands. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #4 from Jimi --- Created attachment 228411 --> https://bugzilla.kernel.org/attachment.cgi?id=228411&action=edit X crash log Here are my Xorg logs for when I unbind from vfio-pci, remove, and rescan, and X crashes and comes back with the card bound. The post-crash log is the Xorg.0.log file, which just shows X loading a desktop that uses both cards (although the AMD card has "Ignore" set to "true" since it's just meant for running games with the DRI_PRIME variable), and the crash log is the Xorg.0.log.old file, which captures the moment of the crash starting at time [456.336]. You can see there aren't any errors in there. It seems to be just reconfiguring the graphics because it noticed a new available card, and somehow that resulted in me being booted back to the login screen. And according to all the tutorials I've read on switching a card between vfio-pci and X, it shouldn't even be doing this on its own. It should be waiting for me to bind the card to amdgpu myself. Why is it doing it automatically and booting me out? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #5 from Jimi --- Created attachment 228421 --> https://bugzilla.kernel.org/attachment.cgi?id=228421&action=edit X post-crash log -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #6 from Jimi --- Created attachment 228431 --> https://bugzilla.kernel.org/attachment.cgi?id=228431&action=edit dmesg log And now I've tried unbinding it from amdgpu without X running at all, and it of course didn't work, confirming its kernel bug status. I've captured the dmesg log, and as far as I can tell, the part of the log that pertains to amdgpu is the stack trace starting at [1131.985756]. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #7 from Jimi --- I should mention at this point, I think there are 2 different bugs going on. One bug is making it impossible to unbind any cards from the driver, and another bug is making X immediately bind itself to an amdgpu card the instant it becomes available and crash. The former is definitely something wrong with amdgpu in the kernel, but the latter could be X's fault--I don't know. Just in case, I've filed a report for X, too: https://bugs.freedesktop.org/show_bug.cgi?id=97313 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 150731] amdgpu: segfault on unbind in sysfs; card becomes nonresponsive
https://bugzilla.kernel.org/show_bug.cgi?id=150731 --- Comment #8 from Jimi --- Created attachment 228441 --> https://bugzilla.kernel.org/attachment.cgi?id=228441&action=edit dmesg log (amdgpu-pro) And here's the dmesg log from testing this with amdgpu-pro (without X running), with the crash starting at [137.003975]. amdgpu-pro exhibited almost exactly the same behavior. The only difference was instead of getting a segfault after a few seconds, the terminal session that unbound the card was immediately spammed with the dmesg stack trace in this attached file. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 117151] amdgpu: Fails to initialize R7 260x (Bonaire)
https://bugzilla.kernel.org/show_bug.cgi?id=117151 Parker Reed changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #7 from Parker Reed --- This is fixed as of compiling linux-git 4.8rc1.r121.g4b9eaf3-1 Initializes correctly and even the Pro stack works on top of the amdgpu driver. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85241] audio over HDMI on AMD E-350 with radeon driver
https://bugzilla.kernel.org/show_bug.cgi?id=85241 --- Comment #5 from Sergei Sinyak --- (In reply to mirh from comment #4) > Created attachment 215621 [details] > TV was attached before booting. > > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/ > ?id=7403c515c49c033fec33df0814fffdc977e6acdc > I read this should be supposed to improve HDMI audio (it landed in 4.6-rc5). Installed recently kernel update (4.7 now, previous 4.6.4). ELD speaker allocation is working without running Xorg this time. Each time computer wakes up after a suspend I need to re-attach power cord, otherwise $ cat f1/card0/eld#0.0 shows empty file. But botting up doesn't require reattaching of one. (In reply to Sergei Sinyak from comment #3) > hi, i can reproduce this bug on two configurations. > That's radeon hd 6320, radeon hd 5650. > kernel version 4.1.3, but tried to load radeon module > compiled from 4.1-rc8, and it presents. > > Description: > The actual question is that: > after just loading radeon module > there is no sound from monitor > connected through hdmi wire. > But after running gdm, or > to be correct reinitializing driver > with a help of Xorg based application > everything comes back. But e.g. > after suspend/resume cycle it > again generates incorrect eld. > As a result dmesg shouts > NO SPEAKER ALLOCATION FOR ELD Thanks to developers, one year old problem of mine had been partially fixed, it's better then it was before! -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] New: UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 Bug ID: 153121 Summary: UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650 Product: Drivers Version: 2.5 Kernel Version: 4.8.0-040800rc2 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri at kernel-bugs.osdl.org Reporter: kostyarin.ivanov at gmail.com Regression: No Created attachment 228711 --> https://bugzilla.kernel.org/attachment.cgi?id=228711&action=edit dmesg Every boot I have got [ 40.074839] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, trying to reset the VCPU!!! [ 40.094753] [drm:uvd_v1_0_start [radeon]] *ERROR* UVD not responding, giving up!!! [ 41.121609] [drm:r600_ib_test [radeon]] *ERROR* radeon: fence wait timed out. [ 41.121654] [drm:radeon_ib_ring_tests [radeon]] *ERROR* radeon: failed testing IB on GFX ring (-110). [ 41.121679] [drm:radeon_resume_kms [radeon]] *ERROR* ib ring test failed (-110). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #1 from Kontantin Ivanov --- Created attachment 228721 --> https://bugzilla.kernel.org/attachment.cgi?id=228721&action=edit DRI_PRIME=1 glxinfo glxinfo for Radeon HD card -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #2 from Kontantin Ivanov --- Created attachment 228731 --> https://bugzilla.kernel.org/attachment.cgi?id=228731&action=edit glxinfo glxinfo for integrated Intel graphic card -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #3 from Kontantin Ivanov --- Created attachment 228741 --> https://bugzilla.kernel.org/attachment.cgi?id=228741&action=edit md5sum /lib/fimware/radeon/* -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 153121] UVD not responding, trying to reset the VCPU, ATI Mobility Radeon HD 5650
https://bugzilla.kernel.org/show_bug.cgi?id=153121 --- Comment #4 from Kontantin Ivanov --- Created attachment 228751 --> https://bugzilla.kernel.org/attachment.cgi?id=228751&action=edit sudo lspci -v -- You are receiving this mail because: You are watching the assignee of the bug.
