Bug 109345 - drm-next-2018-12-14 -Linux PPC
Summary: drm-next-2018-12-14 -Linux PPC
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: XOrg git
Hardware: PowerPC Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-14 07:34 UTC by Allan Cairns
Modified: 2019-08-06 02:23 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Logs.zip (330.71 KB, application/x-zip-compressed)
2019-01-15 07:55 UTC, Allan Cairns
no flags Details
Additional dmseg logs (10.40 KB, application/zip)
2019-03-30 07:21 UTC, Allan Cairns
no flags Details
DMSEG LOGS AmigaOne X5000 (46.10 KB, application/zip)
2019-04-02 07:44 UTC, Allan Cairns
no flags Details
attachment-8385-0.html (2.43 KB, text/html)
2019-04-02 08:35 UTC, Allan Cairns
no flags Details
AmigaOne DRM Issues (45.92 KB, application/zip)
2019-04-11 07:24 UTC, Allan Cairns
no flags Details
Log for bad (69.08 KB, application/zip)
2019-05-11 04:47 UTC, Allan Cairns
no flags Details
Log for Good (67.65 KB, application/zip)
2019-05-11 04:51 UTC, Allan Cairns
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Allan Cairns 2019-01-14 07:34:13 UTC
Initialization  and use of secondary graphics card (Firepro2600) does not work with new kernels using update drm-next-2018-12-14.

Situation
Amigaone x5000 with Radeon R7 250E in 16x PCIE slot, and Firepro 2260 in 1 x PCIE slot.

Previously using the following commands would allow the Firepro 2260 to be used instead of the 250E.

"sudo mv '/usr/lib/xorg/modules/libglamoregl.so' '/usr/lib/xorg/modules/libglamoregl.so.bak'
sudo mv /etc/X11/xorg.conf /etc/X11/xorg.conf.bak"

Since the incorporation of update drm-next-2018-12-14, initialization of the Firepro fails and the 250E is used.

If I remove the 250E and place the Firepro 2260 in the 16x PCIE slot it is initialized and works fine.  The issue is I need to use the 250E for Amiga 4.1 OS.

I have kept various logs but I am not sure this is actually a bug or consistent with what developers wish to happen.
Comment 1 Michel Dänzer 2019-01-14 10:49:02 UTC
Please attach the output of dmesg corresponding to the problem.

Somebody will probably need to isolate the exact commit which introduced the problem using git bisect.
Comment 2 Allan Cairns 2019-01-15 07:55:25 UTC
Created attachment 143120 [details]
Logs.zip

Micahel

Hope these help


Allan



On 14/01/19 9:19 pm, bugzilla-daemon@freedesktop.org wrote:
>
> *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=109345#c1> 
> on bug 109345 <https://bugs.freedesktop.org/show_bug.cgi?id=109345> 
> from Michel Dänzer <mailto:michel@daenzer.net> *
> Please attach the output of dmesg corresponding to the problem.
>
> Somebody will probably need to isolate the exact commit which introduced the
> problem using git bisect.
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>
Comment 3 Christian Zigotzky 2019-03-24 08:38:28 UTC
Any news? The issue still exists with the kernel 5.1-RC1. It works without the DRM updates 'drm-next-2018-12-14' [1].

Did you modify the behaviour of the initialisation of two graphics cards in the DRM updates 'drm-next-2018-12-14' [1]?

Please check the DRM updates 'drm-next-2018-12-14' [1].

@Allan
Please test the stable kernel 4.20.16 [2]. I hope the issue wasn't back ported to the stable kernel 4.20.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4971f090aa7f6ce5daa094ce4334f6618f93a7eb

[2] http://www.xenosoft.de/linux-image-4.20.16-X1000_X5000.tar.gz
Comment 4 Alex Deucher 2019-03-25 14:25:15 UTC
Hardly anything in the radeon driver has changed in the last few years.  You'd really need to bisect.  Also, can you attach a full dmesg (full logs not just filtered for radeon or drm) output from the failed and working cases?
Comment 5 Allan Cairns 2019-03-30 07:21:26 UTC
Created attachment 143815 [details]
Additional dmseg logs

dmseg output for
Xeno Kernel 5 with no DRM - Boots to second card Firepro
Xeno Kernel 5.1 RC2 - Boots to first card Southern Island
Xeno Kernel 4.20.16 - Boots to second card Firepro
Comment 6 Alex Deucher 2019-04-01 16:05:33 UTC
(In reply to Allan Cairns from comment #5)
> Created attachment 143815 [details]
> Additional dmseg logs
> 
> dmseg output for
> Xeno Kernel 5 with no DRM - Boots to second card Firepro
> Xeno Kernel 5.1 RC2 - Boots to first card Southern Island
> Xeno Kernel 4.20.16 - Boots to second card Firepro

Can you attach the full dmesg logs from boot?  These files are only partial logs and don't include any of the information from when the drivers loaded (or didn't).
Comment 7 Allan Cairns 2019-04-02 07:44:11 UTC
Created attachment 143839 [details]
DMSEG LOGS AmigaOne X5000
Comment 8 Allan Cairns 2019-04-02 08:35:41 UTC
Created attachment 143841 [details]
attachment-8385-0.html

Alex

Done, apologies I am somewhat of a novice at this.  let me know if you 
need more.


Allan

On 02/04/19 2:35 am, bugzilla-daemon@freedesktop.org wrote:
>
> *Comment # 6 <https://bugs.freedesktop.org/show_bug.cgi?id=109345#c6> 
> on bug 109345 <https://bugs.freedesktop.org/show_bug.cgi?id=109345> 
> from Alex Deucher <mailto:alexdeucher@gmail.com> *
> (In reply to Allan Cairns fromcomment #5  <show_bug.cgi?id=109345#c5>)
> > Created attachment 143815 [details] <attachment.cgi?id=143815> [details] 
> <attachment.cgi?id=143815&action=edit> > Additional dmseg logs > > 
> dmseg output for > Xeno Kernel 5 with no DRM - Boots to second card 
> Firepro > Xeno Kernel 5.1 RC2 - Boots to first card Southern Island > 
> Xeno Kernel 4.20.16 - Boots to second card Firepro
>
> Can you attach the full dmesg logs from boot?  These files are only partial
> logs and don't include any of the information from when the drivers loaded (or
> didn't).
> ------------------------------------------------------------------------
> You are receiving this mail because:
>
>   * You reported the bug.
>
Comment 9 Alex Deucher 2019-04-02 14:03:18 UTC
They are still only partial logs.  you should just be able to redirect the output to a file right after you log in.  E.g., `dmesg > dmesg.txt`
Comment 10 Allan Cairns 2019-04-11 07:24:58 UTC
Created attachment 143935 [details]
AmigaOne DRM Issues

Third time lucky?
Comment 11 Allan Cairns 2019-04-11 07:27:33 UTC
Alex
Hopefully these are what you are after.  I was told to use less with
dmseg so not sure if that caused the problem.

Allan
Comment 12 Christian Zigotzky 2019-04-29 14:04:40 UTC
Any news? The issue still exists with the kernel 5.1-RC7.
Comment 13 Michel Dänzer 2019-04-29 14:19:04 UTC
(In reply to Christian Zigotzky from comment #12)
> Any news? The issue still exists with the kernel 5.1-RC7.

I wouldn't expect anything to happen without the result of git bisect.
Comment 14 Christian Zigotzky 2019-04-30 07:19:09 UTC
(In reply to Michel Dänzer from comment #13)
> (In reply to Christian Zigotzky from comment #12)
> > Any news? The issue still exists with the kernel 5.1-RC7.
> 
> I wouldn't expect anything to happen without the result of git bisect.

Hi Michel,

This is a bug report from an enduser. Endusers aren't able to git bisect. They use the distributions for their daily work. I don't have these graphics cards so I can't bisect it ether. The user told you what the problem is and we figured out that the DRM updates 'drm-next-2018-12-14' [1] are the problem.

If you don't try to solve it then we will lost this support. PLEASE check your code more carefully before you release it. There are a lot of endusers who uses this code in they daily work later.

I will also look in the DRM updates deeper but I work for an enduser first level support so I need a lot of time to understand the code. It's really better you look in the DRM changes because you understand this code better than me. 

Thanks,
Christian

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4971f090aa7f6ce5daa094ce4334f6618f93a7eb
Comment 15 Michel Dänzer 2019-04-30 07:29:47 UTC
This is a platform specific issue. We cannot test on this platform, so someone who can has to isolate the change causing the problem. I realize this may suck, but it's reality.
Comment 16 Christian Zigotzky 2019-04-30 16:00:44 UTC
(In reply to Michel Dänzer from comment #15)
> This is a platform specific issue. We cannot test on this platform, so
> someone who can has to isolate the change causing the problem. I realize
> this may suck, but it's reality.

OK. Where could be the issue in these DRM updates? I think the issue is somewhere in the updated Core source files. I don’t think the issue is in the driver updates. What do you think?
Comment 17 Christian Zigotzky 2019-05-01 14:44:19 UTC
(In reply to Alex Deucher from comment #4)
> Hardly anything in the radeon driver has changed in the last few years. 
> You'd really need to bisect.  Also, can you attach a full dmesg (full logs
> not just filtered for radeon or drm) output from the failed and working
> cases?

I have found some Radeon changes in these DRM updates:

-rw-r--r--	drivers/gpu/drm/radeon/r300.c	4			
-rw-r--r--	drivers/gpu/drm/radeon/r420.c	1			
-rw-r--r--	drivers/gpu/drm/radeon/radeon.h	3			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_cs.c	4			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_gem.c	2			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_legacy_tv.c 10			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_object.c	2			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_ttm.c	65			
-rw-r--r--	drivers/gpu/drm/radeon/radeon_vm.c

I see some changes in the GPU memory management subsystem (TTM).

Please note: This is a bug report from an enduser. Endusers aren't able to git bisect. They use the distributions for their daily work. I don't have these graphics cards so I can't bisect it ether.
Comment 18 Christian Zigotzky 2019-05-01 14:54:06 UTC
Did you modify the behaviour of the initialisation of two graphics cards in
the DRM updates 'drm-next-2018-12-14' [1]?

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4971f090aa7f6ce5daa094ce4334f6618f93a7eb
Comment 19 Ilia Mirkin 2019-05-01 15:00:59 UTC
(In reply to Christian Zigotzky from comment #17)
> Please note: This is a bug report from an enduser. Endusers aren't able to
> git bisect. They use the distributions for their daily work. I don't have
> these graphics cards so I can't bisect it ether.

If the end user can't build kernels, then the distribution should coordinate with the end user to provide pre-built kernels at appropriate revisions and do the (effective) bisect that way.

(And if the end user can build kernels, then they can certainly bisect.)
Comment 20 Alex Deucher 2019-05-01 16:06:47 UTC
(In reply to Christian Zigotzky from comment #17)
> (In reply to Alex Deucher from comment #4)
> > Hardly anything in the radeon driver has changed in the last few years. 
> > You'd really need to bisect.  Also, can you attach a full dmesg (full logs
> > not just filtered for radeon or drm) output from the failed and working
> > cases?
> 
> I have found some Radeon changes in these DRM updates:
> 
> -rw-r--r--	drivers/gpu/drm/radeon/r300.c	4			
> -rw-r--r--	drivers/gpu/drm/radeon/r420.c	1			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon.h	3			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_cs.c	4			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_gem.c	2			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_legacy_tv.c 10			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_object.c	2			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_ttm.c	65			
> -rw-r--r--	drivers/gpu/drm/radeon/radeon_vm.c

Someone with access to the hw and the platform would have to go through the changes and see what broke it.  A bisect would be an easy way to do it.  Also, it's not necessarily a drm change.  It could have been a bad interaction with some other change elsewhere in the kernel.
Comment 21 Christian Zigotzky 2019-05-01 17:00:35 UTC
Again. Did you modify the behaviour of the initialisation of two graphics cards in the DRM updates 'drm-next-2018-12-14'? If you say no, than I can look in the PowerPC updates. You need to know if there was a change or you don't know what you published. It's not the task for the enduser to look in your code or bisect the code because you don't know the changes. It is always the same. You changed the code and after that we have issues and we endusers and first level support have to figure out where the problem is. And if we don't figure out the issue then the issue remain. It's easy to write that you don't have this platform.

Thanks
Comment 22 Christian Zigotzky 2019-05-01 17:04:29 UTC
Edit: typo

Again. Did you modify the behaviour of the initialisation of two graphics cards in the DRM updates 'drm-next-2018-12-14'? If you say no, then I can look in the PowerPC updates. You need to know if there was a change or you don't know what you published. It's not the task for the enduser to look in your code or bisect the code because you don't know the changes. It is always the same. You changed the code and after that we have issues and we endusers and first level support have to figure out where the problem is. And if we don't figure out the issue then the issue remains. It's easy to write that you don't have this platform.
Comment 23 Alex Deucher 2019-05-01 18:47:21 UTC
(In reply to Christian Zigotzky from comment #22)
> Again. Did you modify the behaviour of the initialisation of two graphics
> cards in the DRM updates 'drm-next-2018-12-14'? If you say no, then I can
> look in the PowerPC updates. You need to know if there was a change or you
> don't know what you published. It's not the task for the enduser to look in
> your code or bisect the code because you don't know the changes. It is
> always the same. You changed the code and after that we have issues and we
> endusers and first level support have to figure out where the problem is.
> And if we don't figure out the issue then the issue remains. It's easy to
> write that you don't have this platform.

No, the only changes were changes in comments, removing some unused code and changes in the shared ttm module that touched all drivers that use ttm.
Comment 24 Christian Zigotzky 2019-05-02 03:44:44 UTC
(In reply to Alex Deucher from comment #23)
> (In reply to Christian Zigotzky from comment #22)
> > Again. Did you modify the behaviour of the initialisation of two graphics
> > cards in the DRM updates 'drm-next-2018-12-14'? If you say no, then I can
> > look in the PowerPC updates. You need to know if there was a change or you
> > don't know what you published. It's not the task for the enduser to look in
> > your code or bisect the code because you don't know the changes. It is
> > always the same. You changed the code and after that we have issues and we
> > endusers and first level support have to figure out where the problem is.
> > And if we don't figure out the issue then the issue remains. It's easy to
> > write that you don't have this platform.
> 
> No, the only changes were changes in comments, removing some unused code and
> changes in the shared ttm module that touched all drivers that use ttm.

Thank you for your reply! OK, we know that without the DRM updates 2018-12-14 the 2 graphics cards work together without any problems. With which good and bad commit should I start bisecting?

@Allan
I have to compile a lot of test kernels but I can’t test them because I don’t have these two graphics cards. Please test all test kernels.
Comment 25 Michel Dänzer 2019-05-02 07:56:56 UTC
(In reply to Christian Zigotzky from comment #24)
> With which good and bad commit should I start bisecting?

Good: c76cd634eb5bfd497617ea224a54a03b545c8c4d
Bad: 4971f090aa7f6ce5daa094ce4334f6618f93a7eb
Comment 26 Christian Zigotzky 2019-05-02 21:47:47 UTC
(In reply to Michel Dänzer from comment #25)
> (In reply to Christian Zigotzky from comment #24)
> > With which good and bad commit should I start bisecting?
> 
> Good: c76cd634eb5bfd497617ea224a54a03b545c8c4d
> Bad: 4971f090aa7f6ce5daa094ce4334f6618f93a7eb

Hi Michel,

Thanks a lot for your help! :-)

I started bisecting today.

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git drm_test

cd drm_test

git bisect start

git bisect good c76cd634eb5bfd497617ea224a54a03b545c8c4d

git bisect bad 4971f090aa7f6ce5daa094ce4334f6618f93a7eb

Output:

Bisecting: 653 revisions left to test after this (roughly 10 steps)
[2ac5e38ea4203852d6e99edd3cf11f044b0a409f] Merge drm/drm-next into drm-intel-next-queued

---

cp ../linux-image-5.1-rc7-X1000_X5000/X5000_and_QEMU_e5500/src/cyrus-5.1-rc7.config .config

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm1

@Allan (acefnq/ace)
Please test this kernel with the two installed graphics cards.

Thanks,
Christian
Comment 27 Christian Zigotzky 2019-05-03 11:00:25 UTC
Hi All,

Allan tested the first test kernel today. He wrote:

Hi Christian
The kernel boots but to SI card.

Cheers

ace

------

That means, this step has been marked as bad.

git bisect bad

Output:

Bisecting: 387 revisions left to test after this (roughly 9 steps)
[63ac3328f0d1d37f286e397b14d9596ed09d7ca5] drm/i915: fix broadwell EU computation

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm2

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 28 Christian Zigotzky 2019-05-03 16:37:52 UTC
Hi All,

Allan successfully tested the second test kernel today. He wrote:

Christian
DRM2 BINGO, boots to Firepro!

ace

------

This step has been marked as good.

git bisect good

Output:

Bisecting: 202 revisions left to test after this (roughly 8 steps)
[d7563c55ef9fc1fd2301b8708b3c1f53509d6745] Merge tag 'drm-misc-next-2018-11-07' of git://anongit.freedesktop.org/drm/drm-misc into drm-next

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm3

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 29 Christian Zigotzky 2019-05-04 21:23:36 UTC
Hi All,

Allan tested the third test kernel today. He wrote:

Christian

DRM3 boots to SI card.

ace

PS Thanks for doing this , much appreciated.

------

This step has been marked as bad because the third test kernel doesn't boot to the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 92 revisions left to test after this (roughly 7 steps)
[2b02a05bdc3a62d36e0d0b015351897109e25991] drm/vc4: Set ->is_yuv to false when num_planes == 1

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm4

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 30 Christian Zigotzky 2019-05-05 10:14:32 UTC
Hi All,

Allan has tested the fourth test kernel. He wrote:

Christian
DRM4 boots to SI card.

Cheers

ace

------

This step has been marked as bad because the fourth test kernel doesn't boot to the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 45 revisions left to test after this (roughly 6 steps)
[a2b50babc74394c99638a37a3d48adeb03ddc248] drm/sti: Use drm_atomic_helper_shutdown

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm5

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 31 Christian Zigotzky 2019-05-05 14:17:03 UTC
Hi All,

Allan has tested the fifth test kernel. He wrote:

Christian
DRM5 boots to Firepro!

ace

------

This step has been marked as good.

Next step:

git bisect good

Output:

Bisecting: 22 revisions left to test after this (roughly 5 steps)
[48197bc564c7a1888c86024a1ba4f956e0ec2300] drm: add syncobj timeline support v9

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm6

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 32 Christian Zigotzky 2019-05-06 08:09:56 UTC
Hi All,

Allan successfully tested the sixth test kernel today. He wrote:

Christian
DRM6 boots to Firepro.

cheers

ace

------

This step has been marked as good because the sixth test kernel boots to FirePro.

Next step:

git bisect good

Output:

Bisecting: 11 revisions left to test after this (roughly 4 steps)
[068f304781804e208f901d8f6083189e0e28c420] drm/drm_pci.c: Use dma_zalloc_coherent

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm7

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 33 Christian Zigotzky 2019-05-06 10:52:48 UTC
Hi All,

Allan successfully tested the seventh test kernel today. He wrote:

Christian
DRM7 boots to SI card.

ace

------

This step has been marked as bad because the seventh test kernel doesn't boot to the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 5 revisions left to test after this (roughly 3 steps)
[e51767279f11571b112dbeaef2628968c62f90a6] drm/selftest: Refactor test-drm_plane_helper

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm8

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 34 Christian Zigotzky 2019-05-07 21:08:24 UTC
Hi All,

Allan successfully tested the eighth test kernel on his X5000 today.

He wrote:

Christian
DRM8 boots to Firepro. Can you ascertain anything as yet as to where the issue lies?

Cheers

ace

------

This step has been marked as good because the eighth test kernel boots to FirePro.

Next step:

git bisect good

Output:

Bisecting: 2 revisions left to test after this (roughly 2 steps)
[43cf1fc0e27e2f7eeb5d6c15fd023813a5b49987] drm: fix deadlock of syncobj v6

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm9

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 35 Ilia Mirkin 2019-05-07 21:18:03 UTC
If I had to put money on one of the left-over commits, I'd go with

commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
Author: Aaron Ma <aaron.ma@canonical.com>
Date:   Sat Sep 1 02:20:00 2018 +0800

    vgaarb: Keep adding VGA device in queue
    
    If failed to find the deivice owning the boot framebuffer,
    try to use the first VGA device instead of the last one.
    
    Usually the 1st device is integrated GPU who owns the boot framebuffer.
    
    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-email-aaron.ma@canonical.com

Which seems to change the vgaarb logic wrt which device is the primary.
Comment 36 Christian Zigotzky 2019-05-08 07:08:55 UTC
(In reply to Ilia Mirkin from comment #35)
> If I had to put money on one of the left-over commits, I'd go with
> 
> commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
> Author: Aaron Ma <aaron.ma@canonical.com>
> Date:   Sat Sep 1 02:20:00 2018 +0800
> 
>     vgaarb: Keep adding VGA device in queue
>     
>     If failed to find the deivice owning the boot framebuffer,
>     try to use the first VGA device instead of the last one.
>     
>     Usually the 1st device is integrated GPU who owns the boot framebuffer.
>     
>     Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
>     Acked-by: Alex Deucher <alexander.deucher@amd.com>
>     Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>     Link:
> https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-
> email-aaron.ma@canonical.com
> 
> Which seems to change the vgaarb logic wrt which device is the primary.

Thanks a lot for the hint. I am looking forward to the git bisect result.
Comment 37 Christian Zigotzky 2019-05-08 11:13:34 UTC
Hi All,

Allan has tested the ninth test kernel.

He wrote:

Christian
DRM9 boots to SI card.

ace

------

This step has been marked as bad because the ninth test kernel doesn't boot to the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 0 revisions left to test after this (roughly 1 step)
[3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa] vgaarb: Keep adding VGA device in queue

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm10

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 38 Christian Zigotzky 2019-05-09 10:04:24 UTC
Hi All,

Allan tested the tenth test kernel today.

He wrote:

Christian
DRM10 also boots to SI card.

ace

------

Link to the test thread: http://forum.hyperion-entertainment.com/viewtopic.php?f=58&t=4256&start=50#p47877

This step has been marked as bad because the tenth test kernel doesn't boot to the FirePro.

Next step:

git bisect bad

Output:

Bisecting: 0 revisions left to test after this (roughly 0 steps)
[a81c9ab678802075b7942c41cf640d9d9866d2db] vgaarb: Add support for 64-bit frame buffer address

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc oldconfig

make CROSS_COMPILE=powerpc-linux-gnu- ARCH=powerpc uImage

Download: http://www.xenosoft.de/uImage-drm11

Additionally I undid the changes in the file 'drivers/gpu/vga/vgaarb.c' [1] and created a test kernel today.

Download: http://www.xenosoft.de/linux-image-5.2-alpha2-X1000_X5000.tar.gz

@Allan (acefnq/ace)
Please test both kernels.

Thanks,
Christian

[1] https://patchwork.freedesktop.org/patch/246810/
Comment 39 Christian Zigotzky 2019-05-09 11:52:24 UTC
Hi All,

Allan has successfully tested the eleventh test kernel.

He wrote:

Christian
DRM11 boots to Firepro.

ace

------

We have a result!

git bisect good

The following commit is responsible for the issue:

3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa is the first bad commit
commit 3d42f1ddc47a69c0ce155f9f30d764c4d689a5fa
Author: Aaron Ma <aaron.ma@canonical.com>
Date:   Sat Sep 1 02:20:00 2018 +0800

    vgaarb: Keep adding VGA device in queue

    If failed to find the deivice owning the boot framebuffer,
    try to use the first VGA device instead of the last one.

    Usually the 1st device is integrated GPU who owns the boot framebuffer.

    Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
    Acked-by: Alex Deucher <alexander.deucher@amd.com>
    Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
    Link: https://patchwork.freedesktop.org/patch/msgid/1535739600-8842-2-git-send-email-aaron.ma@canonical.com

:040000 040000 2d69570b87946ba42095609c945f04de9ad24ef7 3d86752f71500726f20d7d503128119f9b249175 M   drivers

------

I undid these changes in the file 'drivers/gpu/vga/vgaarb.c' and created another test kernel today.

Download: http://www.xenosoft.de/linux-image-5.2-alpha2-X1000_X5000.tar.gz

You can undo the commit with the following patch:

diff -rupN a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
--- a/drivers/gpu/vga/vgaarb.c    2019-05-09 07:56:27.595746473 +0200
+++ b/drivers/gpu/vga/vgaarb.c    2019-05-09 08:00:06.352660688 +0200
@@ -725,7 +725,7 @@ static bool vga_arbiter_add_pci_device(s
     vga_arbiter_check_bridge_sharing(vgadev);

     /* Add to the list */
-    list_add_tail(&vgadev->list, &vga_list);
+    list_add(&vgadev->list, &vga_list);
     vga_count++;
     vgaarb_info(&pdev->dev, "VGA device added: decodes=%s,owns=%s,locks=%s\n",
         vga_iostate_to_str(vgadev->decodes),

------

@Allan (acefnq/ace)
Please test it.

Thanks,
Christian
Comment 40 Christian Zigotzky 2019-05-10 03:45:48 UTC
Hi All,

Great news! :-) Allan successfully tested the latest patched Git kernel with his two graphics cards today. 

OK, we know the bad commit and we have a patch. What’s next?

Cheers,
Christian
Comment 41 Alex Deucher 2019-05-10 14:15:51 UTC
I'll send out a patch to revert the change.
Comment 42 Michel Dänzer 2019-05-10 15:39:52 UTC
Allan, please attach the /etc/X11/xorg.conf(.bak) file and the Xorg log files from the good and bad cases.
Comment 43 Allan Cairns 2019-05-11 04:47:33 UTC
Created attachment 144230 [details]
Log for bad

Christian provided bisect kernels (DRM1 to 11).  These examples booted to Southern Island card (1st card) and are therefore marked as bad.
Comment 44 Allan Cairns 2019-05-11 04:51:16 UTC
Created attachment 144231 [details]
Log for Good

These are the logs for the bisects that booted to Firepro (2nd Card)
Comment 45 Michel Dänzer 2019-05-13 09:37:48 UTC
Reviewing the information, I'm afraid it's not clear that there's a bug here.

The description says the FirePro is the secondary card in a PCIe 1x slot, whereas the R7 is in the PCIe 16x slot. Thus it seems pretty clear that without explicit configuration, Xorg should be expected to come up on the R7. Arguably it was actually the previous behaviour that was buggy.

Something like this in /etc/X11/xorg.conf should be enough to make Xorg use the FirePro card:

Section "Device"
        Identifier "whatever"
        BusID   "PCI:5@4096:0:0"
EndSection
Comment 46 Christian Zigotzky 2019-05-13 14:20:00 UTC
(In reply to Michel Dänzer from comment #45)
> Reviewing the information, I'm afraid it's not clear that there's a bug here.
> 
> The description says the FirePro is the secondary card in a PCIe 1x slot,
> whereas the R7 is in the PCIe 16x slot. Thus it seems pretty clear that
> without explicit configuration, Xorg should be expected to come up on the
> R7. Arguably it was actually the previous behaviour that was buggy.
> 
> Something like this in /etc/X11/xorg.conf should be enough to make Xorg use
> the FirePro card:
> 
> Section "Device"
>         Identifier "whatever"
>         BusID   "PCI:5@4096:0:0"
> EndSection

Hi Michel,

Why did you close this bug report? Allan hasn't tested your solution yet.

My first question in this thread was, if you modified the behaviour of the initialisation of two graphics cards in the DRM updates 'drm-next-2018-12-14'. The answer was: "No, the only changes were changes in comments, removing some unused code and changes in the shared ttm module that touched all drivers that use ttm."

This wasn't correct. I had to compile a lot of kernels and after that we knowed that you modified the behaviour of the initialisation of two graphics cards in the DRM updates 'drm-next-2018-12-14'. And now you just closed this bug report.

Please give Allan the chance to test your solution.

PLEASE check your code more carefully before you release it. There are a lot of endusers who uses this code in they daily work later.

Cheers,
Christian
Comment 47 Allan Cairns 2019-05-27 01:54:48 UTC
I tried using an xorg.conf with the following:
    Section "Device"
            Identifier "ATI RV620 [FirePro 2260]"
            BusID   "PCI:5@4096:0:0"
    EndSection


My Amigone x5000 would only boot to a black screen.  No ability to input.

Allan
Comment 48 Michel Dänzer 2019-06-03 08:42:04 UTC
(In reply to Allan Cairns from comment #47)
> My Amigone x5000 would only boot to a black screen.  No ability to input.

Please attach the corresponding Xorg log file. If you can't log into the system remotely, it should be available as Xorg.0.log.old after rebooting.
Comment 49 Allan Cairns 2019-08-06 02:23:31 UTC
All
Thanks for your hard work in investigating this bug it is very much appreciated.  I can confirm the issues on the Amigaone X5000 are resolved.


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.