Bug 1179387 - Fubar X with Radeon AGP
Fubar X with Radeon AGP
Status: RESOLVED WORKSFORME
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Kernel
Current
32bit Other
: P4 - Low : Major (vote)
: ---
Assigned To: openSUSE Kernel Bugs
E-mail List
regression
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-11-30 05:30 UTC by Felix Miata
Modified: 2022-02-18 09:30 UTC (History)
6 users (show)

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


Attachments
dmesg & journal tails beginning at each first radeon string; lscpu (35.82 KB, text/plain)
2020-11-30 05:30 UTC, Felix Miata
Details
dmesg.txt (55.38 KB, text/plain)
2020-11-30 09:04 UTC, Xavier Montell
Details
cpuinfo.txt (672 bytes, text/plain)
2020-11-30 09:05 UTC, Xavier Montell
Details
lspci.txt (11.69 KB, text/plain)
2020-11-30 09:06 UTC, Xavier Montell
Details
Xorg.0.log using options: nomodeset vga=792; 50-device.conf (16.18 KB, text/plain)
2020-12-09 17:34 UTC, Felix Miata
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Miata 2020-11-30 05:30:17 UTC
Created attachment 843962 [details]
dmesg & journal tails beginning at each first radeon string; lscpu

Initial Summary:
Fubar X with Radeon AGP on Pentium III Coppermine

forum thread:
https://forums.opensuse.org/showthread.php/547620-Tumbleweed-DVD-i586-Snapshot20201123-graphical-mode-fail?p=2986110#post2986110

Just guessing that this is a kernel driver bug rather than an X bug, hence the kernel component selected.

When the login manager tries to load, all that ultimately paints is the background graphic. WINDOWMANAGER=/usr/bin/icewm startx produces a black screen with mouse pointer. Xorg.0.log shows no apparent problem. No apparent difference whether using kernel 5.9.10 or 5.8.15. Vttys work as expected. Replacing the Radeon AGP rv250 ID: 1002:4c66 gfxcard with a Matrox G400 makes X work entirely as expected.

# inxi -Ca
CPU:       Info: Single Core model: Pentium III (Coppermine) socket: Slot-1 bits: 32 type: MCP arch: P6 III Coppermine 
           family: 6 model-id: 8 stepping: 1 microcode: D L1 cache: 16 KiB L2 cache: 256 KiB 
           flags: pae sse bogomips: 1403 
           Speed: 702 MHz min/max: N/A base/boost: 700/850 volts: 3.3 V ext-clock: 100 MHz Core speed (MHz): 1: 702 
           Vulnerabilities: Type: itlb_multihit status: KVM: VMX unsupported 
           Type: l1tf status: Vulnerable 
           Type: mds status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled 
           Type: meltdown status: Vulnerable 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization 
           Type: spectre_v2 mitigation: Full generic retpoline, STIBP: disabled, RSB filling 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
# inxi -GISMy
System:
  Host: s2846 Kernel: 5.8.15-1-default i686 bits: 32 Console: tty 3 
  Distro: openSUSE Tumbleweed 20201127 
Machine:
  Type: Desktop Mobo: Tyan model: Intel 440BX/GX v: Rev. 4 serial: 00000000 
  BIOS: American Megatrends v: 063101 date: 07/15/99 
Graphics:
  Device-1: AMD RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] driver: radeon v: kernel 
  Display: server: X.org 1.20.9 driver: ati,radeon 
  unloaded: fbdev,modesetting,vesa tty: 180x56 
  Message: Advanced graphics data unavailable in console for root. 
Info:...Shell: Bash inxi: 3.1.09
Comment 1 Xavier Montell 2020-11-30 09:04:06 UTC
Created attachment 843967 [details]
dmesg.txt
Comment 2 Xavier Montell 2020-11-30 09:04:33 UTC
Hi.
I started the thread "Forum-> English-> Get Technical Help Here-> Hardware-> TUMBLEWEED Tumbleweed-DVD-i586-Snapshot20201123 graphical mode fail".
I think the error occurs when loading the desktop environment, maybe they have been compiled with unsupported instructions.
Xfce and Gnome crash in the same way, KDE hasn't tried it yet.
Attached cpuinfo.txt, dmesg.txt, lspci.txt
Everything works fine until trying to load the desktop environment, Line 752 of dmesg.txt (time [78.497834])
Thanks
Comment 3 Xavier Montell 2020-11-30 09:05:17 UTC
Created attachment 843968 [details]
cpuinfo.txt
Comment 4 Xavier Montell 2020-11-30 09:06:14 UTC
Created attachment 843969 [details]
lspci.txt
Comment 5 Takashi Iwai 2020-11-30 17:35:01 UTC
What if you avoid radeon X11 driver?  Does it render better?
Comment 6 Felix Miata 2020-11-30 18:51:55 UTC
(In reply to Takashi Iwai from comment #5)
> What if you avoid radeon X11 driver?  Does it render better?

No observable difference after removing it
# zypper se -si video | grep xf86
i+ | xf86-video-fbdev | package | 0.5.0-1.10 | i586 | OSS
i  | xf86-video-mga   | package | 2.0.0-2.4  | i586 | OSS
i+ | xf86-video-vesa  | package | 2.5.0-1.1  | i586 | OSS
and only then starting Xorg.
Comment 7 Takashi Iwai 2020-12-07 12:55:13 UTC
I meant to choose the X11 driver explicitly.  At least, fbdev driver should work as is.
Comment 8 Felix Miata 2020-12-07 19:52:58 UTC
Without xf86-video-ati installed, Xorg.0.log reports using modeset(0), and nothing beyond background graphic when Xorg is started. 'Driver "vesa"' in xorg.con* results in "vesa: Ignoring device with a bound kernel driver", followed by lots of (EE) lines, including no screens found(EE) and fatal server error, when KMS is not disabled.

Booting with nomodeset, and vesa configured, #2 (EE) in log is "VESA(0): No V_BIOS found", so X fails to run. Removing the vesa config (100% automagic restored) allows the DM to open normally running FBDEV(0) @1024x768 on a 1680x1050 display.

ISTR modesetting DDX does not support Radeons as new as rv370 or so, so wouldn't for rv250 here either.
Comment 9 Stefan Dirsch 2020-12-07 22:16:42 UTC
I think Takashi suggested to try with "fbdev" X driver configured explicitely.
Comment 10 Felix Miata 2020-12-08 00:08:36 UTC
With fbdev explicitly configured, nothing else in xorg.con*, and nothing about video on kernel cmdline, both vttys and Xorg come up in 640x480 mode using less than 1/4 of the 1680x1050 native display.

With video=1680x1050 on cmdline and fbdev explicitly configured, Xorg runs in 1680x1050. Vttys appear that they do 1680x1050 also. Using 'Option "PreferredMode" "1680x1050"' without video=1680x1050 on cmdline also runs all video @640x480 in small upper left screen portion.
Comment 11 Stefan Dirsch 2020-12-08 16:14:16 UTC
Hmm. Is 

 vga=0x317

no longer set? I believe Takashi wanted to know whether the generic framebuffer is still working. So I suggest to try with

 vga=0x318 nomodeset

and then hardcode "fbdev" X driver.

Just using 

 video=1680x1050

will set the mode for KMS (kernel mode setting), *not* generic framebuffer --> "modeset" X driver.

Also.

  hwinfo --framebuffer

will tell you the right mode for native resolution. This is not standardized for resolutions > 1280x1024.
Comment 12 Takashi Iwai 2020-12-09 08:17:17 UTC
Yes, the fbdev should work with a higher resolution, but my intention of the previous questions was to confirm that the problem is in radeon DRM modesetting (on x86-32).

Now another question is whether its a kernel regression or not.  If it's a regression, which kernel did it work?  We'd need to narrow down the regression range.
Comment 13 Felix Miata 2020-12-09 10:08:19 UTC
I spent most of the day setting up to respond to comment #11. The PC used for comment #0 would not POST any more. In addition to the following troubleshooting itself, I spent a 4.5 hour trip to pick up some spares needed for troubleshooting these antiques from where I moved from 6 months ago. Apparently my 21-23 year old original motherboard and my exact match spare will go no farther than putting a cursor in upper left, no beeps, no POST. My sister still has one in storage I intend to test. They have Chemicon LXF caps, a series that had issues through most of the 1990s. If sis' won't POST either I plan to use some rainy day to recap one of these ancient workhorses.

I did find a mothballed Asus P2B motherboard with 440BX and Katmai Pentium III CPU. I put in (on the test bench actually) the two PATAs, NIC and Radeon rv250 from the deceased, and it worked, almost. Turns out the ancient BIOS hangs on an 80G disk, which is where I was booting TW from. So I had to image the portion of the disk with partitions, then write the image back to a <60G disk. That enable testing to proceed.

(In reply to Stefan Dirsch from comment #11)
> Hmm. Is 
 
>  vga=0x317
 
> no longer set?

I had taken it out to see what would happen without either vga= or video=.

>I believe Takashi wanted to know whether the generic
> framebuffer is still working. So I suggest to try with
 
>  vga=0x318 nomodeset
 
> and then hardcode "fbdev" X driver.

# cat /etc/X11/xorg.conf.d/50-device.conf
Section "Device"
    Identifier  "Default Device"
        Driver  "fbdev"
EndSection
# cat /proc/cmdline
root=yada... audit=0 noresume consoleblank=0 mitigations=auto vga=792 5
# inxi -CGISay
System:
  Host: s2846 Kernel: 5.8.15-1-default i686 bits: 32 compiler: gcc v: 10.2.1
  parameters: root=yada... audit=0 noresume consoleblank=0 mitigations=auto vga=792 5
  Desktop: Trinity R14.0.9 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM
  Distro: openSUSE Tumbleweed 20201127
CPU:
  Info: Single Core model: Pentium III (Katmai) socket: SLOT 1 bits: 32
  type: MCP arch: P6 III Katmai family: 6 model-id: 7 stepping: 3 microcode: A
  L1 cache: 32 KiB L2 cache: 512 KiB
  flags: pae sse bogomips: 1202
  Speed: 601 MHz min/max: N/A base/boost: 600/500 volts: 2.9 V
  ext-clock: 100 MHz Core speed (MHz): 1: 601
  Vulnerabilities: Type: itlb_multihit status: KVM: VMX unsupported
  Type: l1tf status: Vulnerable
  Type: mds
  status: Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled
  Type: meltdown status: Vulnerable
  Type: spec_store_bypass status: Vulnerable
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
  mitigation: Full generic retpoline, STIBP: disabled, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] driver: radeon
  v: kernel bus ID: 01:00.0 chip ID: 1002:4c66
  Display: x11 server: X.Org 1.20.9 driver: fbdev display ID: :0 screens: 1
  Screen-1: 0 s-res: 1680x1050 s-dpi: 96 s-size: 445x278mm (17.5x10.9")
  s-diag: 525mm (20.7")
  Monitor-1: default res: 1680x1050
  OpenGL: renderer: llvmpipe (LLVM 11.0.0 128 bits) v: 4.5 Mesa 20.2.3
  compat-v: 3.1 direct render: Yes
Info:...Shell: Bash v: 5.0.18 running in: konsole inxi: 3.1.09

NAICT with no fbset to use, the vttys are also running in 1680x1050.
 
> Just using 
 
>  video=1680x1050
 
> will set the mode for KMS (kernel mode setting), *not* generic framebuffer
> --> "modeset" X driver.

IME, video= always works for both Xorg and the vttys when xf86-video-intel is the functioning DDX, and IIRC, with at least one other DDX (not modeset(0)). 

> Also.

>   hwinfo --framebuffer
 
> will tell you the right mode for native resolution. This is not standardized
> for resolutions > 1280x1024.

Not IME:
# cat /proc/cmdline
root=yada... audit=0 noresume consoleblank=0 mitigations=auto vga=792 5
# hwinfo --framebuffer
02: None 00.0: 11001 VESA Framebuffer
  [Created at bios.459]
  Unique ID: rdCR.1RILOGJ1TcB
  Hardware Class: framebuffer
  Model: "ATI V250"
  Vendor: "ATI Technologies Inc."
  Device: "V250"
  SubVendor: "ATI RADEON RV250"
  SubDevice:
  Revision: "01.00"
  Memory Size: 24 MB
  Memory Range: 0x00000000-0x017fffff (rw)
  Config Status: cfg=new, avail=yes, need=no, active=unknown

(In reply to Takashi Iwai from comment #12)
> Yes, the fbdev should work with a higher resolution, but my intention of the
> previous questions was to confirm that the problem is in radeon DRM
> modesetting (on x86-32).
 
> Now another question is whether its a kernel regression or not.  If it's a
> regression, which kernel did it work?  We'd need to narrow down the
> regression range.

I can probably rough this out if it is:
# ls -gG /boot/vmlinuz*t
-rw-r--r-- 1 8912448 Oct 20 13:18 /boot/vmlinuz-5.8.15-1-default
-rw-r--r-- 1 8989632 Nov 10 21:35 /boot/vmlinuz-5.9.1-2-default
-rw-r--r-- 1 9002368 Nov 25 14:58 /boot/vmlinuz-5.9.10-1-default
# ls -gG /boot/vmlinuz*e>>out
ls: cannot access '/boot/vmlinuz*e': No such file or directory
# ls -Gg *nel-def*i586*m
-rw-rw-r-- 1 64969681 May  3  2017 kernel-default-4.10.13-1.2.i586.rpm
-rw-rw-r-- 1 65770091 Aug 13  2017 kernel-default-4.11.8-2.4.i586.rpm
-rw-rw-r-- 1 66632511 Aug 30  2017 kernel-default-4.12.9-1.2.i586.rpm
-rw-rw-r-- 1 62262620 Nov 12  2017 kernel-default-4.13.12-1.1.i586.rpm
-rw-rw-r-- 1 63884486 Jan 31  2018 kernel-default-4.14.15-2.3.i586.rpm
-rw-rw-r-- 1 64937625 Apr  4  2018 kernel-default-4.15.13-2.4.i586.rpm
-rw-rw-r-- 1 66163989 Jun 13  2018 kernel-default-4.16.12-3.5.i586.rpm
-rw-rw-r-- 1 66780856 Aug 13  2018 kernel-default-4.17.14-1.2.i586.rpm
-rw-rw-r-- 1 65753138 Oct 24  2018 kernel-default-4.18.15-1.2.i586.rpm
-rw-rw-r-- 1 66394595 Dec 28  2018 kernel-default-4.19.12-1.4.i586.rpm
-rw-rw-r-- 1 66509281 Mar  4  2019 kernel-default-4.20.13-1.2.i586.rpm
-rw-rw-r-- 1 66289238 May 10  2019 kernel-default-5.0.13-1.1.i586.rpm
-rw-rw-r-- 1 67432660 Jul 16  2019 kernel-default-5.1.16-1.4.i586.rpm
-rw-rw-r-- 1 69543814 Sep 21  2019 kernel-default-5.2.14-1.2.i586.rpm
-rw-rw-r-- 1 70420345 Dec 19  2019 kernel-default-5.3.12-2.2.i586.rpm
-rw-rw-r-- 1 69223987 Feb  2  2020 kernel-default-5.4.14-2.1.i586.rpm
-rw-rw-r-- 1 70216327 Mar 29  2020 kernel-default-5.5.13-1.2.i586.rpm
-rw-rw-r-- 1 71691615 Jun  8  2020 kernel-default-5.6.14-1.6.i586.rpm
-rw-rw-r-- 1 72431687 Aug  3 10:44 kernel-default-5.7.11-1.2.i586.rpm
-rw-rw-r-- 1 72638282 Aug  7 05:23 kernel-default-5.7.12-1.1.g9c98feb.i586.rpm
-rw-rw-r-- 1 75437823 Oct 20 14:05 kernel-default-5.8.15-1.2.i586.rpm
Comment 14 Stefan Dirsch 2020-12-09 11:17:03 UTC
Ok. I have no idea, why there is no single framebuffer mode available. There should be with kernel boot options

   nomodeset vga=792

BTW, this GPU is from 2002! And it's an AGP card! I would guess the Matrox G400, which appears to work,  is a PCI card.

What about combining your machine with a CRT monitor from 2002 and be happy with 1024x768 in framebuffer mode. ;-)
Comment 15 Felix Miata 2020-12-09 17:34:05 UTC
Created attachment 844329 [details]
Xorg.0.log using options: nomodeset vga=792; 50-device.conf

(In reply to Stefan Dirsch from comment #14)
> Ok. I have no idea, why there is no single framebuffer mode available. There
> should be with kernel boot options

>    nomodeset vga=792

X doesn't like this in combination with 'Driver "fbdev".
 
> BTW, this GPU is from 2002! And it's an AGP card! I would guess the Matrox
> G400, which appears to work,  is a PCI card.

All my G400s are AGP. I have a G200 somewhere that is PCI. Whether it still works or not I don't know, not used in many moons.

> What about combining your machine with a CRT monitor from 2002 and be happy
> with 1024x768 in framebuffer mode. ;-)

I didn't bring any when I moved, and don't think I left any behind either, except for a green 12" monochrome hiding deep in a closet. Even when I was last using CRTs I was typically using 1400x1050 or 1600x1200. :) Anyway, I filed this because of Xavier and other poor people who have to use whatever they can get. I'd never get anything done with one 700MHz core and 1024x768. :p

Hmmm. This rv250 back home in the 64bit Sempron host k8mmv I have configured to use radeon.agpmode=-1 with TW. Maybe that's something for Xavier worth a try. Without it, and without fbdev forced via 50-device.conf:

[   164.095] Current Operating System: Linux k8mmv 5.8.14-1-default ...  x86_64
[   164.095] Kernel command line:...mitigations=auto consoleblank=0 vga=792 nomodeset
[   164.697] (II) Unloading vesa
[   164.698] (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
[   164.698] (EE) FBDEV(0): mode initialization failed
[   164.698] (EE)
Fatal server error:
[   164.698] (EE) AddScreen/ScreenInit failed for driver 0...

# cat /etc/X11/xorg.conf /etc/X11/xorg.conf/50-device.conf
cat: /etc/X11/xorg.conf: No such file or directory
cat: /etc/X11/xorg.conf/50-device.conf: No such file or directory
# inxi -CGISay
System:
  Host: k8mmv Kernel: 5.8.14-1-default x86_64 bits: 64 compiler: gcc v: 10.2.1
  parameters:...mitigations=auto consoleblank=0 vga=792 radeon.agpmode=-1
  Desktop: Trinity R14.0.8 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: startx
  Distro: openSUSE Tumbleweed 20201014
CPU:
  Info: Single Core model: AMD Sempron 3000+ bits: 64 type: UP arch: K8 rev.E
  family: F (15) model-id: 2C (44) stepping: 2 microcode: N/A L2 cache: 128 KiB
  flags: lm nx pae sse sse2 sse3 bogomips: 3599
  Speed: 1800 MHz min/max: N/A Core speed (MHz): 1: 1800
  Vulnerabilities: Type: itlb_multihit status: Not affected
  Type: l1tf status: Not affected
  Type: mds status: Not affected
  Type: meltdown status: Not affected
  Type: spec_store_bypass status: Not affected
  Type: spectre_v1
  mitigation: usercopy/swapgs barriers and __user pointer sanitization
  Type: spectre_v2
  mitigation: Full AMD retpoline, STIBP: disabled, RSB filling
  Type: srbds status: Not affected
  Type: tsx_async_abort status: Not affected
Graphics:
  Device-1: AMD RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] driver: radeon
  v: kernel bus ID: 01:00.0 chip ID: 1002:4c66
  Display: x11 server: X.Org 1.20.9 driver: ati,radeon
  unloaded: fbdev,modesetting,vesa display ID: :0 screens: 1
  Screen-1: 0 s-res: 1920x1200 s-dpi: 108 s-size: 451x282mm (17.8x11.1")
  s-diag: 532mm (20.9")
  Monitor-1: DVI-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  OpenGL: renderer: Mesa DRI R200 (RV250 4C66) DRI2 v: 1.3 Mesa 20.1.8
  direct render: Yes
Info:...Shell: Bash v: 5.0.18 running in: konsole inxi: 3.1.09

vttys appear to be in 1920x1200 too. Same goes for forcing FBDEV,  though with a noisy log:

# egrep -i 'ent Ope|fbdev|nel com|\(EE\)|time:' /var/log/Xorg.0.log
[    98.212] Current Operating System: Linux k8mmv 5.8.14-1-default ... x86_64
[    98.212] Kernel command line:...mitigations=auto consoleblank=0 vga=792 radeon.agpmode=-1
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    98.217] (==) Log file: "/var/log/Xorg.0.log", Time: Wed Dec  9 10:56:05 2020
[    98.633] (II) LoadModule: "fbdev"
[    98.633] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[    98.644] (II) Module fbdev: vendor="X.Org Foundation"
[    98.644] (II) FBDEV: driver for framebuffer: fbdev
[    98.644] (II) Loading sub module "fbdevhw"
[    98.644] (II) LoadModule: "fbdevhw"
[    98.645] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[    98.657] (II) Module fbdevhw: vendor="X.Org Foundation"
[    98.657] (**) FBDEV(0): claimed PCI slot 1@0:0:0
[    98.657] (II) FBDEV(0): using default device
[    98.657] (II) FBDEV(0): Creating default Display subsection in Screen section
[    98.658] (==) FBDEV(0): Depth 24, (==) framebuffer bpp 32
[    98.658] (==) FBDEV(0): RGB weight 888
[    98.658] (==) FBDEV(0): Default visual is TrueColor
[    98.658] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
[    98.658] (II) FBDEV(0): hardware: radeondrmfb (video memory: 9000kB)
[    98.658] (II) FBDEV(0): checking modes against framebuffer device...
[    98.658] (II) FBDEV(0): checking modes against monitor...
[    98.658] (II) FBDEV(0): Virtual size is 1920x1200 (pitch 1920)
[    98.658] (**) FBDEV(0):  Built-in mode "current"
[    98.658] (==) FBDEV(0): DPI set to (96, 96)
[    98.664] (**) FBDEV(0): using shadow framebuffer
[    98.673] (==) FBDEV(0): Backing store enabled
[    98.674] (EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy
		#...256 identical of these FBIOPUTCMAPs total..., without apparent impact in X session
[    98.677] (EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy
[    98.677] (==) FBDEV(0): DPMS enabled

I couldn't stop, put the rv250 back into the blankety blank Katmai (bad PS/2 port, flaky RAM slot). With KMS enabled, both FBDEV and Radeon drivers produce expected results. e.g.

# inxi -GSay
System:
  Host: s2846 Kernel: 5.8.15-1-default i686 bits: 32 compiler: gcc v: 10.2.1
  parameters:...consoleblank=0 mitigations=none vga=792 radeon.agpmode=-1
  Desktop: Trinity R14.0.9 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: startx
  Distro: openSUSE Tumbleweed 20201127
Graphics:
  Device-1: AMD RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] driver: radeon
  v: kernel bus ID: 01:00.0 chip ID: 1002:4c66
  Display: x11 server: X.Org 1.20.9 driver: ati,radeon
  unloaded: fbdev,modesetting,vesa display ID: :0 screens: 1
  Screen-1: 0 s-res: 1680x1050 s-dpi: 96 s-size: 444x277mm (17.5x10.9")
  s-diag: 523mm (20.6")
  Monitor-1: VGA-0 res: 1680x1050 hz: 60 dpi: 90 size: 474x296mm (18.7x11.7")
  diag: 559mm (22")
  OpenGL: renderer: Mesa DRI R200 (RV250 4C66) x86/MMX/SSE DRI2
  v: 1.3 Mesa 20.2.3 direct render: Yes

:D
Comment 16 Stefan Dirsch 2020-12-09 22:46:44 UTC
Ok. Apparently with your gfx card, you have no framebuffer device at all. No idea why. Maybe it's time to get rid of this gfx card. Seriously.

[   164.682] (EE) Unable to find a valid framebuffer device
[...]
[   164.683] (DB) xf86MergeOutputClassOptions unsupported bus type 0
[...]
[   164.698] (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
[   164.698] (EE) FBDEV(0): mode initialization failed

And apparently framebuffer on your Matrox AGP cards work. There is no KMS driver for Matrox G400, and mga X driver no longer work with
current kernel.
Comment 17 Stefan Dirsch 2020-12-09 23:24:05 UTC
Sorry. But this is too much for me in one bugreport. Different results from at least 3 different machines. Too much confusion for me. I suggest that Xavier opens a new bug for his issue. Also I think he has a newer Radeon gfx card than yours on hopefully a newer machine than your 32bit one.
Comment 18 Stefan Dirsch 2020-12-09 23:29:49 UTC
(In reply to Stefan Dirsch from comment #17)
> Sorry. But this is too much for me in one bugreport. Different results from
> at least 3 different machines. Too much confusion for me. I suggest that
> Xavier opens a new bug for his issue. Also I think he has a newer Radeon gfx
> card than yours on hopefully a newer machine than your 32bit one.

Ok. It's not any better. Also 32bit machine, Radeon 9800 from 2003.
Comment 19 Felix Miata 2020-12-10 03:24:18 UTC
(In reply to Stefan Dirsch from comment #16)
> Ok. Apparently with your gfx card, you have no framebuffer device at all. No
> idea why. Maybe it's time to get rid of this gfx card. Seriously.

Sorry to have mentioned Matrox. This bug is about old Radeons unsupported by modeset(0).
 
> [   164.682] (EE) Unable to find a valid framebuffer device
> [...]
> [   164.683] (DB) xf86MergeOutputClassOptions unsupported bus type 0
> [...]
> [   164.698] (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode
> [   164.698] (EE) FBDEV(0): mode initialization failed

That's all about the very same rv250 Radeon 9000 AGP running instead on an ancient 64 bit machine (the one I borrowed it from for testing 32bit), without employing radeon.agpmode=-1. With it, all trouble ceases, contrary to 15.2's 5.3 kernel, where all works as expected without it:

# inxi -CGISay
System:
  Host: k8mmv Kernel: 5.3.18-lp152.57-default x86_64 bits: 64
  parameters:...mitigations=auto consoleblank=0
  Desktop: Trinity R14.0.9 tk: Qt 3.5.0 info: kicker wm: Twin 3.0 dm: TDM
  Distro: openSUSE Leap 15.2
CPU:
  Info: Single Core model: AMD Sempron 3000+ socket: 754 (940) note: check...
Graphics:
  Device-1: AMD RV250/M9 GL [Mobility FireGL 9000/Radeon 9000] driver: radeon
  v: kernel bus ID: 01:00.0 chip ID: 1002:4c66
  Display: server: X.Org 1.20.3 driver: ati,radeon
  unloaded: fbdev,modesetting,vesa display ID: :0 screens: 1
  Screen-1: 0 s-res: 3600x1200 s-dpi: 108 s-size: 846x282mm (33.3x11.1")
  s-diag: 892mm (35.1")
  Monitor-1: VGA-0 res: 1680x1050 hz: 60 dpi: 90 size: 474x296mm (18.7x11.7")
  diag: 559mm (22")
  Monitor-2: DVI-0 res: 1920x1200 hz: 60 dpi: 94 size: 519x324mm (20.4x12.8")
  diag: 612mm (24.1")
  OpenGL: renderer: Mesa DRI R200 (RV250 4C66) DRI2 v: 1.3 Mesa 19.3.4
  direct render: Yes
Info:...Shell: Bash v: 4.4.23 running in: konsole inxi: 3.1.09

On same PC, Debian 11 Buster's 5.9.x works as expected without need of radeon.agpmode=-1, vga= or video= to produce 1920x1200 on DVI using Radeon and FBDEV DDXes (along with (EE) FBDEV(0): FBIOPUTCMAP: Device or resource busy).
Comment 20 Felix Miata 2020-12-10 08:00:04 UTC
(In reply to Takashi Iwai from comment #12)
> Now another question is whether its a kernel regression or not.  If it's a
> regression, which kernel did it work?  We'd need to narrow down the
> regression range.

Attempting on host k8mmv, rv250 Radeon on 64 bit TW to not use radeon.agpmode=-1, vga= or video=, 
5.3.12 and up reproduced comment #0, and triggered need for hard reset. 5.2.14 produced conflicts libc.so.6() and split firmwares trying to install.

Upgrading TW20121014 to TW20121207 on host k8mmv using rv250 Radeon fixed this for kernel 5.8.15 and 5.9.12. 5.7.11 and older still require radeon.agpmode=-1.

The 32bit Katmai running the rv250 Radeon is currently TW20201127. I am no longer able to reproduce comment #0 need for radeon.agpmode=-1 to utilize xf86-video-ati with installed kernels 5.8.15 and 5.9.10. What may have changed with this installation, other than not being Coppermine, escapes me. It's the same Gfxcard and PATA HDD installation used for comment #0. Wild guess slim possibility: today I discovered it has a flaky PS/2 port that I was using for keyboard. It reached the point where keyboard simply would disappear once past Grub on 5+ boots in a row. I switched to USB KB, and KB trouble was gone.

So, WFM. I wonder about Xavier?
Comment 21 Felix Miata 2020-12-16 09:44:38 UTC
I just finished resurrecting the comment #0 host and upgrading TW to 20201214, except now with an even older Radeon 7500 rv200. On it comment #0 is not currently reproducible with 5.7.11, 5.8.15 or 5.9.14 kernels. I've now shelved most of my G400s for lack of KMS support.
Comment 23 Miroslav Beneš 2022-02-18 09:30:37 UTC
We can close this one, I guess. It worked out for Felix in the end and Xavier was supposed to open a new bug (don't know if it happened). Please reopen if there is something I missed.