Bug 1004453 - [mga] no Xorg with Matrox gfxcard when valid vga= mode included on kernel cmdline to produce desirable vttys
[mga] no Xorg with Matrox gfxcard when valid vga= mode included on kernel cmd...
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: X.Org
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Max Staudt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-13 08:29 UTC by Felix Miata
Modified: 2021-04-03 05:06 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Xorg.0.log from i586 TW host a-865 (7.54 KB, text/plain)
2016-10-13 08:29 UTC, Felix Miata
Details
dmesg after startx aborted; with vga=791 on host a-865 cmdline; booted to multi-user.target (62.51 KB, text/plain)
2016-10-13 19:12 UTC, Felix Miata
Details
dmesg after startx exited normally; without vga= on host a-865 cmdline; booted to multi-user.target (72.68 KB, text/plain)
2016-10-13 19:13 UTC, Felix Miata
Details
dmesg after kdm3 fails to start; with vga=791 on host a-865 cmdline; booted to graphical.target (61.36 KB, text/plain)
2016-10-13 19:13 UTC, Felix Miata
Details
dmesg after KDM3 greeter appears; without vga= on host a-865 cmdline; booted to graphical.target (61.46 KB, text/plain)
2016-10-13 19:13 UTC, Felix Miata
Details
oops from journalctl (6.17 KB, text/plain)
2017-03-08 02:47 UTC, Felix Miata
Details
systemd-analyze blame from failed attempt to boot directly to KDM3 (2.69 KB, text/plain)
2017-03-08 07:42 UTC, Felix Miata
Details
[rv250] 2 boots' dmesgs, first with vga=791 aborting Xorg, 2nd without vga= after successful startx to KDE3 session and exit (72.97 KB, text/plain)
2017-03-08 13:24 UTC, Felix Miata
Details
[rv250] on TW dmesgs booted with (black screen straight away) and without vga=791 on cmdline (after startx produced black screen) (103.71 KB, text/plain)
2017-03-08 14:33 UTC, Felix Miata
Details
rv250 Xorg.0.logs from 32-bit TW 20170305 host a-865 with and without vga=791 on cmdline (6.17 KB, text/plain)
2017-03-08 21:03 UTC, Felix Miata
Details
/proc/config.gz from running Mageia 5 kernel 4.4.50-desktop-2.mga5 (45.77 KB, application/octet-stream)
2017-03-15 19:02 UTC, Felix Miata
Details
tail of dmesg -w > somefile plus head of Xorg.0.log trying to run startx (36.71 KB, text/plain)
2017-03-16 09:37 UTC, Felix Miata
Details
/proc/config.gz from TW 20170308 booted to pae kernel 4.2.3 on Matrox 550 host a-865 (40.83 KB, application/octet-stream)
2017-03-16 10:08 UTC, Felix Miata
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2016-10-13 08:29:42 UTC
Created attachment 697145 [details]
Xorg.0.log from i586 TW host a-865

Mailing list thread starter:
https://lists.opensuse.org/opensuse/2016-08/msg00322.html
(same with kernels 4.7.x as with kernel 4.6.4) :
# Xorg.0.log excerpts
X.Org X Server 1.18.4
[    57.691] Current Operating System: Linux a-865 4.7.4-1-default #1 SMP Thu Sep 15 09:03:59 UTC 2016 (6a5bbb1) i686
[    57.691] Kernel command line: root=LABEL=os133SS25 ipv6.disable=1 net.ifnames=0 noresume splash=0 vga=791 video=1024x768@60 3
[    58.342] (EE) open /dev/dri/card0: No such file or directory
[    58.382] (EE) MGA(0): Unable to map Framebuffer F0000000 2000000.  Invalid argument (22)
[    58.382] (EE) MGA(0): Unable to detect video RAM.
[    58.382] (EE) Screen(s) found, but none have a usable configuration.
[    58.383] (EE)
[    58.383] (EE) no screens found(EE)...

I didn't update this installation for many months, which explains large gap between installed kernels. Xorg and vttys work as expected with kernel-pae 4.2.3 and vga=791 on cmdline, but vga= needs to be omitted with the newer kernels for Xorg to start. Omitting vga= from cmdline results in far too few columns and rows on the vttys. I looked on bugs.freedesktop.org but found nothing like this. I tried a fresh zypper up, but kernel-default 4.7.6 with vga=788 proved no better, as did kernel-vanilla. Also didn't help adding to xorg.conf device section either VideoRam 16384 and/or Option "OldDmaInit" "On".

# zypper se -si | egrep 'x11-serv|mga|kernel'
il | kernel-default                       | package     | 4.7.4-1.1                      | i586   | (System Packages)
il | kernel-default                       | package     | 4.6.4-2.2                      | i586   | (System Packages)
il | kernel-default                       | package     | 4.7.6-1.1                      | i586   | OSS
i  | kernel-firmware                      | package     | 20160913-1.1                   | noarch | OSS
il | kernel-pae                           | package     | 4.2.3-1.4                      | i686   | (System Packages)
i  | kernel-vanilla                       | package     | 4.7.6-1.1                      | i686   | OSS
i  | nfs-kernel-server                    | package     | 1.3.4-2.2                      | i586   | OSS
i  | xf86-video-mga                       | package     | 1.6.4-2.2                      | i586   | OSS
i  | xorg-x11-server                      | package     | 7.6_1.18.4-1.2                 | i586   | OSS
# lspci | grep VGA
01:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. Millennium G550 (rev 01)
Comment 1 Stefan Dirsch 2016-10-13 09:03:02 UTC
Isn't the issue here, that Xorg is no longer run with root privileges? I'm afraid vga boot param is no longer been used since every driver switched to KMS.
Comment 2 Max Staudt 2016-10-13 10:41:24 UTC
Felix, could you please provide 'dmesg' from the new kernel, both with and without the vga= parameter? I would like to see what the graphics stack looks like in both configurations.
Comment 3 Egbert Eich 2016-10-13 12:30:10 UTC
vga= is not supported by grub2 any more. AFAIR, Felix is using a grub1 setup and starts the Xserver using 'startx' (probably as a regular user) with some scripts on top.
startx really isn't supported any more either - which doesn't mean it won't work, however one needs to know very well what needs to be done to make it work.

Felix: Does it work when you do the same as 'root'?

This may be due newer kernels not allowing to share iomem between drivers - see:
bsc#971907 
Or it may be due to PCI ROM not being made accessible. See the pci=.. command line option.
Comment 4 Felix Miata 2016-10-13 19:12:58 UTC
Created attachment 697273 [details]
dmesg after startx aborted; with vga=791 on host a-865 cmdline; booted to multi-user.target
Comment 5 Felix Miata 2016-10-13 19:13:08 UTC
Created attachment 697274 [details]
dmesg after startx exited normally; without vga= on host a-865 cmdline; booted to multi-user.target
Comment 6 Felix Miata 2016-10-13 19:13:16 UTC
Created attachment 697275 [details]
dmesg after kdm3 fails to start; with vga=791 on host a-865 cmdline; booted to graphical.target
Comment 7 Felix Miata 2016-10-13 19:13:24 UTC
Created attachment 697276 [details]
dmesg after KDM3 greeter appears; without vga= on host a-865 cmdline; booted to graphical.target
Comment 8 Felix Miata 2016-10-13 19:25:18 UTC
(In reply to Egbert Eich from comment #3)
> ...AFAIR, Felix is using a grub1 setup
> and starts the Xserver using 'startx' (probably as a regular user) with some
> scripts on top.

Your memory is correct, though using startx only applies on my test installations, of which host a-865 is one, and runs no extra scripts at startx time.

> Felix: Does it work when you do the same as 'root'?

Of late I've only ever logged in on a-865 as root. That host is only used to see what works or not, mostly only inside the router except for zypper updating.

(In reply to Stefan Dirsch from comment #1)
> Isn't the issue here, that Xorg is no longer run with root privileges? I'm
> afraid vga boot param is no longer been used since every driver switched to
> KMS.

Matrox doesn't respond to video= on cmdline, so vga= is how I was getting the vttys to use a satisfactory mode - until this regression. Even on Intel, AMD and NVidia hardware, vga= still does what it always did pre-KMS for the initial stages of init. KMS only kicks in the video= parameter later in init. I don't use Plymouth on anything unless forced (e.g. Mageia).
Comment 9 Stefan Dirsch 2016-10-14 09:11:56 UTC
Max, this is still Matrox G550. There is no KMS support available for this old GPU. IIRC Egbert only worked on KMS support for old (non-server) G200 chipsets.
Comment 10 Max Staudt 2016-10-14 15:40:11 UTC
Okay, as expected, vga= lets the kernel load vesafb.

However, for some reason, when vga= is used and/or when vesafb is used, the mga DRM module is not loaded...
Comment 11 Max Staudt 2016-11-16 09:37:54 UTC
I placed a Matrox Mystique in a test box and started Tumbleweed.

I've been able to observe several things:

1. The mga kernel module isn't loaded by default.
  -> No idea why.
  -> No 3D acceleration, which wouldn't work anyway since Mesa has long dropped Matrox support.

2. Even without mga, X comes up with its own MGA 2D driver when run as root.
  -> So you may or may not need the mga module if X can access system memory as root.
     It does reference firmware files when checked with 'modinfo mga', so I don't know.

3. But only if vesafb isn't loaded.
  -> Thus, vga= must not be used to set a graphical mode.

Given that the X server now runs as a regular user in Tumbleweed, I see no real solution for you, other than a hack such as setting the X server setuid root :(

Debugging the mga kernel module failing to load automatically also seems pointless, given that modesetting is apparently done via direct memory access and that there is no user of the DRI1 infrastructure left (Mesa dropped the 3D support for Matrox several years ago).

If you're so inclined, you can try to port the modesetting code for your card from the X driver to the new mgag200 kernel module (which was actually meant for the new G200-like chips found in server chipsets). I haven't looked into the code, so I don't know whether this is feasible.

Egbert Eich has done this for the classic G200 chips. See:

  http://kernel.opensuse.org/cgit/kernel-source/tree/patches.drivers/drm-mgag200-Add-support-for-MATROX-PCI-device-IDs-0x520-and-0x521.patch?h=openSUSE-42.2

If you do this, please let me know. As a former Matrox user myself, I would be very glad to see these cards supported with KMS.


As for solving the problem at hand, I suggest setting a video mode in GRUB and making sure it's passed on to Linux when booting (see GRUB's gfxmode and gfxpayload settings). If your card's VESA BIOS supports your screen's native resolution, Linux will pass the setting to vesafb and you can use X with its fbdev driver. Make sure to uninstall xf86-video-mga, which is installed automatically if a Matrox card is found.


Feedback as to what you've tried and whether you found a solution that works for you would be great! Maybe we'll have to kick xf86-video-mga from the default installation.
Comment 12 Max Staudt 2016-12-20 13:01:19 UTC
Since we're not going to write a graphics driver for G550, closing this as RESOLVED WONTFIX.

If you happen to do this yourself, you're more than welcome to ping us and we'll see it integrated if possible.
Comment 13 Felix Miata 2017-03-08 02:47:02 UTC
Created attachment 716675 [details]
oops from journalctl

I discovered what follows as a consequence of investigating a mailing list thread with the closest video hardware match I could come up with (list user has Radeon 9250):
"42,2 installed -> black display"
https://lists.opensuse.org/opensuse/2017-03/msg00163.html

# grep RETT /etc/*lease
PRETTY_NAME="openSUSE Tumbleweed"
# uname -a
Linux a-865 4.9.11-1-default #1 SMP Sat Feb 18 17:59:27 UTC 2017 (cf9c670) i686 i686 i386 GNU/Linux
# inxi -c0 -G
Graphics:  Card: Advanced Micro Devices [AMD/ATI] RV250/M9 GL [Mobility FireGL 9000/Radeon 9000]
           Display Server: X.org 1.18.4 drivers: ati,vesa (unloaded: modesetting,fbdev,radeon)
           tty size: 111x36 Advanced Data: N/A for root
# lspci -xxk | grep -A2 VGA
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] (rev 01)
        Subsystem: Device 0082:0515
        Kernel modules: radeon

With this rv250 AGP card I replaced the comment 0 Matrox 550 card with because of this bug. Could this have nothing to do directly or even at all with Matrox? With the rv250 I must also remove vga= from cmdline to avoid black screen, leaving the framebuffer ttys running in 80x25 mode, and no /dev/fb* devices.

(startx won't start Xorg either:
"(EE) systemd-logind: failed to take device /dev/dri/card0: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken."
Trying  locks up console I/O entirely, requiring remote login or reset button to proceed.
Trying to boot directly to graphical.target fails to reach login manager KDM3:
[    43.128] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[    43.129] (II) xfree86: Adding drm device (/dev/dri/card0))
Comment 14 Felix Miata 2017-03-08 03:16:53 UTC
I forgot to note that with the rv250 the video= cmdline parameter, which for me with all non-antique ATI, Intel and NVidia gfxcards works as expected (with Grub; Grub2 not installed, not used), seems to be entirely disregarded.
Comment 15 Felix Miata 2017-03-08 07:42:55 UTC
Created attachment 716701 [details]
systemd-analyze blame from failed attempt to boot directly to KDM3

I put the comment 0 Matrox 550 in a PC running TW that still has
Linux kt400 4.4.0-2-default #1 SMP Thu Jan 21 07:47:10 UTC 2016 (b56b151) i686 athlon i386 GNU/Linux
installed. I updated all except kernel to TW20170305. Xorg 1.19.1 starts to start with vga=791 included, but this is the Xorg.0.log tail:
# tail Xorg.0.log
[   111.771] (II) evdev: AT Translated Set 2 keyboard: Configuring as keyboard
[   111.771] (**) Option "config_info" "udev:/sys/devices/platform/i8042/serio0/input/input0/event0"
[   111.771] (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD, id 9)
[   111.771] (**) Option "xkb_rules" "evdev"
[   111.771] (**) Option "xkb_layout" "us"
[   111.773] (II) config/udev: Adding input device PC Speaker (/dev/input/event3)
[   111.773] (II) No input driver specified, ignoring this device.
[   111.773] (II) This device may have been added with another device file.
[   111.790] (EE)
[   111.790] (EE) Backtrace:

Tail of journalctl -b:
Mar 07 22:53:03 kt400 systemd[1]: Started Process Core Dump (PID 1378/UID 0).
Mar 07 22:53:06 kt400 systemd-coredump[1379]: Process 1369 (X) of user 0 dumped core.

Startx/KDM3 with 4.4.0 kernel produce only a black screen without or without vga= on cmdline.

Attached Xorg.0.log is from booting 4.4.0 *with* vga=791 on cmdline.

I've saved systemd coredumps at this juncture on kernel 4.4.0, 4.5.0, 4.6.2 & 4.9.11 in TW20170305 in case they might prove of any use. With 4.4.0, the coredumps occurred whether or not vga=791 was on cmdline, and Xorg.0.logs looked similar. With 4.5.0 and newer kernels, coredumps were only generated if vga=791 was absent from cmdline, and Xorg.0.logs were very different, with vga=791 present only 6k in size and terminating with no screens have usable configuration, while without vga=791 they were approaching 38k in size and terminated as shown above with (EE) Backtrace:. This leads me to suspect this bug may have arisen in the window between 4.4.0 and 4.5.0.

Without vga= on cmdline and with kernel-default-4.9.11, KDE3 via startx is again working as expected, though with no /dev/fb* and with vttys stuck at 80x25.

Attempting boot directly to graphical.target KDM3 generates no onscreen errors, but neither starts the greeter. The journal says only display-manager.service timed out/failed to start/entered failed state. 
CPU: Single core AMD Athlon XP 2000+ (-UP-) speed: 1674 MHz (max)
Booting multi-user then doing 'systemctl isolate graphical.target' succeeds to create a usable KDM3 greeter and allow successful login.
Comment 16 Max Staudt 2017-03-08 11:16:29 UTC
To me, this sounds like a problem with the radeon kernel driver. It's what provides KMS and the fb device on modern systems.

In any case, we no longer have a setup to test AGP graphics in, so we won't be able to reproduce your problem I'm afraid.

Could you please post a full dmesg output? Maybe we'll spot something.
Comment 17 Felix Miata 2017-03-08 13:24:51 UTC
Created attachment 716737 [details]
[rv250] 2 boots' dmesgs, first with vga=791 aborting Xorg, 2nd without vga= after successful startx to KDE3 session and exit
Comment 18 Max Staudt 2017-03-08 13:49:04 UTC
There is no mention of radeon whatsoever in the dmesg (?)

The first run boots with vesafb, as expected. The second one without.

Since AFAIK, xf86-video-ati no longer knows how to do UMS, you're probably using xf86-video-fbdev in the first boot, and xf86-video-vesa in the second.

No idea why it crashes in the first case though. Could you please attach Xorg logs for both cases? I'm curious.


Please note that this may well be a separate bug from the Matrox case.
Comment 19 Felix Miata 2017-03-08 14:33:33 UTC
Created attachment 716751 [details]
[rv250] on TW dmesgs booted with (black screen straight away) and without vga=791 on cmdline (after startx produced black screen)

Sorry, I got my miscreant mga and ati machines' problems mixed up. 716737 was from Matrox 550.
Comment 20 Max Staudt 2017-03-08 16:24:54 UTC
Hmm, the X logs would be interesting here, for completeness' sake. I suspect that the vga= case runs with xf86-video-vesa.

To be honest, something is awfully wrong. From the vga=791 log:

  checking generic (e0000000 8000000) vs hw (0 0)

Where is radeon's memory window for accessing the hardware?

Also, why does the kernel crash when initializing GPU memory support (the second crash)? I'm not surprised it never manages to set up a radeon framebuffer console.


So this could well be a bug in the AGP support. I'm sorry, but we don't have hardware to reproduce, and much less debug this. Please look into an upstream bug report, and you also can bisect the (upstream) kernel yourself.

Another thing you can try is newer graphics cards (r300 or newer), and systems with AGP chipsets made by manufacturers other than Intel.
Comment 21 Stefan Dirsch 2017-03-08 16:50:25 UTC
Yeah. Max is probably right. KMS is possibly broken with AGP cards in general (generic issue in latest kernels maybe?). So with vga param the fallback is fbdev driver, otherwise vesa driver. X logfiles should confirm this. And yes, we no longer have any AGP machines and/or AGP cards for testing available. I believe I can still find some R300 PCIe cards, which may still work with the current radeon KMS driver. Never tested this though.
Comment 22 Felix Miata 2017-03-08 21:03:28 UTC
Created attachment 716806 [details]
rv250 Xorg.0.logs from 32-bit TW 20170305 host a-865 with and without vga=791 on cmdline

(In reply to Max Staudt from comment #20)
> So this could well be a bug in the AGP support. I'm sorry, but we don't have
> hardware to reproduce, and much less debug this. Please look into an
> upstream bug report

Which upstream, kernel? Xorg server? Radeon driver?

> , and you also can bisect the (upstream) kernel yourself.

Not really AFAICT. I only do available rpms. B.S. is not something I can deal with.
 
> Another thing you can try is newer graphics cards (r300 or newer), and
> systems with AGP chipsets made by manufacturers other than Intel.

I have rv370 Radeon PCIe working apparently as expected on host gx151's 32-bit TW20170308/Plasma both from startx and KDM, though ATM it has no Plasma system sound output.

I have no Radeon AGP newer than rv250. I have AGP NV11 GeForce on 32-bit host gx270 yet to try updating since August....
Comment 23 Stefan Dirsch 2017-03-08 21:47:40 UTC
Thanks. But seems instead of /var/log/Xorg.0.log files you've attached the output of startx command (most of log is missing there).
Comment 24 Felix Miata 2017-03-08 22:17:25 UTC
/var/log/Xorg.0.log is coming up only ~3000 bytes depending on whether using startx (3273) or starting in graphical.target (2905). I don't know anything about getting a startup log from startx. Last normal size saved Xorg.0.log  on a-865 TW was 5 Dec, 88kb, when it still had the Matrox 550 using VESA(0).
Comment 25 Stefan Dirsch 2017-03-08 23:07:35 UTC
Xorg -retro -logverbose 9 :99
kill it with Ctrl-Alt-BS (press BS twice shortly afterwards)
--> /var/log/Xorg.99.log
Comment 26 Felix Miata 2017-03-09 01:15:40 UTC
(In reply to Stefan Dirsch from comment #25)
> Xorg -retro -logverbose 9 :99
> kill it with Ctrl-Alt-BS (press BS twice shortly afterwards)
> --> /var/log/Xorg.99.log

Is that supposed to be done via remote login? Booted to graphical.target with vga=791 on cmdline, there is only black screen and no keyboard response. I tried Xorg -retro -logverbose 9 :99 from remote anyway, but without killing this DE session with Ctrl-Alt-BS. Xorg.99.log after reset button reboot was only 2964 bytes, and Xorg.0.log 2963.

Booted without vga=791 to multi-user.target, and logged in, Xorg -retro -logverbose 9 :99 simply displayed on the screen content like these short Xorg.#.logs, and Ctrl-Alt-BS only produces ^[^H^[^H, and a new Xorg.99.log of only 2947 bytes.
Comment 27 Felix Miata 2017-03-09 10:12:59 UTC
(In reply to Max Staudt from comment #18)
> Please note that this may well be a separate bug from the Matrox case.

I search fruitlessly on bugs.freedesktop.org and bugzilla.kernel.org for anything similar to comment 13 et seq....

(In reply to Felix Miata from comment #22)
> I have no Radeon AGP newer than rv250. I have AGP NV11 GeForce on 32-bit
> host gx270 yet to try updating since August....

TW20170308 on nv11 host gx270 works as expected.

I replaced the rv250 gfxcard in host a-865 with an rv200 (Radeon 7500). It solved all problems described in comment 13 et seq., suffering AFAICT only https://bugs.freedesktop.org/show_bug.cgi?id=90572

I tried the rv250 in host gx270, but it won't POST with it. Host a-865 is logistically unsuited to try replicating with another OS, so I'm trying to find some other x86 AGP host in which to try the rv250 that has a CPU with at least sse2 to see if this trouble can be replicated in Mageia, Fedora or other before filing a new bug....
Comment 28 Stefan Dirsch 2017-03-09 10:35:10 UTC
(In reply to Felix Miata from comment #26)
> (In reply to Stefan Dirsch from comment #25)
> > Xorg -retro -logverbose 9 :99
> > kill it with Ctrl-Alt-BS (press BS twice shortly afterwards)
> > --> /var/log/Xorg.99.log
> 
> Is that supposed to be done via remote login? Booted to graphical.target
> with vga=791 on cmdline, there is only black screen and no keyboard
> response. I tried Xorg -retro -logverbose 9 :99 from remote anyway, but
> without killing this DE session with Ctrl-Alt-BS. Xorg.99.log after reset
> button reboot was only 2964 bytes, and Xorg.0.log 2963.
> 
> Booted without vga=791 to multi-user.target, and logged in, Xorg -retro
> -logverbose 9 :99 simply displayed on the screen content like these short
> Xorg.#.logs, and Ctrl-Alt-BS only produces ^[^H^[^H, and a new Xorg.99.log
> of only 2947 bytes.

Yes, doing it remotely is absolutely fine. No idea, why X logfiles get truncated. I need to give up at this point. Sorry.
Comment 29 Max Staudt 2017-03-09 10:51:34 UTC
Okay, at this point, things are very unclear.

Several cards behave weirdly, some don't even POST. There are too many unknown factors at play:

 - we have several cards: G550, rv200, rv250.
 - there may be a bug in the kernel's AGP support
 - there may be a bug in the kernel's radeon driver
 - some setups don't even POST (bad bios, bad card, weird hardware?)
 - the X logs are truncated (leftover xorg.conf?)
 - there's a systemd complaint at the end of the X log in comment 22

I've lost track of things. Too many machines, too many cards, too many strange behaviors, too many packages. This bug is a Bugzilla hijack feast.

Okay, PCIe seems to work as expected. Phew. Let's tick that off.

Looking at AGP, we don't have the means to reproduce that. All we can do is look at logs. Please open a new bug to describe one single problem. However, given that our hands are tied (as described), please understand that we will probably have to close it.

Let's bury this particular bug here, as it has become too crowded.

Thanks again for your testing, it is really helpful to know where we stand.
Comment 30 Felix Miata 2017-03-12 04:57:28 UTC
The problem with the rv250 on host a-865 has been solved via a PC BIOS change. Apparently AGP Aperture Size of 32 isn't sufficient for the rv250, while it was for the Matrox 550. Upping it to 64 made the rv250 behave as expected.

I temporarily returned the Matrox 550 to a-865 to confirm 64 is no help for the problem originally reported here.
Comment 31 Max Staudt 2017-03-13 14:34:38 UTC
Okay, the original problem was that xf86-video-mga no longer works when vesafb is in use. Correct?

It seems I missed something:
[    58.382] (EE) MGA(0): Unable to map Framebuffer F0000000 2000000.  Invalid argument (22)

It could be that it can no longer map the VRAM when it is already in use by vesafb. We see similar things with KMS drivers when a userspace process keeps a memory region open.

So maybe a kernel change has disallowed simultaneous mappings of that memory region...?

That could also explain why the mga module isn't loaded (not that it's needed anyway).
Comment 32 Max Staudt 2017-03-13 14:36:39 UTC
Can you please test the current Leap 42.1 and 42.2 KOTDs?

http://kernel.opensuse.org/branches/openSUSE-42.1
http://kernel.opensuse.org/branches/openSUSE-42.2
Comment 33 Felix Miata 2017-03-14 01:20:09 UTC
(In reply to Max Staudt from comment #32)
> Can you please test the current Leap 42.1 and 42.2 KOTDs? 

Did you mean to suggest I try a 4.11 kernel from head or kernel-default-4.10.2-1.1.gbfb2d22.i586.rpm 13-Mar-2017? This was filed against TW. If you can build a 42.1 4.1 or 42.2 4.4 for 32-bit I can try it in TW. :-p

> http://kernel.opensuse.org/branches/openSUSE-42.1
> http://kernel.opensuse.org/branches/openSUSE-42.2

ATM the Matrox is in its original host a-865. It's an AGP card, and host a-865 has a Prescott (90nm) Pentium 4 socket 478, which does not support any 64-bit CPUs that I have access to, if any such exist at all. I have no motherboard with AGP slot that support a CPU supported by Leap.

Most recently installed TW kernel on a-865 is 4.9.11.
Comment 34 Felix Miata 2017-03-14 06:16:19 UTC
I cloned a Mageia 5 partition from host gx28c onto host a-865 with the Matrox AGP 550. Its 4.4.50 kernel, 1.16.4 server and x11-driver-video-mga-1.6.4-1 work as expected with vga=791 on cmdline.
Comment 35 Max Staudt 2017-03-15 13:30:26 UTC
Thanks for the feedback!

Hmm, I expected to see a difference between 4.1 and 4.4 since you said that a 4.2 kernel worked, but 4.4 didn't.

You're right, there are no official 32 bit kernels for Leap anymore. However the 42.1 package was still able to build for 32 bits:

https://build.opensuse.org/package/show/home:mstaudt:1004453boo-kernel-421/kernel-default

Could you please extract the Mageia kernel config and attach it here? Maybe I'll find a difference there...
Comment 36 Felix Miata 2017-03-15 19:02:33 UTC
Created attachment 717615 [details]
/proc/config.gz from running Mageia 5 kernel 4.4.50-desktop-2.mga5

(Trusting my understanding that you didn't literally want extraction in the form of a plain text file.)
Comment 37 Max Staudt 2017-03-16 09:02:47 UTC
Perfect, thanks!
If you could also test the Leap 42.1 kernel I built for 32 bits, that would be helpful.
Comment 38 Max Staudt 2017-03-16 09:05:18 UTC
Better yet, if you still have access to the config of the working Tumbleweed kernel (the Linux 4.2.x one), that would be even more helpful than testing the Leap 42.1 kernel.
Comment 39 Felix Miata 2017-03-16 09:37:10 UTC
Created attachment 717679 [details]
tail of dmesg -w > somefile plus head of Xorg.0.log trying to run startx

I tried a repeat of comment 34 except using Mageia 6, kernel 4.9.15, Xorg 1.19.2, x11-driver-video-mga-1.6.5-1. Trying to use X with or without vga= on cmdline locks up the machine, black screen, no keyb response.

Which upstream bug tracker and product should I take this to, kernel, ???
Comment 40 Felix Miata 2017-03-16 10:08:44 UTC
Created attachment 717681 [details]
/proc/config.gz from TW 20170308 booted to pae kernel 4.2.3 on Matrox 550 host a-865

(In reply to Max Staudt from comment #37)
> If you could also test the Leap 42.1 kernel I built for 32 bits, that would
> be helpful.

I had no luck finding that kernel rpm. http://download.opensuse.org/update/leap/42.1/oss/i586/ is empty, as is .../i686, and http://download.opensuse.org/repositories/Kernel:/openSUSE-42.1/standard/ has no 586 or 686.

Booting TW's pae 4.2.3 with vga=791 on cmdline now with server 1.19.1 produces black screen and no keyboard response:
[   81.828203] Key type id_legacy registered
[  126.894523] mtrr: no MTRR for f4000000,2000000 found
[  130.060970] mtrr: no MTRR for f4000000,2000000 found
[  130.184648] [drm] Initialized drm 1.1.0 20060810
[  130.219705] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[  130.219713] [drm] No driver support for vblank timestamp query.
[  130.219721] [drm] Initialized mga 3.2.1 20051102 for 0000:01:00.0 on minor 0
Comment 41 Max Staudt 2017-03-16 15:58:55 UTC
Felix, thanks for the info, I'll process it sometime soon.

For the time being, here is the download repo for the 42.1 kernel:
  http://download.opensuse.org/repositories/home:/mstaudt:/1004453boo-kernel-421/standard/


You gan get there by clicking on "standard" in the builds list on the right sidebar of the project page, then "Go to download repository".
Comment 42 Felix Miata 2017-03-16 17:58:09 UTC
I can find only x86_64 rpm anywhere you've pointed. The Matrox is AGP. I have no machines with both 64 bit CPU and an AGP slot.
Comment 43 Max Staudt 2017-03-20 09:54:51 UTC
(In reply to Felix Miata from comment #39)
> Which upstream bug tracker and product should I take this to, kernel, ???

I think bugzilla.kernel.org is the way to go for this one, as exchanging the kernel seems to fix/break things and it's either a config change or something broke in the AGP support.

Please give me some more time to double check the config before reporting upstream. Also, please check the latest KOTD before any upstream report.

Finally, I'm rebuilding the 4.1 kernel in OBS, but if that fails it's not important as I now have two kernel configs to compare (thanks!).
Comment 44 Max Staudt 2017-03-22 11:28:27 UTC
Gaah, I've finally reproduced the problem.
I found a G550 PCIe card, which I put into a Sandy Bridge system.

Leap 42.1 and 42.2 work beautifully, whereas Tumbleweed doesn't.

I tried compiling Tumbleweed's xf86-video-mga on Leap and... it still works. Dang. I also installed Leap 42.2's KOTD on Tumbleweed - it's still broken on TW.

Also, it seems that xf86-video-mga is indeed making use of mga.ko. For some reason, the DDX fails to load it on TW, whereas it auto-loads it on the first X server start on Leap.

Manually modprobing mga allows X to come up with the mga DDX.

Felix, does 'modprobe mga' and then restarting X help?
Comment 45 Max Staudt 2017-03-22 11:32:37 UTC
Taking bug.
Comment 46 Felix Miata 2017-03-22 15:25:38 UTC
Not with 4.9.11:
# modprobe mga
modprobe: FATAL: Module mga not found in directory /lib/modules/4.9.11-1-default
# rpm -qa | grep mga
xf86-video-mga-1.6.5-1.1.i586
# uname -a
Linux a-865 4.9.11-1-default #1 SMP Sat Feb 18 17:59:27 UTC 2017 (cf9c670) i686 i686 i386 GNU/Linux

Upgrade to TW 20170320 & kernel-default 4.10.4 didn't help.
Comment 47 Max Staudt 2017-03-23 11:06:39 UTC
Turns out that the mga module is no longer included as of kernel v4.9-rc1, as it is now hidden behind the CONFIG_DRM_LEGACY option:

  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d92d9c3a14488e5af9d7015189f50e02346950f2

Apparently xf86-video-mga has two ways of accessing the memory, either through the DRI1 module, or by direct access via libpciaccess/sysfs. The latter should still work if the X server is run as root, and it does on kernel v4.4, but not on v4.9 (thus, the bug you reported). The failure backtrace is:

 error in  mmap
called by  pci_device_linux_sysfs_map_range_wc
called by  pci_device_linux_sysfs_map_range
called by  pci_device_map_range
called by  MGAMapMem
Comment 48 Felix Miata 2017-03-23 11:50:09 UTC
From the date of that commit I'd expect it to have made its first appearance in kernel 4.8. Why don't the 4.7.6-vanilla and 4.6.4-default kernels run with 4711 set on /usr/bin/Xorg?
Comment 49 Max Staudt 2017-03-23 11:55:29 UTC
This seems to stem from the new IO_STRICT_DEVMEM option introduced in kernel v4.5 - it disallows userspace /dev/mem access to regions used by the kernel. This explains why you can start X with xf86-video-mga when booting in VGA 80x25 text mode, but not when booting with vesafb.

Does booting with iomem=relaxed fix your X?

If yes, please add iomem=relaxed to your boot parameters when using a v4.5 kernel or newer. This is basically the other thing to do after setting the X server setuid root in order to make old user mode setting drivers (such as xf86-video-mga) work.

This change in the kernel has been introduced for security reasons, just like the DRI1 drivers are no longer included by default and the X server runs in user mode. Since there is nobody using the DRI1 driver for 3D, and thus no need to build the mga.ko kernel module, I think that setting this kernel option is the most comfortable workaround for you.
Comment 50 Felix Miata 2017-03-23 12:09:30 UTC
vga=791 and X both work as expected with iomem=relaxed on 4.10.4 kernel-default cmdline. :-)
Comment 51 Felix Miata 2017-03-23 12:21:28 UTC
Startx works, but KDM3 does not. From kdm.log:
xf86TokenToOptinfo: table is NULL
xf86TokenToOptinfo: table is NULL
error setting MTRR (base = 0xf4000000, size = 0x02000000, type = 1) Invalid argument (22)
error setting MTRR (base = 0xf4000000, size = 0x02000000, type = 1) Invalid argument (22)
modprobe: FATAL: Module mga not found in directory /lib/modules/4.10.4-1-default
error setting MTRR (base = 0xf4000000, size = 0x02000000, type = 1) Invalid argument (22)
(II) Server terminated successfully (0). Closing log file.
/usr/bin/Xorg: symbol lookup error: /usr/lib/libLLVMAMDGPUCodeGen.so.3.9: undefined symbol: _ZN4llvm19MachinePassRegistry6RemoveEPNS_23MachinePassRegistryNodeE
Comment 52 Max Staudt 2017-03-23 14:54:28 UTC
These errors look like what happens without "iomem=relaxed". No idea what KDM3 does differently, as starting the X server directly does work (as you confirmed). Maybe you rebooted without "iomem=relaxed" by mistake?

As far as I can see, Xorg is now working for you, so let's close the bug.

This was quite an interesting problem, thanks for filing and assisting with the bug!
Comment 53 Felix Miata 2017-03-23 15:33:37 UTC
I tried with neither iomem=relaxed nor vga=791 and KDM3 exited without displaying anything. Then I rebooted with both and KDM3 is now working. Maybe I did forget. They're both in the Grub stanzas now.

Thanks for taking and finding the solution!!!
Comment 54 Max Staudt 2017-03-23 17:00:50 UTC
(In reply to Max Staudt from comment #44)
> I also installed Leap 42.2's KOTD on Tumbleweed - it's still broken on TW.

Note to self: Installing Leap 42.2's v4.4 kernel on TW fixes the problem. No idea what happened back then.
Comment 55 Felix Miata 2021-04-03 05:06:05 UTC
(In reply to Max Staudt from comment #11)
> As a former Matrox user myself, I would be very glad to see these cards supported with KMS.

As noted in bug 1175754 , Debian current and next have found a way support at least one older (non-200) Matrox card's ability to use widescreen displays' modes using the mga X driver, regardless whether nomodeset is included on kernel cmdline or not.