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