agpgart

[Grogan]

I've never found a straight answer as to whether or not that is used or needed with PCI-Express graphics.

The module loads and is used by ttm (Translation Table Manager, part of the DRM system, a memory management driver used by probably everything but Intel UMA devices like onboard graphics that uses system memory)

However, it's likely just getting loaded as part of the module stack because it's present. Here's the thing. NOT having agpgart when it's needed doesn't make your graphics driver not work, it disables write combining through MTRR ("memory type range registers", kind of like programmable CPU caches, accessed through model specific registers (MSR)) and OpenGL likes that, it would perform poorly without it. It's hard to know whether I'm really using that module or not but I think it's only for AGP graphics. I'm pretty sure PCI-E uses other methods to enable its GART.

I've been building that for 20+ years (well, back then it was AGP) because of that. This is the first kernel ever, where I'm going to turn that off

[Grogan]

I could have gotten rid of agpgart 15 years ago... that it was loading and in use was what deterred me. Easier to just leave it, distributors all do.

But it does not use that module at all to initialize the GART or anything. I noticed something a bit interesting there (not related to this), look how the BAR is larger than the VRAM. That'll probably be so some system memory can be mapped into it too if needed. (GART, GTT)

Code: Select all

[    0.519194] amdgpu 0000:03:00.0: amdgpu: VRAM: 12272M 0x0000008000000000 - 0x00000082FEFFFFFF (12272M used)
[    0.519196] amdgpu 0000:03:00.0: amdgpu: GART: 512M 0x00007FFF00000000 - 0x00007FFF1FFFFFFF
[    0.519203] [drm] Detected VRAM RAM=12272M, BAR=16384M
[    0.519204] [drm] RAM width 192bits GDDR6
[    0.519237] [drm] amdgpu: 12272M of VRAM memory ready
[    0.519238] [drm] amdgpu: 32069M of GTT memory ready.
[    0.519243] [drm] GART: num cpu pages 131072, num gpu pages 131072
[    0.519293] [drm] PCIE GART of 512M enabled (table at 0x0000008000300000).
[    0.519577] [drm] Loading DMUB firmware via PSP: version=0x07002900
[    0.519685] [drm] Found VCN firmware Version ENC: 1.19 DEC: 7 VEP: 0 Revision: 0
[    0.519688] amdgpu 0000:03:00.0: amdgpu: Will use PSP to load VCN firmware

This kernel might be a bit screwy though. After I built and installed it, I rebooted and my keyboard went nuts. Any key pressed was repeating until pressed again. It still seemed to work on the grub menu (arrow keys and enter) but as soon as the kernel loaded, it was fuckery. It started doing other screw things like vertically scrolling and inserting characters too on a subsequent reboot. I thought maybe it was a stuck CTRL key but I worked it and others and again while powered off. On the next boot it wasn't doing that but you could tell something was going on with a little flicker in the "Welcome to Arch Linux" and the console login prompt. I SSH'd in to see what was going on and it was floods of USB reset messages in the kernel ring buffer.

I only changed 2 things in my kernel, disabling agpgart and a setting to strip unused symbols (makes for much smaller modules on disk). Neither of those should have affected this, especially not agpgart. So I reverted the symbol trim setting but of course it wasn't that either. (It's not going to strip symbols needed by anything in-tree).

So powered off again and plugged the keyboard into a different USB port, a yellow one. I wasn't completely expecting it to work (this keyboard is pre-USB3 and it is a "low speed USB device"). All has been well in keyboard and mouse land ever since.

I don't know, maybe the problem all along with that PS/2 to USB converter was that it didn't like being on the same USB ports as my MSI mouse (that's what was actually complaining about latency, well the input subsystem in relation to it). Those aren't actually "USB 2" ports (not a USB 2 controller) they are just pinned for USB 2. It's all the XHCI controller. I don't get why the USB port would matter if it's all the same controller, but whatever, MSI.

Also had a strange problem today. I updated my glibc (still 2.39, just a newer commit for Arch's new pkgrel so that shouldn't have changed any major behaviour) and when I do that I reboot. My network didn't come up. The card was initialized but it was in "Link is down" status. That's never happened before. A ctrl-alt-del fixed it (I didn't screw around trying to restart the network but I should have to see)

Edit: Oops, the glibc thing could have come into play with the network failure. My pkgrel wasn't the same, and for some reason my *glibc* wildcard didn't work in IgnorePkg and I ended up with the distro packages when I did pacman -Syu right away and didn't pay attention and just said Y (alternate spelling of "fuck off" lol) then ctrl-alt-del. So maybe some service barfed on first boot or something. I really should take out the "quiet" parameter from my boot cmdline but I've come to enjoy a boot that takes a few seconds and shows nothing until console login. Gotta fix my glibc now (pkgrel and ignore list).

At least I can't SEE how a loaded module, that wasn't really doing anything, could have affected my kernel like this. (agpgart I mean). Possible I guess, with that gone maybe something else loads at different addresses.