Bug 109345

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.

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.
>

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

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?

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

(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).

Created attachment 143839 [details]
DMSEG LOGS AmigaOne X5000

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.
>

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`

Created attachment 143935 [details]
AmigaOne DRM Issues

Third time lucky?

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

Any news? The issue still exists with the kernel 5.1-RC7.

(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.

(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

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.

(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?

(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.

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

(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.)

(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.

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

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.

(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.

(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.

(In reply to Christian Zigotzky from comment #24)
> With which good and bad commit should I start bisecting?

Good: c76cd634eb5bfd497617ea224a54a03b545c8c4d
Bad: 4971f090aa7f6ce5daa094ce4334f6618f93a7eb

(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

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

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

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

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

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

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

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

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

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.

(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.

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

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/

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

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

I'll send out a patch to revert the change.

Allan, please attach the /etc/X11/xorg.conf(.bak) file and the Xorg log files from the good and bad cases.

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.

Created attachment 144231 [details]
Log for Good

These are the logs for the bisects that booted to Firepro (2nd Card)

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

(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

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

(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.

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.