Created attachment 11229 [details] Xorg.0.log from mga7 i585 host gx27c (EE) highlights from the attachment: [ 116.801] (EE) open /dev/dri/card0: No such file or directory [ 116.845] (EE) MGA(0): Unable to map Framebuffer F8000000 2000000. Invalid argument (22) [ 116.887] (EE) MGA(0): Unable to detect video RAM. [ 116.887] (EE) Screen(s) found, but none have a usable configuration. [ 116.887] (EE) [ 116.888] (EE) no screens found(EE) Original summary: [Matrox G400 102b:0525] (EE) open /dev/dri/card0: No such file or directory (Xorg fails to run) Quoting https://www.mageia.org/en/support/ [quote]Graphic card: any AMD/ATI, Intel, Matrox, Nvidia, SiS or VIA graphic card;[/quote] According to that quote, mga7 continues to support Matrox G400, but after urpmi upgrading from mga6, in which x11-driver-video-mga was successfully utilized, this does not seem to be the case, at least not with the Matrox X11 driver. In https://lists.x.org/archives/xorg/2019-July/059869.html I noted that on the same host gx27c running Debian 10 Buster the matrox DDX works near normally. That thread was started by another Debian 10 user unable to use his Matrox in Xorg. Host gx27c has also installed Tumbleweed and Fedora 29. Fedora provides no mga DDX. TW loads FBDEV even though xf86-video-mga is installed (undefined symbol: shadowUpdatePacked from attempting mga_drv.so load). From running Buster: # inxi -GxxSa System: Host: gx27c Kernel: 4.19.0-5-686 i686 bits: 32 compiler: gcc v: 8.3.0 parameters: root=/dev/sda20 net.ifnames=0 noresume mitigations=auto consoleblank=0 3 Desktop: Trinity R14.0.7 tk: Qt 3.5.0 wm: Twin dm: startx Distro: Debian GNU/Linux 10 (buster) Graphics: Device-1: Matrox Systems MGA G400/G450 driver: N/A bus ID: 01:00.0 chip ID: 102b:0525 Display: tty server: X.Org 1.20.4 driver: mga unloaded: modesetting alternate: fbdev,vesa resolution: 1680x1050~60Hz OpenGL: renderer: llvmpipe (LLVM 7.0 128 bits) v: 3.3 Mesa 18.3.6 compat-v: 3.1 direct render: Yes
I finally recognized the difference between mga not working and debian working, then remembered that vga= anything except "normal" on kernel cmdline causes the server failure. Without vga= on cmdline, X works normally in mga7. Thus this must be an upstream bug, but upstream where? Kernel? Xorg? MGA driver? Other??? Also (might be related?), video= on cmdline is ignored in both mga7 (kernel 5.1.18) and debian 10 (kernel 4.19.x), but not mga6 (kernel 4.14.131) or Debian 9 (kernel 4.9.x). The annoying result of these two problems is the vttys are all limited to 80x25 mode if a respectably working X is desired.
(In reply to Felix Miata from comment #1) > I finally recognized the difference between mga not working and debian > working, then remembered that vga= anything except "normal" on kernel > cmdline causes the server failure. Without vga= on cmdline, X works normally > in mga7. Thus this must be an upstream bug, but upstream where? Kernel? > Xorg? MGA driver? Other??? CC'ing the kernel & drivers maintainers and tv, on of them might know, or at least know how to find out. > > Also (might be related?), video= on cmdline is ignored in both mga7 (kernel > 5.1.18) and debian 10 (kernel 4.19.x), but not mga6 (kernel 4.14.131) or > Debian 9 (kernel 4.9.x). The annoying result of these two problems is the > vttys are all limited to 80x25 mode if a respectably working X is desired.
CC: (none) => kernel, marja11, thierry.vignaud
Don't know why this is still in Bugsquad for one year. Assigned to the package maintainer. (Please set the status to 'assigned' if you are working on it). Seems there is a fix in Comment 1.
Assignee: bugsquad => kernelKeywords: (none) => TriagedCC: (none) => ouaurelien
Comment describes a poor workaround.
Comment #1 describes a poor workaround.
CC: ouaurelien => (none)
Full updates to 7.1 haven't changed anything, and neither have kernels 5.5.15, 5.6.14 or 5.7.14.
8 bad too, and Debian 10 & 11. Upstream bug reported: https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/19
URL: (none) => https://gitlab.freedesktop.org/xorg/driver/xf86-video-mga/-/issues/19
Is kernel 5.8.4 from cauldron affected too?
CC: (none) => ghibomgx
I didn't try before mothballing host gx27c. I expect 5.8.x would also fail based upon this: https://bugzilla.opensuse.org/show_bug.cgi?id=1175754#c4
Mageia 7 is EOL since July 1st 2021. There will not have any further bugfix for this release. You are encouraged to upgrade to Mageia 8 as soon as possible. @reporter, if this bug still apply with Mageia 8, please let us know it. @packager, if you work on the Mageia 7 version of your package, please check the Mageia 8 package if issue is also present. In this case, please fix the Mageia 8 version instead. This bug report will be closed OLD if there is no further notice within 1st September 2021.
Hi bug reporter and hi assignee and others involved, Please reopen this bug report if it is still valid for Mageia 8 or 9(cauldron), and change "Version:" in the upper left of this report accordingly. This report is being closed as OLD because it was filed against Mageia 7, for which support ended on June 30th 2021. Thanks, Marja
Status: NEW => RESOLVEDResolution: (none) => OLD