| Bug ID | 108577 |
|---|---|
| Summary | Black X laptop screen with cursor if HDMI not plugged in, bis= ected |
| Product | DRI |
| Version | DRI git |
| Hardware | x86-64 (AMD64) |
| OS | Linux (All) |
| Status | NEW |
| Severity | blocker |
| Priority | medium |
| Component | DRM/AMDgpu |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | duncan_roe@optusnet.com.au |
Created attachment 142239 [details]
Git diff specifying 2 commits (GD is aliased to git diff)
(High severity because laptop is useless when travelling)
With HDMI unplugged, X laptop screen is black with only a cursor. Cursor
changes shape as it moves over xterm windows put there by xinitrc.
Bisecting in git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git finds
2bfb0b678e48dee76543bfa2079b7e42609332fb has the problem but adjacent commit
9c24c10a2c1e1bb478b6bb70612d9e885aee044f does not.
There is an oddity with git diff between these two: git diff <commit1>
<commit2> produces copious output and a git warning (see attachment),=
but git
checkout <commit2>; git diff <commit1> only shows one patched f=
ile (next
attachment). You might want to try this - I re-cloned the repo in case the =
old
one was corrupted but it made no difference.
| What | Removed | Added |
|---|---|---|
| Status | NEW | NEEDINFO |
Sorry guys, just noticed that after git checkout 2bfb0b678e48dee76543bfa2079b7e42609332fb I see a bunch of new commits that weren't there before - will bisect
The second bisect identifies 5099114ba3b2e5ae9fb487aeb3ae0434f= e38a7da as the oldest commit showing the problem, which does not show in adjacent commit b646c1dc835b6b73884a88643c2534f1a4a1928f. In order to see either of these commits in git list, one first needs to git checkout 2bfb0b678e48dee76543bfa2079b7e42609332fb. (In reply to Duncan Roe from commen= t #0) > Created attachment 142239 [details] > Git diff specifying 2 commits (GD is aliased to git diff) >=20 > (High severity because laptop is useless when travelling) > With HDMI unplugged, X laptop screen is black with only a cursor. Curs= or > changes shape as it moves over xterm windows put there by xinitrc. > Bisecting in git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git = finds > 2bfb0b678e48dee76543bfa2079b7e42609332fb has the problem but adjacent = commit > 9c24c10a2c1e1bb478b6bb70612d9e885aee044f does not. > There is an oddity with git diff between these two: git diff <commi= t1> > <commit2> produces copious output and a git warning (see attachm= ent), but > git checkout <commit2>; git diff <commit1> only shows one = patched file (next > attachment). You might want to try this - I re-cloned the repo in case= the > old one was corrupted but it made no difference. Please ignore the git diff stuff above. After checking out 2bfb0b678e48dee76543bfa2079b7e42609332fb, I diffed the second commit in git list not realising that this was no longer 9c24c10a2c1e1bb478b6bb70612d9e885aee044f. The new bisect is the valid one
| What | Removed | Added |
|---|---|---|
| Status | NEEDINFO | NEW |
After stripping the timestamps from good and bad copies of Xor=
g.0.log, the only
significant difference between them appears to be gart size. See attachment 2 [details] [review]
| What | Removed | Added |
|---|---|---|
| Attachment #142239 is obsolete | 1 |
Created attachment 142250 [details]
Diff of cursor-only and normal Xorg logs
(In reply to Duncan Roe from comment #4) > After stripping the timestamps from good and bad= copies of Xorg.0.log, the > only significant difference between them appears to be gart size. See > attachment 2 [d= etails] [review] [review] Sorry that is now attachment 1 [details]= [review] after obsoleting the old one
(In reply to Duncan Roe from comment #6) > (In reply to Duncan Roe from comment #4) > > After stripping the timestamps from good and bad copies of Xorg.0= .log, the > > only significant difference between them appears to be gart size.= See > > attachment 2 [details] [review] [review] [review] >=20 > Sorry that is now attachment 1 [details]<= /a> [review] [review] after obsoleting the old > one In any case, don't follow the auto-generated attachment hyperlink. Just open the attachment
(In reply to Duncan Roe from comment #7) > (In reply to Duncan Roe from comment #6) > > (In reply to Duncan Roe from comment #4) > > > After stripping the timestamps from good and bad copies of X= org.0.log, the > > > only significant difference between them appears to be gart = size. See > > > attachment 2 [details] [review] [review] [review] [review] > >=20 > > Sorry that is now attachment 1 [de= tails] [review] [review] [review] after obsoleting the old > > one >=20 > In any case, don't follow the auto-generated attachment hyperlink. Jus= t open > the attachment Ah ther you go - attachment numbers are global. See attachment 142250 [details]
| What | Removed | Added |
|---|---|---|
| CC | harry.wentland@amd.com, nicholas.kazlauskas@amd.com,= sunpeng.li@amd.com |
Commit 5099114ba3b2e5ae9fb487aeb3ae0434fe38a7da is "drm/a= mdgpu/display: drop DRM_AMD_DC_FBC kconfig option".
DRM_AMD_DC_FBC is not in my .config and never has been (from t= he RCS tree)
Created attachmen=
t 142286 [details]
Help for CONFIG_DRM_AMD_DC_FBC
Rebuilt b646c1dc835b6b73884a88643c2534f1a4a1928f (previously O= K) with CONFIG_DRM_AMD_DC_FBC turned on and got a black X display. The Help for this option says to check hardware availability before enablin= g. Looks like my hardware doesn't have it. I can see no way this option should be forced on. What I think was intended= was to remove CONFIG_DRM_AMD_DC as an option instead.
Commit 5099114ba3b2e5ae9fb487aeb3ae0434fe38a7da was authored by alexander.deucher@amd.= com but Bugzilla says "CC: alexander.deucher@amd.com did not match anything" when I try to add his email
What chip do you have? Please attach your xorg log and dmesg = output.
Created attachment 142293 [detai= ls] Xorg log See also Comment 4 This log and the dmesg o/p are form a build of commit 5099114ba3b2e5ae9fb487aeb3ae0434fe38a7da to git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Created attachment 142334 [deta= ils] [review] Patch for Linux-19.0 to revert 5099114 & reinstate DRM_AMD_DC_FBC kconf= ig option
Created attachment 142347 <= a href=3D"attachment.cgi?id=3D142347&action=3Dedit" title=3D"possible f= ix 1/2">[details] [review] possible fix 1/2 Do these patches fix the issue?