How to tell if a driver is gallium or just mesa? (Slow renderng with radeon)

[prenex]

So I have changed back the TTL to 48 and changed:

#ifdef CONFIG_PCI_LOCKLESS_CONFIG .... #endif

into

#ifndef CONFIG_PCI_LOCKLESS_CONFIG .... #endif

If this works I should have just set this kernel config value to unset instead of hacking the source to a bad state...

[prenex]

Sadly CONFIG_PCI_LOCKLESS_CONFIG=n did not help.... :-(

Also not much difference between the earlier and current dmesg (basically nothing). But while vimdiffing them I have found pci-related possible issues printed right after we return from the relevant function and log our things!

 PCI: Searching for agp capability for device: f55b7800
 PCI: __pci_bus_find_cap_start success (agp capability for device: f55b7800)
 PCI: __pci_find_next_cap_ttl pos < 0x40 at TTL value still at: 46
 PCI: __pci_find_next_cap_ttl error at TTL value still at: 46
[B] pci_bus 0000:03: extended config space not accessible
 pci_bus 0000:03: busn_res: [bus 03] end can not be updated to 06
 pci 0000:00:14.4: bridge has subordinate 03 but max busn 06[/B]

Similar things are always written out after my log message. I have no idea how big of a problem these are but they seem to be present in many earlier dmesg logs too - just I was not paying attention to them before. Because the AGP acceleration capability check/getter actually reads from the config of the pci card in question I think these might indicate some underlying problem. I have no idea what is the two numbers for the pci_bus xxxx:yy but I see not only one, but several messages like this.

This is really suspicious. It looks like as if some parts of the pci cards are not accessible for some reason and maybe earlier they were.

This seems to be a similar change in the code that might have affected me:

https://lkml.org/lkml/2018/5/4/556

Also an other part of the dmesg logs I missed is this:

 [drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1392 0x00).
 [drm] Generation 2 PCI interface, using max accessible memory
 radeon 0000:01:05.0: VRAM: 128M 0x0000000058000000 - 0x000000005FFFFFFF (128M used)
 radeon 0000:01:05.0: GTT: 512M 0x0000000060000000 - 0x000000007FFFFFFF
 [drm] Detected VRAM RAM=128M, BAR=256M
 [drm] RAM width 128bits DDR
 [TTM] Zone  kernel: Available graphics memory: 438724 kiB
 [TTM] Zone highmem: Available graphics memory: 706920 kiB
 [TTM] Initializing pool allocator
 [TTM] Initializing DMA pool allocator
 [drm] radeon: 128M of VRAM memory ready
 [drm] radeon: 512M of GTT memory ready.
 [drm] GART: num cpu pages 131072, num gpu pages 131072
 [drm] radeon: power management initialized
 [drm] radeon: 3 quad pipes, 1 z pipes initialized.
 [drm] PCIE GART of 512M enabled (table at 0x0000000033500000).
 radeon 0000:01:05.0: WB enabled
 radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x0000000060000000 and cpu addr 0xd1ca941a
 [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
 [drm] Driver supports precise vblank timestamp query.
 radeon 0000:01:05.0: radeon: MSI limited to 32-bit
 [drm] radeon: irq initialized.
 [drm] Loading R300 Microcode

It says there is 512M of PCIe GART.

I have no idea what is this supposed to be, but I used to only have 128M video memory total before. At least I remember sometimes I went out of memory when games like Mount&Blade: warband used bigger textures so I could not use the big ones. I think it would not be a problem if I would have 512M or 512+128M so I highly suspect earlier I had only 128 and I am not sure what gart is. But I am sure that settings for the AGP fast write and the value of 8x had an effect before.

[prenex]

Actually this one seems to be more related:

 pci 0000:00:00.0: [1002:5a31] type 00 class 0x060000
[B] pci 0000:00:00.0: [Firmware Bug]: reg 0x1c: invalid BAR (can't size)[/B]
 pci 0000:00:01.0: [1002:5a3f] type 01 class 0x060400
 pci 0000:00:13.0: [1002:4374] type 00 class 0x0c0310
 pci 0000:00:13.0: reg 0x10: [mem 0xfebff000-0xfebfffff]
 pci 0000:00:13.1: [1002:4375] type 00 class 0x0c0310
 pci 0000:00:13.1: reg 0x10: [mem 0xfebfe000-0xfebfefff]
 pci 0000:00:13.2: [1002:4373] type 00 class 0x0c0320
 pci 0000:00:13.2: reg 0x10: [mem 0xfebfd000-0xfebfdfff]
 pci 0000:00:13.2: supports D1 D2
 pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
 pci 0000:00:14.0: [1002:4372] type 00 class 0x0c0500
 pci 0000:00:14.0: reg 0x10: [io  0x0b00-0x0b0f]
 pci 0000:00:14.0: reg 0x14: [mem 0xfed00000-0xfed003ff]
 pci 0000:00:14.1: [1002:4376] type 00 class 0x01018a
 pci 0000:00:14.1: reg 0x10: [io  0x01f0-0x01f7]
 pci 0000:00:14.1: reg 0x14: [io  0x03f4-0x03f7]
 pci 0000:00:14.1: reg 0x18: [io  0x0170-0x0177]
 pci 0000:00:14.1: reg 0x1c: [io  0x0374-0x0377]
 pci 0000:00:14.1: reg 0x20: [io  0xff00-0xff0f]
 pci 0000:00:14.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
 pci 0000:00:14.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
 pci 0000:00:14.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
 pci 0000:00:14.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
 pci 0000:00:14.2: [1002:437b] type 00 class 0x040300
 pci 0000:00:14.2: reg 0x10: [mem 0xfebf8000-0xfebfbfff 64bit]
 pci 0000:00:14.2: PME# supported from D0 D3hot D3cold
 pci 0000:00:14.3: [1002:4377] type 00 class 0x060100
 pci 0000:00:14.4: [1002:4371] type 01 class 0x060401
 PCI: Searching for agp capability for device: f540b800
 PCI: __pci_bus_find_cap_start success (agp capability for device: f540b800)
 PCI: __pci_find_next_cap_ttl pos < 0x40 at TTL value still at: 46
 PCI: __pci_find_next_cap_ttl error at TTL value still at: 46

According to lspci the pci device that has that "firmware bug" is the RC410 Host bridge...

[prenex@prenex-laptop ~]$ lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RC410 Host Bridge (rev 01)
00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx PCI Bridge [int gfx]
00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 USB Host Controller (rev 80)
00:13.1 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 USB Host Controller (rev 80)
00:13.2 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 USB2 Host Controller (rev 80)
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 SMBus Controller (rev 82)
00:14.1 IDE interface: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 IDE Controller (rev 80)
00:14.2 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 High Definition Audio Controller (rev 01)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 PCI-ISA Bridge (rev 80)
00:14.4 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 PCI-PCI Bridge (rev 80)
01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M]
...

The other messages seem to refer to the other pci devices...

[prenex]

The lspci -v shows weird things too:

[prenex@prenex-laptop ~]$ lspci -v
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD/ATI] RC410 Host Bridge (rev 01)
        Subsystem: ASUSTeK Computer Inc. RC410 Host Bridge
        Flags: bus master, 66MHz, medium devsel, latency 64
        [B]Memory at <ignored> (64-bit, non-prefetchable)[/B]

00:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD/ATI] RC4xx/RS4xx PCI Bridge [int gfx] (prog-if 00 [Normal decode])
        Flags: bus master, 66MHz, medium devsel, latency 64
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        I/O behind bridge: 00009000-00009fff [size=4K]
        Memory behind bridge: fe100000-fe1fffff [size=1M]
        Prefetchable memory behind bridge: bdf00000-ddefffff [size=512M]
        Capabilities: <access denied>

00:13.0 USB controller: Advanced Micro Devices, Inc. [AMD/ATI] IXP SB4x0 USB Host Controller (rev 80) (prog-if 10 [OHCI])
        Subsystem: ASUSTeK Computer Inc. IXP SB4x0 USB Host Controller
        Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19
        Memory at febff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: <access denied>
        Kernel driver in use: ohci-pci
        Kernel modules: ohci_pci
...

[prenex]

I've also tried to run with the kernel parameter: "pci=use_crs" becaue dmesg had this entry:

PCI: Ignoring host bridge windows from ACPI; if necessary, use "pci=use_crs" and report a bug

Did not help...

[prenex]

Okay... I have decided to prepare an ubuntu 16.04 live USB... I was thinking about a Debian too just to maybe try a lot of kernels, but first I want to make the exact same system as before if that is possible just to compare every log as much as I can...

I can only hope that it has an up and running radeon driver and mesa, but I think the kernel modules for radeon will be loaded nevertheless and log messages will be shown for PCI log nevertheless too and maybe lspci -v I can also compare to the new system.

I am not intending to reinstall an older OS. This is only for comparison purposes. Also I am not intending to install the OS, just run the iso from the cd/dvd image. I really hope this helps somewhat...

[prenex]

It was a bad idea on multiple levels to set up that 16.04.6 live usb...

First and foremost it does not even start up by itself without me fighting with it as I just got a flickering screen nothing else so I could only access the terminal because they tried to run compiz for some reason. From the terminal I stole out all the relevant log files. Also for some reason the kernel for this live USB is much later than I even had while still running the 16.04 so I cannot compare. I kind of hoped the install iso do not change and I get an old variant but they continuously changed it even in this year multiple times so I have no idea if this is a kernel tree with patches that slows me or not...

Or likely it is, because performance is around the same. I mean.. after fighting with the system without any reboot and forcing it to start and not counting that now I need to measure extreme tux racer frame rates with the apps internal measurer as gallium hud is not working here... also the driver string is missing the "gallium 0.4 on Ati..." part here too and that was the very first thing that I saw as a difference when starting this topic so surely now I am not running the system I ran before - not even close.

It was a system btw, that always just got "updated" from an earlier one. Who knows if that counts... maybe yes and older configs stayed here and there from old distro versions like 14.04 or the 12.04...

Things very much seem to be the same here. :-(

Kernel version: Linux ubuntu 4.15.0-45-generic

Relevant log files:

http://ballmerpeak.web.elte.hu/glxinfo_livecd_16_04.txt

http://ballmerpeak.web.elte.hu/dmesg_livecd_16_04.txt

http://ballmerpeak.web.elte.hu/config_livecd_16_04.txt

Also when using lscpi -v the same memory is named to be ignored just the same way.

PS.: At first sight extreme tux races seemed to perform better, but I had no feedback on the FPS count. When enabling the internal count it says 10-13 FPS which is smaller than on arch, but on arch the measurements are done with the gallium_hud that segfaults here on this version and is unusable - so I wonder what the internal will say when I am on the other system... Basically I cannot compare, but I would not say there is any radical difference. UrT sadly cannot run because it runs out of memory or some other error (it just exited so I am not sure).

PS.: I just hope the speed loss is not just because all kind of per-application configurations in the old system all the time as I am starting to lose my mind as of now and just start to question everything that comes through it

At least the live image had a radeon driver in it and mesa in it...

[bridgman]

Sorry, didn't necessarily mean "latest 16.04" (which is likely to be 18.04 kernel / graphics plus some more updates" but whatever 16.04 version you were running previously.

[prenex]

Sorry, didn't necessarily mean "latest 16.04" (which is likely to be 18.04 kernel / graphics plus some more updates" but whatever 16.04 version you were running previously.

I didn't mean it was a bad idea someone told me to try the original setup, just it was a bad idea of mine to try an image that likely has the latest things just as you mentioned. I was hoping that the install images are in some very old state and people only update them after installation is already done, but thinking back I see the value of them updating the installers to the latest ones as long as there is support for them so that when there is no support, the installer image is at least in the latest state instead of the earliest.

I was boring and now I am running Debian Wheezy 7.0 Xfce i386 Live from the link I posted earlier. It works out of box and here is some data of it:

Maybe it does not have the "radeon" driver, but I guess it might have the kernel modules for it maybe - even if it has not, I might be still able to analyse what the pci subsystem is doing so it might worth a try to liveUSB this too.

Also I will try to set up the planned very old (existing, saved from old times) 8.04 / kernel 2.6.x system. I intend to boot it from the sd card without the bios supporting those kind of things, but the initramfs and the kernel have a place on my hdd so maybe if I add root=/dev/mmblk0 things might magically work (or not). If the initramfs that comes with the old system is not having the modules for sd reading I will have problems. I might also use an old debian with a 2.6 kernel too maybe if this is not working in a one-shot way and I need to create an initramfs myself. I guess I cannot make one on a modern kernel that will be good for a very old kernel...

[prenex]

So I will try the 3.x kernel debian to extract all the logs like I tried the latest 16.04. If it has the kernel modules for radeon I think I can install the radeon for xorg without a reboot and need to restart only the X so I have hopes for testing the whole I think ;-)

Alongside downloading and installing this I work on booting from the internal sd too - but that system might serve completely different information and purpose.