[Bug 1179387] Fubar X with Radeon AGP on Pentium III Coppermine & Katmai

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.