Bug 117591
Summary: | amdgpu: Black screens on A10-8700P (Carrizo) + R7 M260/M265 (Topaz) Combo | ||
---|---|---|---|
Product: | Drivers | Reporter: | Jani Väinölä (jani.vainola) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | RESOLVED UNREPRODUCIBLE | ||
Severity: | normal | CC: | alexdeucher, jockeyshortz |
Priority: | P1 | ||
Hardware: | x86-64 | ||
OS: | Linux | ||
Kernel Version: | 4.4.0-21-generic | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
dmesg
xrandr outputs before the black screen xrandr outputs after the black screen xorg.log Kernel log Output of lspci -vv |
Created attachment 215181 [details]
xrandr outputs before the black screen
This is what I get with xrandr commands before I get the black screen
Created attachment 215191 [details]
xrandr outputs after the black screen
This is what I get after the black screen (taken with ssh -X)
Created attachment 215201 [details]
xorg.log
Created attachment 215211 [details]
Kernel log
Created attachment 215221 [details]
Output of lspci -vv
Also, this machine worked flawlessly with the old fglrx 15.12 drivers. The troubles started when I did the upgrade to Ubuntu 16.04, but I did do fresh install of several distros to try it out. Does appending amdgpu.runpm=0 to the kernel command line in grub help? Yes it did! :) Perfect! Thanks! I have been running the laptop now for an hour and it is still working great. Now if I run lspci -vv I get: 04:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Topaz XT [Radeon R7 M260/M265] (rev 81) DeviceName: AMD Radeon (TM) R7 M260 Subsystem: Hewlett-Packard Company Topaz XT [Radeon R7 M260/M265] Physical Slot: 0-1 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 33 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at f0000000 (64-bit, prefetchable) [size=2M] Region 4: I/O ports at d000 [size=256] Region 5: Memory at ff300000 (32-bit, non-prefetchable) [size=256K] Expansion ROM at ff340000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: amdgpu Kernel modules: amdgpu Which basically means that the system can find it...so if I understand this correctly (after googling) this command disables the driver power control and this means that my discrete card is not automatically turned on? That suits me fine since I don't use it anyway. I guess I should leave the bug open so you can investigate why this discrete card is not running properly in normal mode? (BTW: I noticed now that my card is an R7 M260X according to the laptop-box). I have almost identical hardware, but a much different experience (kernel 4.6.2, 4.6.3, 4.6.4, 4.7-rc4 on Gentoo). For me, I rarely, if ever, get a non-black screen. Sometimes, when the machine has been running a while before rebooting, I get good video up until init gets loaded. During the many hours/days I beat my head against this problem, on very rare occasions everything would just start working. This problem is made worse by the fact that I have no other machines to connect with (I could still execute commands blindly, when lucky, or prepare scripts to do what I wanted with minimal chance for typos) and the fact that the keyboard appears to have issues. When I first got the machine, I used efifb, and it worked (and still works) perfectly all the time (except, of course, no 3d, and no brightness control, and no resolution switching in X). Among other things, I played with all the various power management toggles (including runpm) and nothing helped. I still can't get video on the console, although I have finally stumbled on a workaround for X that sometimes works OK (and may benefit from runpm=0, but I'd have to try again from a cold boot after long powerdown, since that's when the video acts up the most): xrandr --output eDP --crtc 1. Most of the time this causes video to appear in X. Sometimes that video is flickery, and sometimes toggling the crtc between 0 and 1 causes the flickering to disappear. Almost all the time when X is killed with crtc 1 enabled, the machine hangs, as well, but that's not really a big deal. Given the severe lack of documentation for drm, I haven't tried to make a console program with similar effect, and my attempts at tracing the kernel module to force "crtc 1" to be chosen by default have all ended in frustration. Then again, since the machine sometimes (even if very, very rarely) "just works", I'm not sure why I would have to swtich the crtc in the first place. Thomas, since your symptoms are different from Jani's, please file your own report, preferably at https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/AMDgpu . (In reply to Michel Dänzer from comment #11) > Thomas, since your symptoms are different from Jani's, please file your own > report, preferably at > https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/AMDgpu . I have done as requested, but I still think this bug covers it. Basically it amounts to "Broken Carrizo+Topaz [on HP?] power management issues lead to black or flickering screen with amdgpu". Since my latest working solution (boot into X w/ power management enabled, then reboot with it disabled) does not involve playing with the crtc switch, I am even more convinced of this. The only part that isn't covered is the system hang when killing X with crtc 1 enabled, but that's not something I ever cared about, anyway. I installed Kernel 4.15 on this machine now and it worked flawlessly. So I consider this bug resolved on 4.15. |
Created attachment 215171 [details] dmesg Getting black screens after fresh install on HP pavillion laptop with A10-8700P (Carrizo) + R7 M260/M265 (Topaz). Happened both in Ubuntu, Antergos and Debian (Testing). The computer is still running and I can access it and operate it via SSH. It just seems that the driver is unloaded in some way. The blackscreen can occur basically at any time after login. Sometimes it occurs directly after login, sometimes a bit later, but it hasn't been longer than 5 min.