http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c2 --- Comment #2 from Xavier Montell --- 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 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c4 --- Comment #4 from Xavier Montell --- Created attachment 843969 --> http://bugzilla.opensuse.org/attachment.cgi?id=843969&action=edit lspci.txt -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c8 Felix Miata (offline until ???) changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(xmontell@gmail.co | |m) | --- Comment #8 from Felix Miata (offline until ???) --- 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. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c10 --- Comment #10 from Felix Miata (offline until ???) --- 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. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c13 Felix Miata (offline until ???) changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fubar X with Radeon AGP on |Fubar X with Radeon AGP on |Pentium III Coppermine |Pentium III Coppermine & | |Katmai --- Comment #13 from Felix Miata (offline until ???) --- 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 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c15 --- Comment #15 from Felix Miata (offline until ???) --- Created attachment 844329 --> http://bugzilla.opensuse.org/attachment.cgi?id=844329&action=edit 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 -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c17 --- Comment #17 from Stefan Dirsch --- 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. -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c19 Felix Miata (offline until ???) changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fubar X with Radeon AGP on |Fubar X with Radeon AGP |Pentium III Coppermine & | |Katmai | Whiteboard| |regression --- Comment #19 from Felix Miata (offline until ???) --- (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). -- You are receiving this mail because: You are the assignee for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=1179387 http://bugzilla.opensuse.org/show_bug.cgi?id=1179387#c21 --- Comment #21 from Felix Miata (offline until ???) --- 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. -- You are receiving this mail because: You are the assignee for the bug.