r600/RV610: Heavy disturbed screen output after !20451 landed
Summary
It looks that we have a new problem on some RV610 aka Radeon HD 2400 XT based systems. I can confirm this for my iMac8,1 based computer and Kubuntu 22.04 LTS. After !20451 (merged), I had the following screen output:
Tested version was presumably Mesa 23.0.0-devel (git-980df9ed 2023-01-03 jammy-oibaf-ppa).
cc @gerddie, because this looks like a serious regression. PS Happy new year!
System information
test@iMac-test:~$ inxi -GSC -xx
System:
Host: iMac-test Kernel: 5.15.0-56-generic x86_64 bits: 64 compiler: gcc
v: 11.3.0 Desktop: KDE Plasma 5.24.7 tk: Qt 5.15.3 wm: kwin_x11 dm: SDDM
Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
CPU:
Info: dual core model: Intel Core2 Duo E8135 bits: 64 type: MCP
arch: Core Yorkfield rev: 6 cache: L1: 128 KiB L2: 6 MiB
Speed (MHz): avg: 798 min/max: 800/2400 cores: 1: 798 2: 798
bogomips: 9575
Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3 vmx
Graphics:
Device-1: AMD RV610/M74 [Mobility Radeon HD 2400 XT] vendor: Apple
driver: radeon v: kernel pcie: speed: 2.5 GT/s lanes: 16 ports:
active: LVDS-1 empty: DIN-1,DVI-I-1 bus-ID: 01:00.0 chip-ID: 1002:94c8
Device-2: Apple Built-in iSight type: USB driver: uvcvideo bus-ID: 2-4:4
chip-ID: 05ac:8502
Display: x11 server: X.Org v: 1.21.1.3 compositor: kwin_x11 driver: X:
loaded: ati,radeon unloaded: fbdev,modesetting,vesa gpu: radeon
display-ID: :0 screens: 1
Screen-1: 0 s-res: 1680x1050 s-dpi: 96
Monitor-1: LVDS res: 1680x1050 dpi: 99 diag: 510mm (20.1")
OpenGL: renderer: AMD RV610 (DRM 2.50.0 / 5.15.0-56-generic LLVM 15.0.5)
v: 3.3 Mesa 23.0.0-devel (git-980df9e 2023-01-03 jammy-oibaf-ppa)
compat-v: 3.0 direct render: Yes
Regression
It worked before the corresponding MR !20451 (merged) landed.
Log files as attachment
I was not able to get any log because the system was no longer accessible and I was myself in some state of "panic mode".
In the end I was able to boot to a console with boot paramter quiet splash 3 xforcevesa vga=791
. And after login with username and password it was then finally possible to uninstall the oibaf PPA with sudo ppa-purge ppa:oibaf/graphics-drivers
.
Note for noobs, this cannot be done at the "emergency console"! An internet connection is absolutely necessary for ppa-purge
to restore the original Ubuntu Mesa stock files. Unfortunately ppa-purge
is trying to purge the PPA also in offline mode which leads to an even bigger mess in the way that some stuff is removed while the original stock Mesa is not restored. So don't try this when no Internet connection is present at OS level!
Any extra information would be greatly appreciated
Maybe it should be added that the iMac8,1 is a somehow special Apple-EFI based system because it has some strange "quirks" which normal PC based RV610 systems don't have. For example, the screen is always disturbed (but in a different way) after a wake-up from stand-by. See #2444 for more information. Only solution is to disable any stand-by mode and only allow to power-off the LCD.
The underlying cause may be also here the special Apple EFI vBios which seems to be not fully correctly adopted by the radeon kernel driver:
[ 2.668534] radeon 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xd52a
And in the end, eventually also issue #7965 may have some relation to this vBios stuff.
Note for devs, on those early and non-UEFI conformant systems it would probably make sense to use an alternative approach to extract the vBios information. I mean here the "ioremap(), not phys_to_virt() for platform ROM" way instead of the conventional one. This allowed me to install a 32bit MX-21 Linux "Wildflower" in native EFI-mode at an iMac5,1 computer which never worked before. This is also the only possible way to install Linux natively on several later Apple products with nVidia based GPUs, see bug 211. It could be said that this special Apple EFI vBios behavior is present from 2006 until 2011. After that, the whole vBios matter was more UEFI compliant also on Apple systems. However, that would be a job for the radeon kernel folks.