[Bug 112265] Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
https://bugs.freedesktop.org/show_bug.cgi?id=112265 Thomas Zimmermann changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |tzimmerm...@suse.de |.org| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112265] Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
https://bugs.freedesktop.org/show_bug.cgi?id=112265 --- Comment #3 from john.p.donne...@oracle.com --- Created attachment 145950 --> https://bugs.freedesktop.org/attachment.cgi?id=145950&action=edit Running startx on the console This likely doesn't help much On a 4.18 kernel ; when I do "startx" on the console ; it eventually runs gnone. On the bad kernel ; I just see x11 noise ; then nothing . -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112265] Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
https://bugs.freedesktop.org/show_bug.cgi?id=112265 --- Comment #2 from john.p.donne...@oracle.com --- debugfs content : With gnome running # for f in `find . -type f ` ; do > echo "$f : `cat $f` " > done ./VGA-1/edid_override : ./VGA-1/force : unspecified ./internal_clients : ./framebuffer : framebuffer[35]: allocated by = Xorg refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=1024x768 layers: size[0]=1024x768 pitch[0]=4096 offset[0]=0 obj[0]:(null) framebuffer[34]: allocated by = [fbcon] refcount=1 format=XR24 little-endian (0x34325258) modifier=0xb7e2c7450010 size=1024x768 layers: size[0]=1024x768 pitch[0]=4096 offset[0]=4294967295 obj[0]:(null) ./gem_names :name size handles refcount ./clients : command pid dev master a uid magic systemd-logind 1563 0 yy 0 0 ./name : mgag200 dev=:3d:00.0 unique=:3d:00.0 -- You are receiving this mail because: You are the assignee for the bug.___ 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
[Bug 112265] Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
https://bugs.freedesktop.org/show_bug.cgi?id=112265 john.p.donne...@oracle.com changed: What|Removed |Added CC||john.p.donne...@oracle.com --- Comment #1 from john.p.donne...@oracle.com --- Created attachment 145949 --> https://bugs.freedesktop.org/attachment.cgi?id=145949&action=edit dmesg and message file on bi-sected kernel Starting gnome See messages for " starting gnome " and " Stopping gnome " -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112265] Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
https://bugs.freedesktop.org/show_bug.cgi?id=112265 Bug ID: 112265 Summary: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: DRM/other Assignee: dri-devel@lists.freedesktop.org Reporter: john.p.donne...@oracle.com bisect took to me to this change that certainly reflects the behavior I am seeing : 5.1.0-rc5 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 . 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 . -- You are receiving this mail because: You are the assignee for the bug.___ 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 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 > > > > > > > > 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ 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
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. 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. 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. > > > > > > > ___ > 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 signature.asc Description: OpenPGP digital signature ___ 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 Tue, Nov 12, 2019 at 8:13 PM John Donnelly wrote: > > > > > 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 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/
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 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 n
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
Hi just a few more comments. Am 11.11.19 um 18:40 schrieb John Donnelly: > 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 Reconsidering this output, it actually makes sense. X11 only allocates a single framebuffer and uses an additional shadow buffer for its rendering. So the memory map is OK. I'm having some problems with running Gnome 3.34 (3.32 is fine), which makes it hard to distinguish Gnome errors from driver errors. I guess I'm back to step 1. :( Best regards Thomas >> >> 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, t
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”. - Are you referri
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
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
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
On Fri, Nov 8, 2019 at 7:07 PM John Donnelly wrote: > > > > > 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 c
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 ) > > > 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.rc
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
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 >>
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
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. >> >> >> >>> >>> 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=ttyS
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 ! > > > > > > > > > > >> >> >>> >>> >>> >>> >>> 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. >> >> The latest and greatest DRM code is in the drm-tip branch at >> >> git://anongit.freedesktop.org/drm/drm-tip >> >> If you build this version you should find >> >> /sys/kernel/debug/dri/0/vram-mm >> >> on the device. You have to build with debugfs enabled and >> maybe have to mount debugfs at /sys/kernel/debug. >> >> >>> >>> b
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. > > The latest and greatest DRM code is in the drm-tip branch at > > git://anongit.freedesktop.org/drm/drm-tip > > If you build this version you should find > > /sys/kernel/debug/dri/0/vram-mm > > on the device. You have to build with debugfs enabled and > maybe have to mount debugfs at /sys/kernel/debug. > > >> >> >>> >>> 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
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
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’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? > > > > > 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. The latest and greatest DRM code is in the drm-tip branch at git://anongit.freedesktop.org/drm/drm-tip If you build this version you should find /sys/kernel/debug/dri/0/vram-mm on the device. You have to build with debugfs enabled and maybe have to mount debugfs at /sys/kernel/debug. > > >> >> 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-Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > NUMA node: 0 > Region 0: Memory at c500 (32-bit, non-prefetchable) [size=16M] > Region 1: Memory at c681 (32-bit, non-prefetchable) [size=16K] > Region 2: Memory at c600 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at 000c [disabled] [size=128K] > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA > PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [e4] Express
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
Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics
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? 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. If possible, could you try to update to the latest drm-tip and attach the output of /sys/kernel/debug/dri/0/vram-mm 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. > > > 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 Could you please attach the output of lspci -v for the VGA adapter? 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 signature.asc Description: OpenPGP digital signature ___ 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
