Re: [PATCH 00/17] drm/mgag200: Convert to atomic modesetting
> On May 4, 2020, at 8:39 AM, Thomas Zimmermann wrote: > > Hi John > > Am 30.04.20 um 02:11 schrieb John Donnelly: >> On 4/29/20 9:32 AM, Thomas Zimmermann wrote: >>> This patchset converts mgag200 to atomic modesetting. It uses simple >>> KMS helpers and SHMEM. >>> >>> Patches 1 to 4 simplifies the driver before the conversion. For example, >>> the HW cursor is not usable with the way universal planes work. A few >>> data structures can be cleaned up. >>> >>> Patches 5 to 15 untangle the existing modesetting code into smaller >>> functions. Specifically, mode setting and plane updates are being >>> separated from each other. >>> >>> Patch 16 converts mgag200 to simple KMS helpers and enables atomic >>> mode setting. >>> >>> As some HW seems to require a framebuffer offset of 0 within the video >>> memory, it does not work with atomic modesetting. Atomically switching >>> plane framebuffers, requires either source or target buffer to be located >>> at a non-0 offet. To resolve this problem, patch 17 converts mgag200 from >>> VRAM helpers to SHMEM helpers. During plane updates, the content of the >>> SHMEM BO is memcpy'd to VRAM. From my subjective obersation, performance >>> is not nuch different from the original code. >>> >>> The patchset has been tested on MGA G200EH hardware. >>> >>> Thomas Zimmermann (17): >>>drm/mgag200: Remove HW cursor >>>drm/mgag200: Remove unused fields from struct mga_device >>>drm/mgag200: Embed connector instance in struct mga_device >>>drm/mgag200: Use managed mode-config initialization >>>drm/mgag200: Clean up mga_set_start_address() >>>drm/mgag200: Clean up mga_crtc_do_set_base() >>>drm/mgag200: Move mode-setting code into separate helper function >>>drm/mgag200: Split MISC register update into PLL selection, SYNC and >>> I/O >>>drm/mgag200: Update mode registers after plane registers >>>drm/mgag200: Set pitch in a separate helper function >>>drm/mgag200: Set primary plane's format in separate helper function >>>drm/mgag200: Move TAGFIFO reset into separate function >>>drm/mgag200: Move hiprilvl setting into separate functions >>>drm/mgag200: Move register initialization into separate function >>>drm/mgag200: Remove waiting from DPMS code >>>drm/mgag200: Convert to simple KMS helper >>>drm/mgag200: Replace VRAM helpers with SHMEM helpers >>> >>> drivers/gpu/drm/mgag200/Kconfig | 4 +- >>> drivers/gpu/drm/mgag200/Makefile | 2 +- >>> drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 >>> drivers/gpu/drm/mgag200/mgag200_drv.c| 51 +- >>> drivers/gpu/drm/mgag200/mgag200_drv.h| 43 +- >>> drivers/gpu/drm/mgag200/mgag200_main.c | 28 - >>> drivers/gpu/drm/mgag200/mgag200_mode.c | 948 --- >>> drivers/gpu/drm/mgag200/mgag200_reg.h| 5 +- >>> drivers/gpu/drm/mgag200/mgag200_ttm.c| 35 +- >>> 9 files changed, 563 insertions(+), 872 deletions(-) >>> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c >>> >>> -- >>> 2.26.0 >>> >> >> >> Hi Thomas , >> >> I would like to test this on hardware that uses this device integrated >> into as BMC ( iLo ) that I have ran into problems before. Can you post >> your staging URL so I can clone it ? > > I uploaded the patches at > > > https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/mgag200-simplekms-20200504 > > You can clone them with > > git clone g...@gitlab.freedesktop.org:tzimmermann/linux.git > > and checkout the mgag200-simplekms-20200405 branch afterwards. > > Best regards > Thomas > >> >> >> ( Thank you for CC'ing me. I removed my email from on dlist recently) . >> >> >> I had no issues running these changes with gnome on a server with a mgag200 integrated into a BMC . Tested-by: John Donnelly ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/17] drm/mgag200: Convert to atomic modesetting
> On May 4, 2020, at 8:39 AM, Thomas Zimmermann wrote: > > Hi John > > Am 30.04.20 um 02:11 schrieb John Donnelly: >> On 4/29/20 9:32 AM, Thomas Zimmermann wrote: >>> This patchset converts mgag200 to atomic modesetting. It uses simple >>> KMS helpers and SHMEM. >>> >>> Patches 1 to 4 simplifies the driver before the conversion. For example, >>> the HW cursor is not usable with the way universal planes work. A few >>> data structures can be cleaned up. >>> >>> Patches 5 to 15 untangle the existing modesetting code into smaller >>> functions. Specifically, mode setting and plane updates are being >>> separated from each other. >>> >>> Patch 16 converts mgag200 to simple KMS helpers and enables atomic >>> mode setting. >>> >>> As some HW seems to require a framebuffer offset of 0 within the video >>> memory, it does not work with atomic modesetting. Atomically switching >>> plane framebuffers, requires either source or target buffer to be located >>> at a non-0 offet. To resolve this problem, patch 17 converts mgag200 from >>> VRAM helpers to SHMEM helpers. During plane updates, the content of the >>> SHMEM BO is memcpy'd to VRAM. From my subjective obersation, performance >>> is not nuch different from the original code. >>> >>> The patchset has been tested on MGA G200EH hardware. >>> >>> Thomas Zimmermann (17): >>>drm/mgag200: Remove HW cursor >>>drm/mgag200: Remove unused fields from struct mga_device >>>drm/mgag200: Embed connector instance in struct mga_device >>>drm/mgag200: Use managed mode-config initialization >>>drm/mgag200: Clean up mga_set_start_address() >>>drm/mgag200: Clean up mga_crtc_do_set_base() >>>drm/mgag200: Move mode-setting code into separate helper function >>>drm/mgag200: Split MISC register update into PLL selection, SYNC and >>> I/O >>>drm/mgag200: Update mode registers after plane registers >>>drm/mgag200: Set pitch in a separate helper function >>>drm/mgag200: Set primary plane's format in separate helper function >>>drm/mgag200: Move TAGFIFO reset into separate function >>>drm/mgag200: Move hiprilvl setting into separate functions >>>drm/mgag200: Move register initialization into separate function >>>drm/mgag200: Remove waiting from DPMS code >>>drm/mgag200: Convert to simple KMS helper >>>drm/mgag200: Replace VRAM helpers with SHMEM helpers >>> >>> drivers/gpu/drm/mgag200/Kconfig | 4 +- >>> drivers/gpu/drm/mgag200/Makefile | 2 +- >>> drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 >>> drivers/gpu/drm/mgag200/mgag200_drv.c| 51 +- >>> drivers/gpu/drm/mgag200/mgag200_drv.h| 43 +- >>> drivers/gpu/drm/mgag200/mgag200_main.c | 28 - >>> drivers/gpu/drm/mgag200/mgag200_mode.c | 948 --- >>> drivers/gpu/drm/mgag200/mgag200_reg.h| 5 +- >>> drivers/gpu/drm/mgag200/mgag200_ttm.c| 35 +- >>> 9 files changed, 563 insertions(+), 872 deletions(-) >>> delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c >>> >>> -- >>> 2.26.0 >>> >> >> >> Hi Thomas , >> >> I would like to test this on hardware that uses this device integrated >> into as BMC ( iLo ) that I have ran into problems before. Can you post >> your staging URL so I can clone it ? > > I uploaded the patches at > > > https://gitlab.freedesktop.org/tzimmermann/linux/-/tree/mgag200-simplekms-20200504 > > You can clone them with > > git clone g...@gitlab.freedesktop.org:tzimmermann/linux.git > > and checkout the mgag200-simplekms-20200405 branch afterwards. > > Best regards > Thomas Got it . Thank you . ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/17] drm/mgag200: Convert to atomic modesetting
On 4/30/20 3:29 AM, Thomas Zimmermann wrote: Hi John Am 30.04.20 um 02:11 schrieb John Donnelly: On 4/29/20 9:32 AM, Thomas Zimmermann wrote: This patchset converts mgag200 to atomic modesetting. It uses simple KMS helpers and SHMEM. Patches 1 to 4 simplifies the driver before the conversion. For example, the HW cursor is not usable with the way universal planes work. A few data structures can be cleaned up. Patches 5 to 15 untangle the existing modesetting code into smaller functions. Specifically, mode setting and plane updates are being separated from each other. Patch 16 converts mgag200 to simple KMS helpers and enables atomic mode setting. As some HW seems to require a framebuffer offset of 0 within the video memory, it does not work with atomic modesetting. Atomically switching plane framebuffers, requires either source or target buffer to be located at a non-0 offet. To resolve this problem, patch 17 converts mgag200 from VRAM helpers to SHMEM helpers. During plane updates, the content of the SHMEM BO is memcpy'd to VRAM. From my subjective obersation, performance is not nuch different from the original code. The patchset has been tested on MGA G200EH hardware. Thomas Zimmermann (17): drm/mgag200: Remove HW cursor drm/mgag200: Remove unused fields from struct mga_device drm/mgag200: Embed connector instance in struct mga_device drm/mgag200: Use managed mode-config initialization drm/mgag200: Clean up mga_set_start_address() drm/mgag200: Clean up mga_crtc_do_set_base() drm/mgag200: Move mode-setting code into separate helper function drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O drm/mgag200: Update mode registers after plane registers drm/mgag200: Set pitch in a separate helper function drm/mgag200: Set primary plane's format in separate helper function drm/mgag200: Move TAGFIFO reset into separate function drm/mgag200: Move hiprilvl setting into separate functions drm/mgag200: Move register initialization into separate function drm/mgag200: Remove waiting from DPMS code drm/mgag200: Convert to simple KMS helper drm/mgag200: Replace VRAM helpers with SHMEM helpers drivers/gpu/drm/mgag200/Kconfig | 4 +- drivers/gpu/drm/mgag200/Makefile | 2 +- drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 drivers/gpu/drm/mgag200/mgag200_drv.c | 51 +- drivers/gpu/drm/mgag200/mgag200_drv.h | 43 +- drivers/gpu/drm/mgag200/mgag200_main.c | 28 - drivers/gpu/drm/mgag200/mgag200_mode.c | 948 --- drivers/gpu/drm/mgag200/mgag200_reg.h | 5 +- drivers/gpu/drm/mgag200/mgag200_ttm.c | 35 +- 9 files changed, 563 insertions(+), 872 deletions(-) delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c -- 2.26.0 Hi Thomas , I would like to test this on hardware that uses this device integrated into as BMC ( iLo ) that I have ran into problems before. Can you post your staging URL so I can clone it ? Sure, I'll set something up for you. But it could take until next week. I promise not to merge the patches before you had a chance to test them. Best regards Thomas Hi I may try to apply these patches locally .. It won't be until next week though . ( Thank you for CC'ing me. I removed my email from on dlist recently) . -- Thank You, John ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
re: [PATCH 00/17] drm/mgag200: Convert to atomic modesetting
On 4/29/20 9:32 AM, Thomas Zimmermann wrote: This patchset converts mgag200 to atomic modesetting. It uses simple KMS helpers and SHMEM. Patches 1 to 4 simplifies the driver before the conversion. For example, the HW cursor is not usable with the way universal planes work. A few data structures can be cleaned up. Patches 5 to 15 untangle the existing modesetting code into smaller functions. Specifically, mode setting and plane updates are being separated from each other. Patch 16 converts mgag200 to simple KMS helpers and enables atomic mode setting. As some HW seems to require a framebuffer offset of 0 within the video memory, it does not work with atomic modesetting. Atomically switching plane framebuffers, requires either source or target buffer to be located at a non-0 offet. To resolve this problem, patch 17 converts mgag200 from VRAM helpers to SHMEM helpers. During plane updates, the content of the SHMEM BO is memcpy'd to VRAM. From my subjective obersation, performance is not nuch different from the original code. The patchset has been tested on MGA G200EH hardware. Thomas Zimmermann (17): drm/mgag200: Remove HW cursor drm/mgag200: Remove unused fields from struct mga_device drm/mgag200: Embed connector instance in struct mga_device drm/mgag200: Use managed mode-config initialization drm/mgag200: Clean up mga_set_start_address() drm/mgag200: Clean up mga_crtc_do_set_base() drm/mgag200: Move mode-setting code into separate helper function drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O drm/mgag200: Update mode registers after plane registers drm/mgag200: Set pitch in a separate helper function drm/mgag200: Set primary plane's format in separate helper function drm/mgag200: Move TAGFIFO reset into separate function drm/mgag200: Move hiprilvl setting into separate functions drm/mgag200: Move register initialization into separate function drm/mgag200: Remove waiting from DPMS code drm/mgag200: Convert to simple KMS helper drm/mgag200: Replace VRAM helpers with SHMEM helpers drivers/gpu/drm/mgag200/Kconfig | 4 +- drivers/gpu/drm/mgag200/Makefile | 2 +- drivers/gpu/drm/mgag200/mgag200_cursor.c | 319 drivers/gpu/drm/mgag200/mgag200_drv.c| 51 +- drivers/gpu/drm/mgag200/mgag200_drv.h| 43 +- drivers/gpu/drm/mgag200/mgag200_main.c | 28 - drivers/gpu/drm/mgag200/mgag200_mode.c | 948 --- drivers/gpu/drm/mgag200/mgag200_reg.h| 5 +- drivers/gpu/drm/mgag200/mgag200_ttm.c| 35 +- 9 files changed, 563 insertions(+), 872 deletions(-) delete mode 100644 drivers/gpu/drm/mgag200/mgag200_cursor.c -- 2.26.0 Hi Thomas , I would like to test this on hardware that uses this device integrated into as BMC ( iLo ) that I have ran into problems before. Can you post your staging URL so I can clone it ? ( Thank you for CC'ing me. I removed my email from on dlist recently) . -- Thank You, John ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: BAD -- Patch "drm/mgag200: Flag all G200 SE A machines as broken wrt " has been added to the 5.4-stable tree
Hi
I am having difficulties with this patch on : 5.4.2 variant ; The system is
not booting with these patches applied.
I had verified a prototype of the patch on 5.4.0-rc8 ;
I am currently debugging it , but I will be OoO until 1/6/2020 after today .
> On Dec 19, 2019, at 5:37 AM, gre...@linuxfoundation.org wrote:
>
>
> This is a note to let you know that I've just added the patch titled
>
>drm/mgag200: Flag all G200 SE A machines as broken wrt
>
> to the 5.4-stable tree which can be found at:
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_git_-3Fp-3Dlinux_kernel_git_stable_stable-2Dqueue.git-3Ba-3Dsummary=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=mqHE1ETbyuc9Qg_WHNUzDRBGo073QFCYwTAxpxXEQJU=
>
>
> The filename of the patch is:
> drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
> and it can be found in the queue-5.4 subdirectory.
>
> If you, or anyone else, feels it should not be added to the stable tree,
> please let know about it.
>
>
> From 4adf0b49eea926a55fd956ef7d86750f771435ff Mon Sep 17 00:00:00 2001
> From: Thomas Zimmermann
> Date: Fri, 6 Dec 2019 09:19:01 +0100
> Subject: drm/mgag200: Flag all G200 SE A machines as broken wrt
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> From: Thomas Zimmermann
>
> commit 4adf0b49eea926a55fd956ef7d86750f771435ff upstream.
>
> Several MGA G200 SE machines don't respect the value of the startadd
> register field. After more feedback on affected machines, neither PCI
> subvendor ID nor the internal ID seem to hint towards the bug. All
> affected machines have a PCI ID of 0x0522 (i.e., G200 SE A). It was
> decided to flag all G200 SE A machines as broken.
>
> Signed-off-by: Thomas Zimmermann
> Acked-by: Gerd Hoffmann
> Fixes: 1591fadf857c ("drm/mgag200: Add workaround for HW that does not
> support 'startadd'")
> Cc: Thomas Zimmermann
> Cc: John Donnelly
> Cc: Daniel Vetter
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: David Airlie
> Cc: Sam Ravnborg
> Cc: "Y.C. Chen"
> Cc: Neil Armstrong
> Cc: Thomas Gleixner
> Cc: "José Roberto de Souza"
> Cc: Andrzej Pietrasiewicz
> Cc: dri-devel@lists.freedesktop.org
> Cc: # v5.3+
> Cc: Greg Kroah-Hartman
> Cc: Allison Randal
> Cc: Alex Deucher
> Cc: "Noralf Trønnes"
> Link:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_msgid_20191206081901.9938-2D1-2Dtzimmermann-40suse.de=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=hkr0WOmd31sveBOYMZnLk8Sb2ujD-JxnYwjeSLBw9cA=
>
> Signed-off-by: Greg Kroah-Hartman
>
> ---
> drivers/gpu/drm/mgag200/mgag200_drv.c |3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
> @@ -30,9 +30,8 @@ module_param_named(modeset, mgag200_mode
> static struct drm_driver driver;
>
> static const struct pci_device_id pciidlist[] = {
> - { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
> + { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
> G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
> - { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A
> },
> { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B
> },
> { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
> { PCI_VENDOR_ID_MATROX, 0x532, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_WB },
>
>
> Patches currently in stable-queue which might be from tzimmerm...@suse.de are
>
> queue-5.4/drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
> queue-5.4/drm-mgag200-store-flags-from-pci-driver-data-in-device-structure.patch
> queue-5.4/drm-mgag200-add-workaround-for-hw-that-does-not-support-startadd.patch
> queue-5.4/drm-mgag200-extract-device-type-from-flags.patch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: IGNORE -- Patch "drm/mgag200: Flag all G200 SE A machines as broken wrt " has been added to the 5.4-stable tree
I discovered I was missing a commit when I merged .
This series is fine .
> On Dec 19, 2019, at 12:24 PM, John Donnelly
> wrote:
>
> Hi
>
> I am having difficulties with this patch on : 5.4.2 variant ; The system is
> not booting with these patches applied.
>
> I had verified a prototype of the patch on 5.4.0-rc8 ;
>
> I am currently debugging it , but I will be OoO until 1/6/2020 after today .
>
>
>
>
>
>
>
>
>
>
>> On Dec 19, 2019, at 5:37 AM, gre...@linuxfoundation.org wrote:
>>
>>
>> This is a note to let you know that I've just added the patch titled
>>
>> drm/mgag200: Flag all G200 SE A machines as broken wrt
>>
>> to the 5.4-stable tree which can be found at:
>>
>> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kernel.org_git_-3Fp-3Dlinux_kernel_git_stable_stable-2Dqueue.git-3Ba-3Dsummary=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=mqHE1ETbyuc9Qg_WHNUzDRBGo073QFCYwTAxpxXEQJU=
>>
>>
>> The filename of the patch is:
>>drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
>> and it can be found in the queue-5.4 subdirectory.
>>
>> If you, or anyone else, feels it should not be added to the stable tree,
>> please let know about it.
>>
>>
>> From 4adf0b49eea926a55fd956ef7d86750f771435ff Mon Sep 17 00:00:00 2001
>> From: Thomas Zimmermann
>> Date: Fri, 6 Dec 2019 09:19:01 +0100
>> Subject: drm/mgag200: Flag all G200 SE A machines as broken wrt
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> From: Thomas Zimmermann
>>
>> commit 4adf0b49eea926a55fd956ef7d86750f771435ff upstream.
>>
>> Several MGA G200 SE machines don't respect the value of the startadd
>> register field. After more feedback on affected machines, neither PCI
>> subvendor ID nor the internal ID seem to hint towards the bug. All
>> affected machines have a PCI ID of 0x0522 (i.e., G200 SE A). It was
>> decided to flag all G200 SE A machines as broken.
>>
>> Signed-off-by: Thomas Zimmermann
>> Acked-by: Gerd Hoffmann
>> Fixes: 1591fadf857c ("drm/mgag200: Add workaround for HW that does not
>> support 'startadd'")
>> Cc: Thomas Zimmermann
>> Cc: John Donnelly
>> Cc: Daniel Vetter
>> Cc: Gerd Hoffmann
>> Cc: Dave Airlie
>> Cc: Maarten Lankhorst
>> Cc: Maxime Ripard
>> Cc: David Airlie
>> Cc: Sam Ravnborg
>> Cc: "Y.C. Chen"
>> Cc: Neil Armstrong
>> Cc: Thomas Gleixner
>> Cc: "José Roberto de Souza"
>> Cc: Andrzej Pietrasiewicz
>> Cc: dri-devel@lists.freedesktop.org
>> Cc: # v5.3+
>> Cc: Greg Kroah-Hartman
>> Cc: Allison Randal
>> Cc: Alex Deucher
>> Cc: "Noralf Trønnes"
>> Link:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.freedesktop.org_patch_msgid_20191206081901.9938-2D1-2Dtzimmermann-40suse.de=DwIDaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=Nb5EnzCYEqUCU43_FPM930DrN6A-OrVBoIvQhl3A6xo=hkr0WOmd31sveBOYMZnLk8Sb2ujD-JxnYwjeSLBw9cA=
>>
>> Signed-off-by: Greg Kroah-Hartman
>>
>> ---
>> drivers/gpu/drm/mgag200/mgag200_drv.c |3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
>> @@ -30,9 +30,8 @@ module_param_named(modeset, mgag200_mode
>> static struct drm_driver driver;
>>
>> static const struct pci_device_id pciidlist[] = {
>> -{ PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
>> +{ PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>> G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
>> -{ PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A
>> },
>> { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B
>> },
>> { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
>> { PCI_VENDOR_ID_MATROX, 0x532, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_WB },
>>
>>
>> Patches currently in stable-queue which might be from tzimmerm...@suse.de are
>>
>> queue-5.4/drm-mgag200-flag-all-g200-se-a-machines-as-broken-wrt-startadd.patch
>> queue-5.4/drm-mgag200-store-flags-from-pci-driver-data-in-device-structure.patch
>> queue-5.4/drm-mgag200-add-workaround-for-hw-that-does-not-support-startadd.patch
>> queue-5.4/drm-mgag200-extract-device-type-from-flags.patch
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/mgag200: Flag all G200 SE A machines as broken wrt
> On Dec 6, 2019, at 4:04 AM, Gerd Hoffmann wrote:
>
>> Several MGA G200 SE machines don't respect the value of the startadd
>> register field. After more feedback on affected machines, neither PCI
>> subvendor ID nor the internal ID seem to hint towards the bug. All
>> affected machines have a PCI ID of 0x0522 (i.e., G200 SE A). It was
>> decided to flag all G200 SE A machines as broken.
>
>> -{ PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
>> +{ PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
>> G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
>> -{ PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A
>> },
>
> Acked-by: Gerd Hoffmann
Tested-by: John Donnelly
This series of commits appear to resolve the display issue in 5.4.-rc8 as
reported in :
https://gitlab.freedesktop.org/drm/misc/issues/7
52ca22daadbb 2019-12-06 | drm/mgag200: Flag all G200 SE A machines as broken
wrt
e0f1a41a45b3 2019-12-06 | drm/mgag200: Add workaround for HW that does not
support 'startadd'
11a219a38f2d 2019-12-06 | drm/mgag200: Store flags from PCI driver data in
device structure
a23512ace008 2019-12-06 | drm/mgag200: Extract device type from flags
There is one commit I did not apply :
[PATCH v2] drm/mgag200: Add module parameter to pin all buffers at offset 0
I don’t see a need for that now since we using the PCI-ID of 0x522 for the fix.
>
> cheers,
> Gerd
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=cFYmB62lgH3WoOWZuvgMKjsgMXQUscmrypDlQhYpF_E=21ZEZohFZBQsEr5bo3sS4pMpCf2ca5KXFJq5X3XUzQw=
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: FAILED - [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'
> On Dec 3, 2019, at 11:30 AM, John Donnelly wrote:
>
>
> Hello Sasha and Thomas ,
>
>
> This particular patch has failed on one class of servers that has a slightly
> different Sun Vendor. ID for the BMC video device:
>
> I will follow up with additional details in the review comments for the
> original message,.
>
>
>
>
>> On Nov 28, 2019, at 8:23 AM, Sasha Levin wrote:
>>
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a "Fixes:" tag,
>> fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system()
>> with kunmap + unpin").
>>
>> The bot has tested the following trees: v5.3.13.
>>
>> v5.3.13: Build failed! Errors:
>> drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error:
>> ‘drm_vram_mm_debugfs_init’ undeclared here (not in a function); did you mean
>> ‘drm_client_debugfs_init’?
>>
I had this same issue and removed that from my local 5.4.0-rc8 build
>>
>> NOTE: The patch will not be queued to stable trees until it is upstream.
>>
>> How should we proceed with this patch?
>>
>> --
>> Thanks,
>> Sasha
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=vxMDOLV77rRe2ekdNFH9IxMSBQrTccltZd8A1H6xYCc=efHs2lc_RQYvzLC82c-D3wa8MpX5DCU_YsIo6XruAQg=
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hi ,
See below ,
> On Nov 26, 2019, at 3:50 AM, Thomas Zimmermann wrote:
>
> Hi
>
> Am 26.11.19 um 10:37 schrieb Daniel Vetter:
>> On Tue, Nov 26, 2019 at 08:25:44AM +0100, Thomas Zimmermann wrote:
>>> There's at least one system that does not interpret the value of
>>> the device's 'startadd' field correctly, which leads to incorrectly
>>> displayed scanout buffers. Always placing the active scanout buffer
>>> at offset 0 works around the problem.
>>>
>>> Signed-off-by: Thomas Zimmermann
>>> Reported-by: John Donnelly
>>> Link: https://gitlab.freedesktop.org/drm/misc/issues/7
>>
>> Tested-by: John Donnelly
>>
>> (Not quite this patch, but pretty much the logic, so counts).
>>
>> Fixes: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with kunmap
>> + unpin")
>> Cc: # v5.3+
>>
>> Also you need the stable line on both prep patches too. For next time
>> around,
>>
>> $ dim fixes 81da87f63a1e
>>
>> will generate all the stuff you need, including a good set of suggested
>> Cc: you should have.
>>
>> On the first 3 patches, with all that stuff added:
>>
>> Reviewed-by: Daniel Vetter
>
> Thanks for the review.
>
> Sorry for leaving out some of the tags. I wanted to wait for feedback
> before adding tested-by, fixes, stable. I'll split off patch 4 from the
> series and get 1 to 3 merged ASAP.
>
> Best regards
> Thomas
>
>>
>> Please push these to drm-misc-next-fixes so they get backported as quickly
>> as possible.
>> -Daniel
>>
>>> ---
>>> drivers/gpu/drm/mgag200/mgag200_drv.c | 36 ++-
>>> drivers/gpu/drm/mgag200/mgag200_drv.h | 3 +++
>>> 2 files changed, 38 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> b/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> index 397f8b0a9af8..d43951caeea0 100644
>>> --- a/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c
>>> @@ -30,6 +30,8 @@ module_param_named(modeset, mgag200_modeset, int, 0400);
>>> static struct drm_driver driver;
>>>
>>> static const struct pci_device_id pciidlist[] = {
>>> + { PCI_VENDOR_ID_MATROX, 0x522, PCI_VENDOR_ID_SUN, 0x4852, 0, 0,
>>> + G200_SE_A | MGAG200_FLAG_HW_BUG_NO_STARTADD},
I will have an additional list of vendor IDs (0x4852) I will provide in a
follow up patch shortly . This fixes only 1 flavor of server.
Thank you .
>>> { PCI_VENDOR_ID_MATROX, 0x522, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_A
>>> },
>>> { PCI_VENDOR_ID_MATROX, 0x524, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_SE_B
>>> },
>>> { PCI_VENDOR_ID_MATROX, 0x530, PCI_ANY_ID, PCI_ANY_ID, 0, 0, G200_EV },
>>> @@ -60,6 +62,35 @@ static void mga_pci_remove(struct pci_dev *pdev)
>>>
>>> DEFINE_DRM_GEM_FOPS(mgag200_driver_fops);
>>>
>>> +static bool mgag200_pin_bo_at_0(const struct mga_device *mdev)
>>> +{
>>> + return mdev->flags & MGAG200_FLAG_HW_BUG_NO_STARTADD;
>>> +}
>>> +
>>> +int mgag200_driver_dumb_create(struct drm_file *file,
>>> + struct drm_device *dev,
>>> + struct drm_mode_create_dumb *args)
>>> +{
>>> + struct mga_device *mdev = dev->dev_private;
>>> + unsigned long pg_align;
>>> +
>>> + if (WARN_ONCE(!dev->vram_mm, "VRAM MM not initialized"))
>>> + return -EINVAL;
>>> +
>>> + pg_align = 0ul;
>>> +
>>> + /*
>>> +* Aligning scanout buffers to the size of the video ram forces
>>> +* placement at offset 0. Works around a bug where HW does not
>>> +* respect 'startadd' field.
>>> +*/
>>> + if (mgag200_pin_bo_at_0(mdev))
>>> + pg_align = PFN_UP(mdev->mc.vram_size);
>>> +
>>> + return drm_gem_vram_fill_create_dumb(file, dev, >vram_mm->bdev,
>>> +pg_align, false, args);
>>> +}
>>> +
>>> static struct drm_driver driver = {
>>> .driver_features = DRIVER_GEM | DRIVER_MODESET,
>>> .load = mgag200_driver_load,
>>> @@ -71,7 +102,10 @@ static struct drm_driver driver = {
>>> .major = DRIVER_MAJOR,
>>> .minor = DRIVER_MINOR,
>>> .patchlevel = DRIVER_PATCHLEVEL,
>>> - DRM_GEM_VRAM_DRIVER
>>>
Re: FAILED - [PATCH v2 3/3] drm/mgag200: Add workaround for HW that does not support 'startadd'
Hello Sasha and Thomas ,
This particular patch has failed on one class of servers that has a slightly
different Sun Vendor. ID for the BMC video device:
I will follow up with additional details in the review comments for the
original message,.
> On Nov 28, 2019, at 8:23 AM, Sasha Levin wrote:
>
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a "Fixes:" tag,
> fixing commit: 81da87f63a1e ("drm: Replace drm_gem_vram_push_to_system() with
> kunmap + unpin").
>
> The bot has tested the following trees: v5.3.13.
>
> v5.3.13: Build failed! Errors:
>drivers/gpu/drm/mgag200/mgag200_drv.c:104:18: error:
> ‘drm_vram_mm_debugfs_init’ undeclared here (not in a function); did you mean
> ‘drm_client_debugfs_init’?
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
> --
> Thanks,
> Sasha
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop.org_mailman_listinfo_dri-2Ddevel=DwIGaQ=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=t2fPg9D87F7D8jm0_3CG9yoiIKdRg4qc_thBw4bzMhc=vxMDOLV77rRe2ekdNFH9IxMSBQrTccltZd8A1H6xYCc=efHs2lc_RQYvzLC82c-D3wa8MpX5DCU_YsIo6XruAQg=
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Bugzilla to Gitlabs migration - No email updates ?
Does gitlab not generate email when a comment is added to a ticket ? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 13, 2019, at 2:06 PM, Daniel Vetter wrote: > > On Wed, Nov 13, 2019 at 6:42 PM John Donnelly > wrote: >> >> Hi Thomas: See below >> >>> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote: >>> >>> Hi John >>> >>> Am 12.11.19 um 20:13 schrieb John Donnelly: >>>> >>>> In short . I started with : >>>> >>>> git bisect start >>>> >>>> git bisect bad be8454afc50f >>>> >>>> git bisect good fec88ab0af97 >>>> >>>> And at the the end of bisects showed this was the offending commit : >>>> >>>> c0a74c732568 >>>> >>>> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >>>> Author: Jani Nikula >>>> Date: Fri May 24 20:35:22 2019 +0300 >>>> >>>> drm/i915: Update DRIVER_DATE to 20190524 >>>> >>>> Signed-off-by: Jani Nikula >>>> >>>> That does not have any real relevance >>> >>> No, that doesn't look right. The other bad commits you list below also >>> don't seem to be related. >> >> >> >> Thank you for your patience ; I started over and the bisect took to me to >> this change that certainly reflects the behavior I am seeing : >> >> commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) >> Author: Thomas Zimmermann >> Date: Tue May 21 13:08:29 2019 +0200 >> >>drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin >> >>The push-to-system function forces a buffer out of video RAM. This >> decision >>should rather be made by the memory manager. By replacing the function >> with >>calls to the kunmap and unpin functions, the buffer's memory becomes >> available, >>but the buffer remains in VRAM until it's evicted by a pin operation. >> >>This patch replaces the remaining instances of >> drm_gem_vram_push_to_system() >>in ast and mgag200, and removes the function from DRM. > > Yeah that looks a lot more plausible as the culprit. > >> My 1st impression is we need a method that restores the previous behavior >> that pushes the content to the device . > > Can you pls grab the debugsfs for the above broken kernel (without any > of the later reworks on top), both for console mode and after you > started gnome. Plus I guess booting with drm.debug=0xfe and full dmesg > (please note the timestamp when you started gnome, that helps with > sifting through it all, it's going to be a lot). You might need to > grab the full dmesg from logs on disk, please make sure it includes > everything from boot-up. > > Thanks, Daniel Hi I started a Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=112265 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 13, 2019, at 11:42 AM, John Donnelly > wrote: > > Hi Thomas: See below > >> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote: >> >> Hi John >> >> Am 12.11.19 um 20:13 schrieb John Donnelly: >>> >>> In short . I started with : >>> >>> git bisect start >>> >>> git bisect bad be8454afc50f >>> >>> git bisect good fec88ab0af97 >>> >>> And at the the end of bisects showed this was the offending commit : >>> >>> c0a74c732568 >>> >>> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >>> Author: Jani Nikula >>> Date: Fri May 24 20:35:22 2019 +0300 >>> >>> drm/i915: Update DRIVER_DATE to 20190524 >>> >>> Signed-off-by: Jani Nikula >>> >>> That does not have any real relevance >> >> No, that doesn't look right. The other bad commits you list below also >> don't seem to be related. > > > > Thank you for your patience ; I started over and the bisect took to me to > this change that certainly reflects the behavior I am seeing : > > commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) > Author: Thomas Zimmermann > Date: Tue May 21 13:08:29 2019 +0200 > >drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin > >The push-to-system function forces a buffer out of video RAM. This decision >should rather be made by the memory manager. By replacing the function with >calls to the kunmap and unpin functions, the buffer's memory becomes > available, >but the buffer remains in VRAM until it's evicted by a pin operation. > >This patch replaces the remaining instances of > drm_gem_vram_push_to_system() >in ast and mgag200, and removes the function from DRM. > > > My 1st impression is we need a method that restores the previous behavior > that pushes the content to the device . It appears many of the code changes that were involved in 81da87f63a1 ( above ) have been superseded by : commit 5d17718997367c435dbe5341a8e270d9b19478d3 Author: Thomas Zimmermann Date: Thu Jun 27 10:09:09 2019 +0200 drm/mgag200: Replace struct mga_framebuffer with GEM framebuffer helpers Are there any other methods (tools ) you could recommend outside of starting Gnome that I could use to get a display activity shown on the console ? ===. snipped === ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi Thomas: See below > On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann wrote: > > Hi John > > Am 12.11.19 um 20:13 schrieb John Donnelly: >> >> In short . I started with : >> >> git bisect start >> >> git bisect bad be8454afc50f >> >> git bisect good fec88ab0af97 >> >> And at the the end of bisects showed this was the offending commit : >> >> c0a74c732568 >> >> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >> Author: Jani Nikula >> Date: Fri May 24 20:35:22 2019 +0300 >> >>drm/i915: Update DRIVER_DATE to 20190524 >> >>Signed-off-by: Jani Nikula >> >> That does not have any real relevance > > No, that doesn't look right. The other bad commits you list below also > don't seem to be related. Thank you for your patience ; I started over and the bisect took to me to this change that certainly reflects the behavior I am seeing : commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) Author: Thomas Zimmermann Date: Tue May 21 13:08:29 2019 +0200 drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin The push-to-system function forces a buffer out of video RAM. This decision should rather be made by the memory manager. By replacing the function with calls to the kunmap and unpin functions, the buffer's memory becomes available, but the buffer remains in VRAM until it's evicted by a pin operation. This patch replaces the remaining instances of drm_gem_vram_push_to_system() in ast and mgag200, and removes the function from DRM. My 1st impression is we need a method that restores the previous behavior that pushes the content to the device . > > You could also bisect between your original working commit (v4.18?) and > the one you want to upgrade to (v5.3?). It's only a few more builds but > might be might give better results. > > BTW, are you also converting Gnome from X11 to Wayland. I found that > Gnome's Wayland code is so slow on mgag200 that it's unusable. They > recently added a shadow FB [1] to improve performance, but it won't be > available before Gnome 3.36. I found this issue using gnome-desktop3-3.28.2-1.el8.x86_64 If there is a more specific. RPM I can look at for guidance I will . > > Best regards > Thomas > > [1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/877/diffs > >> >> >> I am not sure if I did the bisects correctly . After each test I did : >> >> >> #1 git bisect bad 827440a90146 >> >> #2 git bisect bad f5b07b04e5f0 >> >> #3 git bisect bad c0a74c732568 >> >> #4 git bisect good 818f5cb3e8fb >> >> #5 git bisect good 6cfe7ec02e85 >> >> #6 git bisect good f71e01a78bee >> >> #7 git bisect good 09a93ef3d60f >> >> #8 git bisect good f1e6b336bafa >> >> #9 git bisect good eaf20e6933dc >> >> #10 git bisect good 63e8dcdb4f8e >> >> #11 git bisect good 397049a03022 >> >> I’ve restarted the bisect without appending the after a the >> “bad|good “ , and so far git is showing the same selections. snip ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann wrote: > > Hi John > > Am 08.11.19 um 19:07 schrieb John Donnelly: >> >> >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote: >>> >>> Hi >>> >>> Am 08.11.19 um 13:55 schrieb John Donnelly: >>>> >>>> >>>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote: >>>>> >>>>> Hi John >>>>> >>>>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>>>> >>>>>> >>>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi John >>>>>>>> >>>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>>>> >>>>>>>>> See inline: >>>>>>>>> >>>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi John, >>>>>>>>>> >>>>>>>>>> apparently the vgaarb was not the problem. >>>>>>>>>> >>>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am investigating an issue where we lose video activity when the >>>>>>>>>>> display is switched from from “text mode” to “graphic mode” >>>>>>>>>>> on a number of servers using this driver.Specifically >>>>>>>>>>> starting the GNOME desktop. >>>>>>>>>> >>>>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>>>> console that emulates text mode? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie >>>>>>>>> : run-level 3; So I guess your term for it is VGA. >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> When you enable graphics mode, does it set the correct resolution? A >>>>>>>>>> lot >>>>>>>>>> of work went into memory management recently. I could imagine that >>>>>>>>>> the >>>>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>>>> correct framebuffer. >>>>>>>>> >>>>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>>>> the output of >>>>>>>>>> >>>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>>> >>>>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>>>> >>>>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>>>> See below for how to get it. >>>>>>> >>>>>>> I built your “tip” ; Still no graphics displayed . >>>>>>> >>>>>>> >>>>>>> mount -t debugfs none /sys/kernel >>>>>>> >>>>>>> cat /proc/cmdline >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ >>>>>>> root=/dev/mapper/ol_ca--dev55-root ro crashkern
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
On 11/11/19 9:57 AM, Thomas Zimmermann wrote: Hi John Am 08.11.19 um 19:07 schrieb John Donnelly: On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote: Hi Am 08.11.19 um 13:55 schrieb John Donnelly: On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote: Hi John Am 07.11.19 um 23:14 schrieb John Donnelly: On Nov 7, 2019, at 10:13 AM, John Donnelly wrote: On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote: Hi John Am 07.11.19 um 14:12 schrieb John Donnelly: Hi Thomas ; Thank you for reaching out. See inline: On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote: Hi John, apparently the vgaarb was not the problem. Am 07.11.19 um 03:29 schrieb John Donnelly: Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver.Specifically starting the GNOME desktop. When you say "text mode", do you mean VGA text mode or the graphical console that emulates text mode? I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. Yes. When you enable graphics mode, does it set the correct resolution? A lot of work went into memory management recently. I could imagine that the driver sets the correct resolution, but then fails to display the correct framebuffer. There is no display at all ; so there is no resolution to mention. If possible, could you try to update to the latest drm-tip and attach the output of /sys/kernel/debug/dri/0/vram-mm I don’t see that file ; Is there something else I need to do ? That file is fairly new and maybe it's not in the mainline kernel yet. See below for how to get it. I built your “tip” ; Still no graphics displayed . mount -t debugfs none /sys/kernel cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff cat /sys/kernel/dri/0/vram-mm In VGA mode : cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used In GRAPHICS mode ( if it matters ) cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used total: 2032, used 1538 free 494 This is interesting. In the graphics mode, you see two buffers of 768 pages each. That's the main framebuffers as used by X (it's double buffered). Then there's a free area and finally two pages for cursor images (also double buffered). That looks as expected. The thing is that in text mode, the areas are allocated. But the driver shouldn't be active, so the file shouldn't exist or only show a single free area. If you want me to double check this I will .I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; Good! Looking through that log file, the card is found at line 79 and the generic X modesetting driver initializes below. That works as expected. I notices that several operations are not permitted (lines 78 and 87). I guess you're starting X from a regular user account? IIRC special permission is required to acquire control of the display. What happens if you start X as root user? I am starting GNOME as root by doing “init 5” from either the console session or from ssh . The default runlevel is 3 on boot . On failing session running your 5.4.0.rc6. 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 237.712] (EE) open /dev/fb0: Permission denied Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 101.334] (EE) open /dev/fb0: Permission denied What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . # cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff When you say “tip”.
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote: > > Hi > > Am 08.11.19 um 13:55 schrieb John Donnelly: >> >> >>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann wrote: >>> >>> Hi John >>> >>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>> >>>> >>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann >>>>>> wrote: >>>>>> >>>>>> Hi John >>>>>> >>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>> >>>>>>> See inline: >>>>>>> >>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> apparently the vgaarb was not the problem. >>>>>>>> >>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I am investigating an issue where we lose video activity when the >>>>>>>>> display is switched from from “text mode” to “graphic mode” >>>>>>>>> on a number of servers using this driver.Specifically starting >>>>>>>>> the GNOME desktop. >>>>>>>> >>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>> console that emulates text mode? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : >>>>>>> run-level 3; So I guess your term for it is VGA. >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> When you enable graphics mode, does it set the correct resolution? A >>>>>>>> lot >>>>>>>> of work went into memory management recently. I could imagine that the >>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>> correct framebuffer. >>>>>>> >>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>> the output of >>>>>>>> >>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>> >>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>> >>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>> See below for how to get it. >>>>> >>>>> I built your “tip” ; Still no graphics displayed . >>>>> >>>>> >>>>> mount -t debugfs none /sys/kernel >>>>> >>>>> cat /proc/cmdline >>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ >>>>> root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto >>>>> resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root >>>>> rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>> >>>>> >>>>> cat /sys/kernel/dri/0/vram-mm >>>>> >>>>> In VGA mode : >>>>> >>>>> >>>>> cat /sys/kernel/dri/0/vram-mm >>>>> 0x-0x0300: 768: used >>>>> 0x0300-0x0600: 768: used >>>>> 0x0600-0x07ee: 494: free >>>>> 0x07ee-0x07ef: 1: used >>>>> 0x07ef-0x07f0: 1: used >>>>> >>>>> >>>>> In GRAPHICS mode ( if it matters ) >>>>> >>>>>
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 7, 2019, at 10:13 AM, John Donnelly wrote: > > > >> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote: >> >> Hi John >> >> Am 07.11.19 um 14:12 schrieb John Donnelly: >>> Hi Thomas ; Thank you for reaching out. >>> >>> See inline: >>> >>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote: >>>> >>>> Hi John, >>>> >>>> apparently the vgaarb was not the problem. >>>> >>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>> Hi, >>>>> >>>>> I am investigating an issue where we lose video activity when the display >>>>> is switched from from “text mode” to “graphic mode” >>>>> on a number of servers using this driver.Specifically starting the >>>>> GNOME desktop. >>>> >>>> When you say "text mode", do you mean VGA text mode or the graphical >>>> console that emulates text mode? >>>> >>> >>> >>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : >>> run-level 3; So I guess your term for it is VGA. >> >> Yes. >> >> >>> >>> >>>> When you enable graphics mode, does it set the correct resolution? A lot >>>> of work went into memory management recently. I could imagine that the >>>> driver sets the correct resolution, but then fails to display the >>>> correct framebuffer. >>> >>> There is no display at all ; so there is no resolution to mention. >>> >>> >>> >>>> >>>> If possible, could you try to update to the latest drm-tip and attach >>>> the output of >>>> >>>> /sys/kernel/debug/dri/0/vram-mm >>> >>> I don’t see that file ; Is there something else I need to do ? >> >> That file is fairly new and maybe it's not in the mainline kernel yet. >> See below for how to get it. > > I built your “tip” ; Still no graphics displayed . > > > mount -t debugfs none /sys/kernel > > cat /proc/cmdline > BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ > root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto > resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root > rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > > > cat /sys/kernel/dri/0/vram-mm > > In VGA mode : > > > cat /sys/kernel/dri/0/vram-mm > 0x-0x0300: 768: used > 0x0300-0x0600: 768: used > 0x0600-0x07ee: 494: free > 0x07ee-0x07ef: 1: used > 0x07ef-0x07f0: 1: used > > > In GRAPHICS mode ( if it matters ) > > > cat /sys/kernel/dri/0/vram-mm > 0x-0x0300: 768: used > 0x0300-0x0600: 768: used > 0x0600-0x07ee: 494: free > 0x07ee-0x07ef: 1: used > 0x07ef-0x07f0: 1: used > total: 2032, used 1538 free 494 > > > > >> >> >>> >>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >> >> Good! Looking through that log file, the card is found at line 79 and >> the generic X modesetting driver initializes below. That works as expected. >> >> I notices that several operations are not permitted (lines 78 and 87). I >> guess you're starting X from a regular user account? IIRC special >> permission is required to acquire control of the display. What happens >> if you start X as root user? > > >I am starting GNOME as root by doing “init 5” from either the console > session or from ssh . > > The default runlevel is 3 on boot . > > On failing session running your 5.4.0.rc6. > > 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) > > 87 [ 237.712] (EE) open /dev/fb0: Permission denied > > Booting 4.18 kernel yields the same error results in: > /var/lib/gdm/.local/share/xorg/Xorg.0.log > > 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not > permitted) > > 87 [ 101.334] (EE) open /dev/fb0: Permission denied > > > What is strange the X logs ( bad and Ok ) files essentially appear as if > GNOME started ! > > > > > > > > > > >> >> >>> >>&g
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann wrote: > > Hi John > > Am 07.11.19 um 14:12 schrieb John Donnelly: >> Hi Thomas ; Thank you for reaching out. >> >> See inline: >> >>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote: >>> >>> Hi John, >>> >>> apparently the vgaarb was not the problem. >>> >>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>> Hi, >>>> >>>> I am investigating an issue where we lose video activity when the display >>>> is switched from from “text mode” to “graphic mode” >>>> on a number of servers using this driver.Specifically starting the >>>> GNOME desktop. >>> >>> When you say "text mode", do you mean VGA text mode or the graphical >>> console that emulates text mode? >>> >> >> >> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : >> run-level 3; So I guess your term for it is VGA. > > Yes. > > >> >> >>> When you enable graphics mode, does it set the correct resolution? A lot >>> of work went into memory management recently. I could imagine that the >>> driver sets the correct resolution, but then fails to display the >>> correct framebuffer. >> >>There is no display at all ; so there is no resolution to mention. >> >> >> >>> >>> If possible, could you try to update to the latest drm-tip and attach >>> the output of >>> >>> /sys/kernel/debug/dri/0/vram-mm >> >> I don’t see that file ; Is there something else I need to do ? > > That file is fairly new and maybe it's not in the mainline kernel yet. > See below for how to get it. I built your “tip” ; Still no graphics displayed . mount -t debugfs none /sys/kernel cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff cat /sys/kernel/dri/0/vram-mm In VGA mode : cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used In GRAPHICS mode ( if it matters ) cat /sys/kernel/dri/0/vram-mm 0x-0x0300: 768: used 0x0300-0x0600: 768: used 0x0600-0x07ee: 494: free 0x07ee-0x07ef: 1: used 0x07ef-0x07f0: 1: used total: 2032, used 1538 free 494 > > >> >> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; > > Good! Looking through that log file, the card is found at line 79 and > the generic X modesetting driver initializes below. That works as expected. > > I notices that several operations are not permitted (lines 78 and 87). I > guess you're starting X from a regular user account? IIRC special > permission is required to acquire control of the display. What happens > if you start X as root user? I am starting GNOME as root by doing “init 5” from either the console session or from ssh . The default runlevel is 3 on boot . On failing session running your 5.4.0.rc6. 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 237.712] (EE) open /dev/fb0: Permission denied Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 101.334] (EE) open /dev/fb0: Permission denied What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! Xorg.0.log.bad Description: Binary data Xorg.0.log.Ok Description: Binary data > > >> >> >> >> >> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test >> was 5.3.8 and it failed also ) . >> >> # cat /proc/cmdline >> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro >> crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap >> rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap >> console=ttyS0,9600,8,n,1 drm.debug=0xff >> >> When you say “tip”. - Are you referring to a specific kernel ? I can build >> a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 >> time frame.
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi Thomas ; Thank you for reaching out. See inline: > On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann wrote: > > Hi John, > > apparently the vgaarb was not the problem. > > Am 07.11.19 um 03:29 schrieb John Donnelly: >> Hi, >> >> I am investigating an issue where we lose video activity when the display is >> switched from from “text mode” to “graphic mode” >> on a number of servers using this driver.Specifically starting the >> GNOME desktop. > > When you say "text mode", do you mean VGA text mode or the graphical > console that emulates text mode? > I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. > When you enable graphics mode, does it set the correct resolution? A lot > of work went into memory management recently. I could imagine that the > driver sets the correct resolution, but then fails to display the > correct framebuffer. There is no display at all ; so there is no resolution to mention. > > If possible, could you try to update to the latest drm-tip and attach > the output of > > /sys/kernel/debug/dri/0/vram-mm I don’t see that file ; Is there something else I need to do ? I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; Xorg.0.log Description: Binary data Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . # cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. > > before and after switching to graphics mode. The file lists the > allocated regions of the VRAM. > >> >> This adapter is Server Engines Integrated Remote Video Acceleration >> Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >> >> I don’t see any specific errors in the gdm logs or message file other than >> this: > > You can boot with drm.debug=0xff on the kernel command line to enable > more warnings. > > > Could you please attach the output of lspci -v for the VGA adapter? > Here is the output from the current machine; The previous addresses were from another model using the same SE device: Nov 7 04:42:50 ca-dev55 kernel: mgag200 :3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc500 -> 0xc5ff Nov 7 04:42:50 ca-dev55 kernel: mgag200 :3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc681 -> 0xc6813fff Nov 7 04:42:50 ca-dev55 kernel: mgag200 :3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc600 -> 0xc67f Nov 7 04:42:50 ca-dev55 kernel: mgag200 :3d:00.0: vgaarb: deactivate vga console lspci -s 3d:00.0 -vvv -k 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) Subsystem: Oracle/SUN Device 4852 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Best regards > Thomas > >> >> fb0: switching to mgag200drmfb from EFI VGA >> mgag200 :04:00.0: vgaarb: deactivate vga console >> fbcon: mgag200drmfb (fb0) is primary device >> mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device >> [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 >> >> The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; >> The symptom first appears in 5.3.6. and onward. >> ___ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Drm: mgag200. Video adapter issue with 5.4.0-rc3
Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver. This adapter is Server Engines integrated Remote Video Acceleration Subsystem (RVAS) is used primarily as remote console , iLO/DRAC environments. I was wondering if anyone could offer any suggestions where to look at . I don’t see any specific errors in the gdm logs or message file other than this: mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b00 -> 0x9bff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c81 -> 0x9c813fff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c00 -> 0x9c7f fb0: switching to mgag200drmfb from EFI VGA mgag200 :04:00.0: vgaarb: deactivate vga console fbcon: mgag200drmfb (fb0) is primary device mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 The systems worked fine 4.18 kernels ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver.Specifically starting the GNOME desktop. This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. I don’t see any specific errors in the gdm logs or message file other than this: mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b00 -> 0x9bff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c81 -> 0x9c813fff mgag200 :04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c00 -> 0x9c7f fb0: switching to mgag200drmfb from EFI VGA mgag200 :04:00.0: vgaarb: deactivate vga console fbcon: mgag200drmfb (fb0) is primary device mgag200 :04:00.0: fb0: mgag200drmfb frame buffer device [drm] Initialized mgag200 1.0.0 20110418 for :04:00.0 on minor 0 The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
