| Bug ID | 101499 |
|---|---|
| Summary | Black screen when detaching HDMI cable (AMD A10-9620P) |
| Product | DRI |
| Version | unspecified |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | carlo@caione.org |
Created attachment 132061 [details]
journal_from_boot_to_HDMI_cable_detaching
We are working with new laptops that have the AMD Bristol Ridge
chipset with this SoC:
AMD A10-9620P RADEON R5, 10 COMPUTE CORES 4C+6G
When the HDMI cable is attached and then detached, the internal panel goes
black and the only way to have it back is switching to another TTY and then
back to xorg or doing 'xset dpms force off; xset dpms force on'.
This is reproducible also on the ~agd5f/drm-next-4.13-wip branch.
In the attachment the whole journal when booting the kernel compiled from
~agd5f/drm-next-4.13-wip, landing in xorg and then attaching and detaching =
the
HDMI cable.
Created attachment 132062 [d=
etails]
dmps_off_on
This is what we have in the log when we give 'xset dpms force off; xset dpms
force on'.
> Jun 19 17:09:49 endless kernel: [dr=
m] Detected VRAM RAM=3D32M, BAR=3D32M
I suspect the core problem is that there's only 32 MB of VRAM available. Is=
it
possible to increase this in the BIOS setup?
> I suspect the core problem is that =
there's only 32 MB of VRAM available.
> Is it possible to increase this in the BIOS setup?
It is not. There is nothing in the BIOS related to VRAM.
(In reply to Carlo Caione from comment #3) > There is nothing in the BIOS related to VRAM. FWIW, it wouldn't say "VRAM" but rather "integrated graphics= memory" or something like that.
> FWIW, it wouldn't say "VRAM&qu=
ot; but rather "integrated graphics memory" or
> something like that.
Yeah :) Let me put this way: there is nothing in the BIOS related to graphic
controller / GPU / video in general.
FWIW the BIOS is InsydeH20 v0.09
Also I guess you are looking at the wrong controller: [ 2.111381] amdgpu 0000:00:01.0: VRAM: 32M 0x000000F400000000 - 0x000000F401FFFFFF (32M used) [ 2.111390] [drm] Detected VRAM RAM=3D32M, BAR=3D32M [ 2.111511] [drm] amdgpu: 32M of VRAM memory ready [ 6.560772] amdgpu 0000:03:00.0: VRAM: 2048M 0x000000F400000000 - 0x000000F47FFFFFFF (2048M used) [ 6.560785] [drm] Detected VRAM RAM=3D2048M, BAR=3D256M [ 6.560805] [drm] amdgpu: 2048M of VRAM memory ready So I guess in this laptop there is an integrated controller with 32MB of VR= AM and the GPU with 2GB?
There are two GPUs, the integrated one in the APU (Carrizo fam= ily) and a dedicated one (Polaris 12 family). Xorg is using the integrated one, and there's no way around that, because only the integrated GPU has display out= puts hooked up. The dedicated GPU could only be used via PRIME render offloading= .
Interesting. Ok then, back to square one: no BIOS options to t= weak the integrated graphics memory / controller. On a side note: is it normal so many error messages in the journal? Like: kernel: amdgpu 0000:00:01.0: ffff9cccade4d800 pin failed kernel: [drm:amdgpu_crtc_page_flip_target [amdgpu]] *ERROR* failed to pin n= ew abo buffer before flip gdm-Xorg-:0[672]: (WW) AMDGPU(0): flip queue failed: Cannot allocate memory gdm-Xorg-:0[672]: (WW) AMDGPU(0): Page flip failed: Cannot allocate memory gdm-Xorg-:0[672]: (EE) AMDGPU(0): present flip failed ... gdm-Xorg-:0[672]: (WW) AMDGPU(0): get vblank counter failed: Invalid argume= nt or kernel: amdgpu: [powerplay] min_core_set_clock not set
(In reply to Carlo Caione from comment #8) > On a side note: is it normal so many error messa= ges in the journal? Like: >=20 > kernel: amdgpu 0000:00:01.0: ffff9cccade4d800 pin failed > kernel: [drm:amdgpu_crtc_page_flip_target [amdgpu]] *ERROR* failed to = pin > new abo buffer before flip > gdm-Xorg-:0[672]: (WW) AMDGPU(0): flip queue failed: Cannot allocate m= emory > gdm-Xorg-:0[672]: (WW) AMDGPU(0): Page flip failed: Cannot allocate me= mory > gdm-Xorg-:0[672]: (EE) AMDGPU(0): present flip failed > ... > gdm-Xorg-:0[672]: (WW) AMDGPU(0): get vblank counter failed: Invalid a= rgument I think all of these are triggered by VRAM being too small to fit the scano= ut buffers covering the laptop panel + external monitor. > kernel: amdgpu: [powerplay] min_core_set_clock n= ot set Not sure about this one, might be harmless.
> I think all of these are triggered =
by VRAM being too small to fit the
> scanout buffers covering the laptop panel + external monitor.
Probably I'm missing something, but when the HDMI is connected everything w=
orks
fine, with the scanout buffer correctly displayed on the laptop panel +
external monitor. The problem starts when we _disconnect_ the HDMI cable.
Also if it was a problem with VRAM being too small, why toggling the DPMS m=
akes
the laptop panel working fine again?
(In reply to Carlo Caione from comment #10) > Probably I'm missing something, but when the HDM= I is connected everything > works fine, with the scanout buffer correctly displayed on the laptop = panel > + external monitor. The problem starts when we _disconnect_ the HDMI c= able. At least some of the errors you referenced in comment 8 already happen before that. They're related to failed attempts at page flipping. xf86-video-amdgpu manages to chug along regardless. When you unplug the HDMI cable is presumably when > Jun 19 17:10:31 endless gdm-Xorg-:0[672]: (EE) A= MDGPU(0): failed to set mode: Invalid argument appears, i.e. drmModeSetCrtc() fails, presumably (not 100% sure about this = part though) because the new, smaller scanout buffer cannot fit into VRAM while = the old, larger one is still being scanned out. > Also if it was a problem with VRAM being too sma= ll, why toggling the DPMS > makes the laptop panel working fine again? Toggling DPMS off disables scanout, which allows the old scanout buffer to = be moved out of VRAM, so the new one can be moved in. Some details might differ from the above, but that should be roughly what's happening.
Created =
attachment 132081 [details]
Corruption using xf86-video-amdgpu HEAD
Interesting. Thank you for explaining this and your time.
I just tried the HEAD of xf86-video-amdgpu and now instead of having a black
screen I have the image corruption as shown in the picture.
Anything I can do to debug / have this fixed? Is it something I need to fix
with the ODM (acer)?
> I just tried the HEAD of xf86-video=
-amdgpu and now instead of
> having a black screen I have the image corruption as shown
> in the picture.
Just FYI this is due to commit b09fde0d81 ("Use reference counting for=
tracking
KMS framebuffer lifetimes").
(In reply to Carlo Caione from comment #12) > I just tried the HEAD of xf86-video-amdgpu and n= ow instead of having a black > screen I have the image corruption as shown in the picture. Without seeing the corresponding Xorg log, I guess that's just a different symptom triggered by the same issue. > Anything I can do to debug / have this fixed? We need to make scanout work with buffers outside of VRAM somehow. I've kic= ked off an internal discussion about this. With an amd-staging-* kernel branch and DC enabled, you can try tweaking dce_v11_0_crtc_do_set_base to pass AMDGPU_GEM_DOMAIN_GTT instead of / in addition to AMDGPU_GEM_DOMAIN_VRAM to amdgpu_bo_pin. The DC code should alr= eady handle this correctly, but we're not sure whether or not there are addition= al constraints on system memory used for scanout. If there are, it probably wo= n't work correctly yet. > Is it something I need to fix with the ODM (acer= )? If you can get a BIOS which allows setting up larger VRAM, that might allow= you to move forward faster.
Created attach= ment 132118 [details] journal_HDMI_detaching_corruption > Without seeing the corresponding Xorg log, I gue= ss that's just > a different symptom triggered by the same issue. Attached the log. Yeah, not much different. > With an amd-staging-* kernel branch and DC enabl= ed, you can try tweaking > dce_v11_0_crtc_do_set_base to pass AMDGPU_GEM_DOMAIN_GTT instead of / = in > addition to AMDGPU_GEM_DOMAIN_VRAM to amdgpu_bo_pin. The DC code should > already handle this correctly, but we're not sure whether or not there= are > additional constraints on system memory used for scanout. If there are= , it > probably won't work correctly yet. I tried amd-staging-4.11 and interestingly dce_v11_0_crtc_do_set_base is ca= lled only when DC is disabled. When DRM_AMD_DC=3Dy the function is never called. I tried also to make the s/AMDGPU_GEM_DOMAIN_VRAM/AMDGPU_GEM_DOMAIN_GTT/ ch= ange with DC disabled. What I get is that I have some kind of intermittent displ= ay corruption when _connecting_ the HDMI cable on both the screens but on detaching at least everything is fine on the laptop panel.
(In reply to Carlo Caione from comment #15) > > With an amd-staging-* kernel branch and DC = enabled, you can try tweaking > > dce_v11_0_crtc_do_set_base to pass AMDGPU_GEM_DOMAIN_GTT instead = of / in > > addition to AMDGPU_GEM_DOMAIN_VRAM to amdgpu_bo_pin. [...] > I tried amd-staging-4.11 and interestingly dce_v11_0_crtc_do_set_base = is > called only when DC is disabled. Right, sorry, with DC you need to tweak dm_plane_helper_prepare_fb instead.=
Created attachment 132130 [details] dm_plane_helper_prepare_fb with AMDGPU_GEM_DOMAIN_GTT > Right, sorry, with DC you need to tweak dm_plane= _helper_prepare_fb instead. Yup, I tried this but not much luck. In attachment what I get when using AMDGPU_GEM_DOMAIN_GTT. Using AMDGPU_GEM_DOMAIN_GTT | AMDGPU_GEM_DOMAIN_VRAM= is pretty much the same but the cursor is correctly displayed (even though I cannot move it). The log is filled with: [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR* Failed to pin framebuffer /me scratch his head
We have found another laptop with exactly the same issue (and = again 32MB of VRAM for the embedded video controller). We have also requested to ACER a n= ew BIOS with a bigger size of VRAM, waiting to receive it (hopefully). Any news about the internal discussion about this issue? We are available to test any fix / workaround / proposal :) Thanks,
No news I'm afraid. (In reply to Carlo Caione from com= ment #17) > In attachment what I get when using AMDGPU_GEM_D= OMAIN_GTT. [...] > [drm:dm_plane_helper_prepare_fb [amdgpu]] *ERROR= * Failed to pin framebuffer Do you also get those errors with AMDGPU_GEM_DOMAIN_GTT? If so, it might be interesting to track down the origin of the errors. Otherwise, it looks like there's still something missing.
| What | Removed | Added |
|---|---|---|
| Attachment #132130 is obsolete | 1 |
Created attachment 132281 [details] dm_plane_helper_prepare_fb with AMDGPU_GEM_DOMAIN_GTT > Do you also get those errors with AMDGPU_GEM_DOM= AIN_GTT? If so, it might be=20 > interesting to track down the origin of the errors. Otherwise, it look= s like > there's still something missing. The error is not reproducible anymore using the latest amd-staging-4.11 bra= nch and the master HEAD of xf86-video-amdgpu using AMDGPU_GEM_DOMAIN_GTT in dm_plane_helper_prepare_fb, but I still have the weird corruption with a wh= ite background screen and a corrupted square as pointer as in the previous attachment. In the attachment the journal when attaching and detaching the = HDMI cable. The only concerning errors I can see in there are: [drm:construct [amdgpu]] *ERROR* construct: Invalid Connector ObjectID from Adapter Service for connector index:2!=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 [drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crt= c!=20=20=20 [drm:dc_create [amdgpu]] *ERROR* DC: Number of connectors is zero!
| What | Removed | Added |
|---|---|---|
| CC | harry.wentland@amd.com |
Sounds like either DC is still missing something for scanning = out from GTT, or there may indeed be additional constraints on the system memory used for it. Harry, have you guys tested GTT scanout?