Description
Andrew Reginato
2016-05-06 20:27:58 UTC
Please attach your xorg log and dmesg output. This bug affects me on Ubuntu 14.04, 15.10, 16.04, and Arch Linux. I too have the same AMD chip, A10-8700p, on an HP 17-g121wm. I can only get past the black screen if I boot into low-graphics mode with the nomodeset parameter. I have scoured countless online resources looking for a solution to this problem. I hope someone knowledgeable and able to do something about it takes notice of this page and works on the bug. Hi Josh, since the original reporter didn't, perhaps you can at least provide your xorg log and dmesg output? Created attachment 125945 [details]
4.7.2 kernel with 2.49 glib2. The display did not go on again after resuming from suspend.
Created attachment 125946 [details]
4.7.1 kernel with 2.49 glib2. The display blanked temporarily, function restored for 10 minutes after switching to TTY and back.
Created attachment 125947 [details]
4.7.1 kernel with 2.49 glib2. The display blanked for good after blanking temporarily.
APU: AMD FX-8800P (Carrizo, Volcanic Island) GPU: AMD Radeon R7 M360 (Topaz XT, Volcanic Island) OS: Archlinux X: 1.18.4 DE: Gnome 3.20, happens with other (KDE, XFCE, i3) DM: GDM 3.20 Kernel: Various stable and rc releases 4.4 to 4.7.2 Glib2: 2.48.1 Problem: Screen blanks randomly. It usually happens with cold machine immediately after loading amdgpu module. After resume from suspend the screen turns on and blanks after a few seconds (always less than 1 minute). Even if the booting is successful it will happen at any time after that. The machine almost never runs for more than 30 minutes without blanking. Connecting VGA or HDMI monitor causes immediate blank but starting with connected monitors or disconnecting them doesn't. Once screen blanks there is no way how to get it working (switching to console, playing with xrandr etc.) except for suspend (the few seconds is not worth it). It does not seem to affect console unless X is started. Kernel: 4.5rc6 (and maybe some other) Glib2: 2.48.1, 2.49.5.11.gb82682e-1 Problem: It occurs only on cold boot, after connecting external monitor (didn't test yet with Glib2 2.49) and a longer suspend (a few minutes). Kernel: 4.7.1 Glib2: 2.49.5.11.gb82682e-1 Problem: Screen blanked once after 2 hours but turned back on after switching to console and back to X. After 10 minutes it blanked for good. Kernel: 4.7.2 Glib2: 2.49.5.11.gb82682e-1 Problem: Ran for 1h 30m without any issue. Blanked after suspending for 15 minutes and resuming. So maybe Glib2 related problem? (In reply to Tom from comment #7) > Kernel: 4.7.1 > Glib2: 2.49.5.11.gb82682e-1 > Problem: Screen blanked once after 2 hours but turned back on after > switching to console and back to X. After 10 minutes it blanked for good. > > Kernel: 4.7.2 > Glib2: 2.49.5.11.gb82682e-1 > Problem: Ran for 1h 30m without any issue. Blanked after suspending for 15 > minutes and resuming. Please attach the corresponding Xorg log file. Created attachment 125978 [details]
Xorg.log: Screen blanked during boot.
Tom, does your blanking in X also happen with the modesetting driver instead of the amdgpu driver? (In reply to Michel Dänzer from comment #10) > Tom, does your blanking in X also happen with the modesetting driver instead > of the amdgpu driver? I'm not sure how to do this. I tried setting it as a driver in Xorg.conf and the screen blanked as usual. Although Xorg.log listed only modesetting driver the amdgpu module was loaded. Blacklisting the module prevents X from starting. I was also unable to replicate the success with 4.7.2 kernel and 2.49 glib2. Now it blanks within a few minutes. It seems I was just lucky that day. (In reply to Tom from comment #11) > (In reply to Michel Dänzer from comment #10) > > Tom, does your blanking in X also happen with the modesetting driver instead > > of the amdgpu driver? > > I'm not sure how to do this. I tried setting it as a driver in Xorg.conf and > the screen blanked as usual. Although Xorg.log listed only modesetting > driver the amdgpu module was loaded. Blacklisting the module prevents X from > starting. > > I was also unable to replicate the success with 4.7.2 kernel and 2.49 glib2. > Now it blanks within a few minutes. It seems I was just lucky that day. Don't worry about the kernel module. That should be loaded regardless of what X driver you use. Just make sure modesetting is used for X. (In reply to Alex Deucher from comment #12) > Don't worry about the kernel module. That should be loaded regardless of > what X driver you use. Just make sure modesetting is used for X. Yeah, modesetting was used. I'll attach the log. Created attachment 126013 [details]
Modesetting driver
I did some more testing with kernel 4.8rc5 and it seems it is not related to X after all. Cold boot to console has exactly the same issues as cold boot to X (screen blanks). The last message I see on the screen is “fb: switching to amdgpudrmfb from EFI VGA” then it turns off and on again but it is blank. So far console didn't blank after successful start like X does unless I suspended it. This affects me as well. HP Pavillion A10-8700P - Carrizo - R6 Linux Manjaro Daniella 16.06 w. kernel 4.4 I can't wait to see this resolved. I can observe that the performance is quite impressive with this AMDGPU driver (before the black screen happens...) compared to the proprietary catalyst display driver. I did some more testing with AMDGPU-PRO driver (from AUR). It seems to work without those issues but I get only a mesh up of previous session screen after reboot or pink and white lines after cold boot. This bug did not affect 4.6.x and earlier, it started with: commit 70eced9b2e05f38274ebe8ad91c472bb684fa82a That commit enables new features on the Carrizo, - adev->cg_flags = 0; + adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG | + AMD_CG_SUPPORT_GFX_MGLS | + AMD_CG_SUPPORT_GFX_RLC_LS | + AMD_CG_SUPPORT_GFX_CP_LS | + AMD_CG_SUPPORT_GFX_CGTS | + AMD_CG_SUPPORT_GFX_MGLS | + AMD_CG_SUPPORT_GFX_CGTS_LS | + AMD_CG_SUPPORT_GFX_CGCG | + AMD_CG_SUPPORT_GFX_CGLS; So it should be relatively easy to isolate the problem by stepping through those features one by one to isolate which of those flags is triggering the problem. I'm available to test semi-official patches until the problem is properly fixed. In the meantime I've reverted the patch on my 4.7.6 kernel and have run for over two days without encountering the problem. Tom, looks like there are issues with clock gating on Carrizo. If they're using the pro driver (dkms + closed GL/etc) there are known issues with CGCG and the UMD. Try booting with amdgpu.cg_mask=0xFFFFFFFB to disable CGCG. Note this will also disable power gating so battery life/temp might be an issue :-/ I unfortunately don't have an 88xx series Carrizo (mine is an A12-9800) and with the all open UMD I haven't noticed any problems with PG/CG. Nicolai has an 8800 I think we should involve him here. Does disabling powerplay help? E.g., set amdgpu.powerplay=0 on the kernel command line in grub? or vice versa, depending on whether you were using powerplay before or not, amdgpu.powerplay=1 (In reply to Alex Deucher from comment #22) > or vice versa, depending on whether you were using powerplay before or not, > amdgpu.powerplay=1 Powerplay affects only temperature, all the issues persist. Have you tried the cg_mask I suggested? (In reply to Tom St Denis from comment #24) > Have you tried the cg_mask I suggested? Yes I did. The way the screen is messed up changes (it stays the same without the param), but it is still broken. (In reply to Kelly Anderson from comment #18) > This bug did not affect 4.6.x and earlier, it started with: > > commit 70eced9b2e05f38274ebe8ad91c472bb684fa82a > > That commit enables new features on the Carrizo, > > - adev->cg_flags = 0; > + adev->cg_flags = AMD_CG_SUPPORT_GFX_MGCG | > + AMD_CG_SUPPORT_GFX_MGLS | > + AMD_CG_SUPPORT_GFX_RLC_LS | > + AMD_CG_SUPPORT_GFX_CP_LS | > + AMD_CG_SUPPORT_GFX_CGTS | > + AMD_CG_SUPPORT_GFX_MGLS | > + AMD_CG_SUPPORT_GFX_CGTS_LS | > + AMD_CG_SUPPORT_GFX_CGCG | > + AMD_CG_SUPPORT_GFX_CGLS; > > So it should be relatively easy to isolate the problem by stepping through > those features one by one to isolate which of those flags is triggering the > problem. > > I'm available to test semi-official patches until the problem is properly > fixed. In the meantime I've reverted the patch on my 4.7.6 kernel and have > run for over two days without encountering the problem. I tried 4.6, 4.5 and 4.4 kernels and all stable releases had this issue. Only some 4.5 rc releases work for me. Created attachment 127123 [details] [review] possible fix Does the attached patch fix the issue? (In reply to Alex Deucher from comment #27) > Created attachment 127123 [details] [review] [review] > possible fix > > Does the attached patch fix the issue? The patch does not fix the problem. Linux 4.9rc4 seems to fix the suspend issue, but booting up is still buggy. Created attachment 127827 [details] attachment-6932-0.html Indeed, I am currently trying 4.9 rc-3 right now and it has been running for more than 30 minutes now. This is exciting time. Crossing all fingers... On Nov 7, 2016 16:05, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 29 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c29> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom > <tom.vycital@gmail.com> * > > Linux 4.9rc4 seems to fix the suspend issue, but booting up is still buggy. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > The suspend issue is still present, it just doesn't happen so often. I also noticed another thing. It seems to be impossible to cold boot with 4.9rc4, I have to boot some other kernel or Windows and then reboot to successfully boot with 4.9rc4. So far no random blanking, but it already happened before, that it ran for hours without blanking. Created attachment 127842 [details] attachment-7364-0.html I confirm still present on rc4. Guess I only got lucky on rc3 for 45 minutes. On Nov 8, 2016 03:10, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 31 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c31> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom > <tom.vycital@gmail.com> * > > The suspend issue is still present, it just doesn't happen so often. > I also noticed another thing. It seems to be impossible to cold boot with > 4.9rc4, I have to boot some other kernel or Windows and then reboot to > successfully boot with 4.9rc4. > So far no random blanking, but it already happened before, that it ran for > hours without blanking. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > Created attachment 127843 [details] attachment-7466-0.html Issue == screen turning black after a while. On Nov 8, 2016 08:35, "Patrick Laurin" <plaurin@inocybe.ca> wrote: > I confirm still present on rc4. Guess I only got lucky on rc3 for 45 > minutes. > > On Nov 8, 2016 03:10, <bugzilla-daemon@freedesktop.org> wrote: > >> *Comment # 31 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c31> on >> bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom >> <tom.vycital@gmail.com> * >> >> The suspend issue is still present, it just doesn't happen so often. >> I also noticed another thing. It seems to be impossible to cold boot with >> 4.9rc4, I have to boot some other kernel or Windows and then reboot to >> successfully boot with 4.9rc4. >> So far no random blanking, but it already happened before, that it ran for >> hours without blanking. >> >> ------------------------------ >> You are receiving this mail because: >> >> - You are on the CC list for the bug. >> >> I just installed fresh Ubuntu 16.04 again on my Pavilion 15-ab188ca (AMD A10-8700P). This time I installed current mainline kernel 4.9 rc-6. Still no luck. Kernel 4.9rc7 seems very stable after it boots up. But overheats a lot and booting up often takes several attempts. Created attachment 128273 [details] attachment-3204-0.html Still got black screen after grub boot, event with 4.9 rc-7. Sometime I have time to play around for 5 minutes, sometime it turns black almost immediately. The screen is still powered on and laptop still running, just plain black image. Sometimes, when it turns black, it's like I can see the image drop down the screen in a fraction of a second. On 29 November 2016 at 07:32, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 35 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c35> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom > <tom.vycital@gmail.com> * > > Kernel 4.9rc7 seems very stable after it boots up. But overheats a lot and > booting up often takes several attempts. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > I also have an HP g121wm laptop with an A10 8700p apu/gpu chipset (carrizo R6). Ever since the removal of the catalyst driver and replacement with the Xorg amdgpu driver at least 6 months ago, shortly after the kernel loads and detects hardware the screen blanks, the keyboard doesn't respond, although numlock and capslock are working, but any of the alt+ctl or reisub commands won't work, however the system does continue to load in the background. I suppose this occurs when kernel mode setting kicks in. I can only get a working screen using nomodeset in the command line, which limits me to an 800x600 fb screen. AMD support tells me there is no support for R6 graphics in amdgpu pro, but an Xorg support person tells me that their Xorg version of amdgpu (not pro) does support this carrizo chipset. I've tried the latest Xorg amdgpu to no avail. Apparently, the basic Xorg.ati driver won't work with this chipset. I even get conflicting accounts of how to set up this card with the vesa driver! I haven't been able to achieve it and I'm a 24 year Linux user! I've tried this with all kernels since 4.3 and am now running 4.8.11 and the problem remains. BTW I run PClinuxos with KDE. Is this even a bug or just an unusual configuration issue? I don't have the amdgpu driver installed at the moment, but here are my dmesg and Xorg.log files. Created attachment 128781 [details]
Xorg.log
Xorg.log of working screen with nomodeset using fb.
Created attachment 128782 [details]
dmesg
dmesg of 1/05/17
[ 12.873675] [drm:amdgpu_init [amdgpu]] *ERROR* VGACON disables amdgpu kernel modesetting. amdgpu isn't loaded so it's kinda hard to support that config. Why not blacklist amdgpu and remove your dm/wm from init. Then ssh in and modprobe it while running 'dmesg -w'. That way if your system hangs you might still get some output. [ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-4.8.11-pclos1 root=UUID=4507d394-b92d-4d28-94a0-45eb537f32cb ro splash quiet resume=UUID=8da19a6f-6a18-46a2-920e-f9f81125e74b nomodeset vga=788 Remove vga=788 from your kernel command line. I had already removed vga=788 from command line. It makes no difference. It was meant just to set the display resolution for grub before the kernel boots. However, grub2 now requires other instructions. New info to report. I reinstalled amdgpu and created the xorg.conf file. This was the first time that the installer (XFdrake) reported the resolution correctly and I didn't have to manually configure it. Now I get a randomly flashing screen and still no keyboard input. Before, it was a blank screen with the backlight on, now the light is on/off irregularly every few seconds. I'm not sure this is progress, but perhaps it is a clue for someone who knows the driver well. Amdgpu eems to be fixed since my last testing! Kernel 4.9.1 Mesa 13.0.3 LibDrm 2.4.74 Created attachment 128830 [details] attachment-2821-0.html I confirm I didn't get the black screen after more than 20 minutes while trying kernel 4.10. This is GREAT new !!! But, My screen was rotating by itself in a random manner, after a couple of minutes. (Counter-clockwise after 15 minutes, counter-clockwize again after 5 minutes, etc...) Not sure if related tough... On 9 January 2017 at 02:02, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 43 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c43> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Kelly > Anderson <kelly@xilka.com> * > > Amdgpu eems to be fixed since my last testing! > > Kernel 4.9.1 > Mesa 13.0.3 > LibDrm 2.4.74 > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > Just to rule out the low hanging fruit. There was no celebratory champagne involved in the screen rotation issues right? :-) (EUSERDRUNKONFLOOR error happens from time to time) What does xrandr report normally and while inverted? Created attachment 128831 [details] attachment-3608-0.html Heh, nan, EUSERDRUNKONFLOOR error usually rotates both ways and displays some blurring effects! I'm not near the machine having this behaviour i'll give feed back asap on this. On 9 January 2017 at 10:18, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 45 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c45> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Tom St > Denis <tom.stdenis@amd.com> * > > Just to rule out the low hanging fruit. There was no celebratory champagne > involved in the screen rotation issues right? :-) (EUSERDRUNKONFLOOR error > happens from time to time) > > What does xrandr report normally and while inverted? > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > Created attachment 128840 [details]
xorg log after trying to boot with amdgpu enabled
Tried booting using new 4.8.16 kernel. Back to blank screen.
Created attachment 128841 [details]
latest xorg.conf file for amdgpu
The xorg.conf renamed .new so it won't work. Created by XFdrake.
(In reply to Kelly Anderson from comment #43) > Amdgpu eems to be fixed since my last testing! > > Kernel 4.9.1 > Mesa 13.0.3 > LibDrm 2.4.74 I spoke too soon...it's black screening as per usual. Maybe I had booted into 4.7.10 and though I was running under 4.9.1. In any case my most reliable kernel to avoid this problem is 4.7.10. Has anyone read my xorg.log and xorg.conf files? Two things I noticed that might be relevant. There is a Screen1, but not a Screen0 in the conf file. Should XFdrake have created this file designating Screen0? The log file shows that modesetting isn't supported. Why? Is this problem just a faulty configuration problem? 4.10.0-rc4 is looking good. whereas I had some screen glitches with 4.10.0-rc3 and lost pointer cursor, all of that seems to have been fixed with rc4. As far as BLACK screen syndrome...so far I've had none of that with either rc3 or rc4. 4.10-RC4 is working great! I'm happy. great job! Tried to look at the latest patches in the Kernel not sure what solved it / what was the issue (I'm curious, want to understand things :) There's something wrong tough, that's probably unrelated, is that the mouse gets invisible after coming back from sleep. It's still working as I see things get selected when I move it around, but it's a ghost. (In reply to Patrick Laurin from comment #52) > There's something wrong tough, that's probably unrelated, is that the mouse > gets invisible after coming back from sleep. That should be fixed by https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69bcc0b7140c30de552aa3ef08322295862e8e2f , which will be in 4.10-rc6. Created attachment 129237 [details] attachment-14139-0.html Interesting enough, I started having screen blackouts again on RC6, but RC4 is fine, I can use it all day without issues. On 24 January 2017 at 20:13, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 53 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c53> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Michel > Dänzer <michel@daenzer.net> * > > (In reply to Patrick Laurin from comment #52 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c52>)> There's something wrong tough, that's probably unrelated, is that the mouse > > gets invisible after coming back from sleep. > > That should be fixed byhttps://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=69bcc0b7140c30de552aa3ef08322295862e8e2f > , which will be in 4.10-rc6. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > I kind of have the same laptop, manufactured for a different region. I can confirm it doesn't work well with 4.10 RC6 (for me it blanks before the login screen). 4.10 RC5 works great, although it gets really hot at times. I tried 4.10 RC7, and I could successfully login with this kernel. But after 5 mins of using it, I had a blackout again :/ . Guess I'll stick to RC5 for a while Created attachment 129489 [details] attachment-22966-0.html I was finally able to get another laptop from my company. No more AMDGPU for me! Core i3 with Intel HD Graphics 520 = Heaven But hey, i'll still follow that thread :) On 9 February 2017 at 20:18, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 56 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c56> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Jaime > Rodrigo <jarc1896@gmail.com> * > > I tried 4.10 RC7, and I could successfully login with this kernel. But after 5 > mins of using it, I had a blackout again :/ . Guess I'll stick to RC5 for a > while > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > The only deltas I can see from rc4 to now are in powerplay... so does booting with amdgpu.powerplay=0 help? Sadly it doesn't do any good. I get a blackout anyways. Tried it (amdgpu.powerplay=0) also on RC5 (which, as I said before, works good) and it makes it blackout. I believe the problem lies on Crossfire or something like that, since it makes both cards run @100% all the time. Tried every RC8 and it blackouts too. Official 4.10 release boots into low graphics mode by default, and theres no kernel driver in use (nor radeon or amdgpu). Installed AMDGPUPRO and I get stuck in the logging screen (after logging successfully it goes back to the logging screen and so on), and still using low graphics mode (In reply to Jaime Rodrigo from comment #60) > Tried every RC8 and it blackouts too. Official 4.10 release boots into low > graphics mode by default, and theres no kernel driver in use (nor radeon or > amdgpu). Installed AMDGPUPRO and I get stuck in the logging screen (after > logging successfully it goes back to the logging screen and so on), and > still using low graphics mode Tried RC8* Don't know how and why but I'm trying now the latest CentOS 7.3 (installed with kde + development tools) and no random black screen, no low resolution, no false start, no proprietary Crimson driver installed (Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / M340/M360]). It's the first distro that it works out of the box at now (tried OpenSUSE Tumbleweed, Fedora 25, Ubuntu 16.04, Arch). (In reply to poggif from comment #62) > Don't know how and why but I'm trying now the latest CentOS 7.3 (installed > with kde + development tools) and no random black screen, no low resolution, > no false start, no proprietary Crimson driver installed (Display controller: > Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / > M340/M360]). It's the first distro that it works out of the box at now > (tried OpenSUSE Tumbleweed, Fedora 25, Ubuntu 16.04, Arch). No, again a false start today. (In reply to poggif from comment #63) > (In reply to poggif from comment #62) > > Don't know how and why but I'm trying now the latest CentOS 7.3 (installed > > with kde + development tools) and no random black screen, no low resolution, > > no false start, no proprietary Crimson driver installed (Display controller: > > Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265 / > > M340/M360]). It's the first distro that it works out of the box at now > > (tried OpenSUSE Tumbleweed, Fedora 25, Ubuntu 16.04, Arch). > > No, again a false start today. Which version of the kernel does it have? Was an HP Pavilion 17-g154nl, with a CentOS 7.3 (1611) and 3.10.0-514.el7.x86_64. (In reply to poggif from comment #65) > Was an HP Pavilion 17-g154nl, with a CentOS 7.3 (1611) and > 3.10.0-514.el7.x86_64. Aaah, idk when amdgpu appeared in the kernel, perhaps it wasn't even present there. Is there a way to disable the integrated GPU from the PCI devices? I also have an R7 M360 dedicated GPU on board, I wonder if it would work if only the dedicated and supported GPU would appear... my laptop is an hp pavilion 15-ab104nh (In reply to Tamás Tóth from comment #66) > (In reply to poggif from comment #65) > > Was an HP Pavilion 17-g154nl, with a CentOS 7.3 (1611) and > > 3.10.0-514.el7.x86_64. > > Aaah, idk when amdgpu appeared in the kernel, perhaps it wasn't even present > there. RH backports newer code to the kernels they are using in RHEL/Centos for hardware enablement so the kernel version is largely meaningless with respect to when something went upstream. > > Is there a way to disable the integrated GPU from the PCI devices? I also > have an R7 M360 dedicated GPU on board, I wonder if it would work if only > the dedicated and supported GPU would appear... > > my laptop is an hp pavilion 15-ab104nh Not likely. Generally the dGPU on hybrid laptops is not connected to any displays. It is just for render off-load. Hi, I made a fresh install of Archlinux (GNU/Linux kernel 4.13.11) on a HP Probook 455 G3 with A10-8700p APU and 1x8GB RAM (no dedicated GPU) with the default driver (amdgpu open source driver): I experience the issue described by Andrew who opened the thread in May 2016. The black screen appears at a certain step of the boot. After a cycle of suspend?resune (usually 3 or 4) the display turns right and is stable (if no X session is started...) I can confirm the issue is not linked to X since it is not installed. The only messages for amdgpu in journalctl are amdgpu: [powerplay] min_core_set_clock not set but amdgpu.powerplay=0 is not recognized any longer: kernel: amdgpu: unknown parameter 'powerplay' ignored. Any (new) idea ? Can anybody explain what will kermels 4.14 and especially 4.15 will bring us (carrizo users)? (In reply to Charly from comment #68) > Hi, > > I made a fresh install of Archlinux (GNU/Linux kernel 4.13.11) on a HP > Probook 455 G3 with A10-8700p APU and 1x8GB RAM (no dedicated GPU) with the > default driver (amdgpu open source driver): I experience the issue described > by Andrew who opened the thread in May 2016. The black screen appears at a > certain step of the boot. After a cycle of suspend?resune (usually 3 or 4) > the display turns right and is stable (if no X session is started...) I can > confirm the issue is not linked to X since it is not installed. The only > messages for amdgpu in journalctl are > > amdgpu: [powerplay] min_core_set_clock not set > > but amdgpu.powerplay=0 is not recognized any longer: > > kernel: amdgpu: unknown parameter 'powerplay' ignored. > > Any (new) idea ? > > Can anybody explain what will kermels 4.14 and especially 4.15 will bring us > (carrizo users)? There seems to be no solution. I tried several params, combinations of various things (some even led to quite serious file system corruption) but it had no positive effect whatsoever. Playing with powerplay/dpm etc. just made my laptop overheat a lot. I had some luck with amdgpu-pro in 2016, but it was even less usable. It always booted successfully but there was mostly pinkish garbage on the screen (±75%) although I could see the desktop at some places (±25%) and therefore somewhat use it (login and reboot). Not sure if it is better nowadays, I think it's worth a try. Since this issue is here at least since 4.4 I highly doubt 4.14 or 4.15 will bring the solution. this bug/thread looks very simillar to what i ahve been expiriencing once i tried to move from fglx + fedora 22 to over amdgpu + fedora27. Please take a look@ the bug i filed : https://bugzilla.redhat.com/show_bug.cgi?id=1520676 // i'll shamelessly x-ref these 2 threads. adding amdgpu.cg_mask=0xFFFFFFFB semed to keep boot messages for a bit longer, but then again - black screen of beauty :( adding powerplay) made no difference Created attachment 136007 [details]
log files with amdgpu.cg_mask set
i also noticed that the grub screen is in high resolution (probably 1024 ) without me specifying any params. Also the boot messages are flying in the high resolution, until something is loaded and then all goes dark Initial results with 4.15rc2 looks good. In thirty minutes or so of usage no black screens. with 4.14.4 it would have black screened by now. Kernel config snippet: CONFIG_DRM_AMD_DC=y CONFIG_DRM_AMD_DC_PRE_VEGA=y # CONFIG_DRM_AMD_DC_FBC is not set CONFIG_DRM_AMD_DC_DCN1_0=y # CONFIG_DEBUG_KERNEL_DC is not set 4.15rc2 has been working for me for over a day now without a problem I can see terminals now on init 3 thanks to Kelly's config. Still a nogo with X. And some odd messages during the boot - filed https://bugs.freedesktop.org/show_bug.cgi?id=104206 4.15rc3 also seems to be fine with respect to this problem. Created attachment 136125 [details] attachment-18449-0.html Kelly, Maybe RADV would work? https://www.phoronix.com/scan.php?page=article&item=amd-open-vulkan&num=1 Also. Is a new amd driver out already? // sorry im traveling at the moment On Dec 11, 2017 11:24 AM, <bugzilla-daemon@freedesktop.org> wrote: > *Comment # 77 <https://bugs.freedesktop.org/show_bug.cgi?id=95306#c77> on > bug 95306 <https://bugs.freedesktop.org/show_bug.cgi?id=95306> from Kelly > Anderson <kelly@xilka.com> * > > 4.15rc3 also seems to be fine with respect to this problem. > > ------------------------------ > You are receiving this mail because: > > - You are on the CC list for the bug. > > Hi It looks fine for me also !! On my carrizo A10-8700p rev c5 (probook 455 g3), when booting archlinux with kernel 4.15-rc3, journalctl raises an error reported in bug 104206 4.15rc4 also seems to work fine with respect to this problem. 4.15rc5 is also working fine with respect to this problem. Let's assume this is fixed in 4.15-rc. Anyone except Andrew Reginato, if you're still seeing an issue with that or newer, please file your own report. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.