Hi, I have this port on a Supermicro X11SSH-F and it doesn't work, it hands the X server (kill -9 required to recover). I did some debugging and found it is stuck here.. 0x0000000801ae1d86 in ASTGetDRAMInfo (pScrn=0x801af7000) at ast_vgatool.c:439 439 } while (*(volatile ULONG *) (pAST->MMIOVirtualAddr + 0x10000) != 0x01); (gdb) print/x *(volatile ULONG *) (pAST->MMIOVirtualAddr + 0x10000) $2 = 0xffffffff Reading around this area also reads 0xffffffff all the time. ie it is like that memory is not correctly mapped. I added some debugging to the mapping process in ASTMapMMIO: [ 71021.555] (II) AST(0): pci_device_map_range Addr 0xdf000000 size 0x20000, err 0 result 0x01b30000 But when I check ASTGetDRAMInfo().. (gdb) print/x pAST->MMIOVirtualAddr $2 = 0x801b30000 (gdb) print/x *(0x01b30000) Cannot access memory at address 0x1b30000 The mappings look to match dmesg: vgapci0: <VGA-compatible display> port 0xc000-0xc07f mem 0xde000000-0xdeffffff,0xdf000000-0xdf01ffff irq 18 at device 0.0 on pci4 Curiously on the working machine with an identical motherboard with FreeBSD 11 it is at a different location: vgapci0: <VGA-compatible display> port 0xd000-0xd07f mem 0xf6000000-0xf6ffffff,0xf7000000-0xf701ffff irq 16 at device 0.0 on pci4 I extracted the values from the working system and hard coded them into the FreeBSD 12 one and while it starts it is very slow (same speed as VESA) The VESA driver is significantly slower than I expect, I am not sure if that is related or just it sucking harder in new systems..
Just a note the AST driver from Xorg hasn't been updated in like 4years: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ast/-/tags/xf86-video-ast-1.1.5 If this was working as expected in the FreeBSD-11.x this may be a kernel bug.
FWIW I did try the code from the ASPEED website which is slightly newer but it had the same effect. I wonder if the mapping to physical memory isn't working properly, although it works for the frame buffer and must work for *most* of the registers since it can successfully draw things. That said the registers it has trouble with are offset >0x10000 (ie 64k) where as most of the others seem <0x10000 - so perhaps there is some rounding issue with mapping? (wild guess..)
I noticed that libpciaccess was 0.13.5 on the working system and 0.16 and there were a bunch of FreeBSD related commits between those 2. I tried 0.13.5 on the non-functional system but it had no effect.
(In reply to darius from comment #3) The changes in libpciaccess was me upstreaming a whole bunch of code that was already in our local tree, so the difference there should be minimal. Be aware that a lot of xf86-video drivers for older graphics cards are not really updated upstream, only maintained. It might be better to simply use the vesa or scfb driver.
The VESA driver is unusably slow, and the SCFB driver defaulted to 1024x768. The ASPEED driver from 4 years ago works perfectly fine on a FreeBSD 11 system with identical hardware so I am hopeful it should work on FreeBSD 12 as well.
(In reply to darius from comment #5) Then, most likely something changed in FreeBSD, as Pete already pointed out, the driver hasn't seen any changes in quite some time. I don't know the reason for the driver using different mappings on 12 and 11.
Created attachment 207306 [details] Register dump from the working (11.x) system.
Created attachment 207307 [details] Register dump from the broken (12.x) system.
I contacted ASPEED about this and received this reply: It related to the CVE patch which Supermicro implemented. We will try to reproduce your issue in next week and see whether it related to our driver or not, please wait. So, fingers crossed..
Is this still relevant?
Yes, although they didn't get back to me about it.
I did work around this by patching the driver to try the read 10000 times and if it fails then hard code the RAM information (which was extracted from a working system). This seemed to work but the performance wasn't great, however I subsequently learnt that compositing was on and I haven't been able to try it with that turned off as yet. I think the RAM information is only used to work out the maximum resolution/bit depth so rough and ready values are fine since I'm only doing 1080p.
I did some more digging and found this patch to the Linux DRM driver: https://patchwork.kernel.org/patch/9578793/ Where it talks about P2A access being disabled for security - so I am wondering if a BMC or BIOS update has flipped that to fix a security vulnerability. That patch talks about using device tree but I don't know how to do that in FreeBSD so hard coded defaults will have to do. I will also submit this patch upstream.
Created attachment 218037 [details] port patch to fix issue
I've attached a patch for the port. I also filed a bug upstream (https://gitlab.freedesktop.org/xorg/driver/xf86-video-ast/-/issues/5) and notified ASPEED via email but I have no idea how responsive either of those will be.
Created attachment 226295 [details] Port patch without the cruft
LGTM, approved.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=b6eed3fd348662481b8180988860bb23cb171e41 commit b6eed3fd348662481b8180988860bb23cb171e41 Author: Darius <darius@dons.net.au> AuthorDate: 2021-07-09 11:19:00 +0000 Commit: Adriaan de Groot <adridg@FreeBSD.org> CommitDate: 2021-07-09 11:24:23 +0000 x11-drivers/xf86-video-ast: restore functionality on 12 AST video which works on 11-, doesn't on 12-, restored by pulling in some Linux DRM patches and then massaging it to avoid device-tree madness, from darius@dons.net.au PR: 240294 Approved by: zeising (x11@) x11-drivers/xf86-video-ast/Makefile | 2 +- .../xf86-video-ast/files/patch-ast_vgatool.c (new) | 33 ++++++++++++++++++++++ 2 files changed, 34 insertions(+), 1 deletion(-)
Landed. Darius, if you could confirm the updated port (well, it's just your patch applied) works, then a merge to quarterly can be arranged.
BTW after some review, I don't think this is an 11 vs 12 thing, but I think it is due to BIOS patches for security vulns. It's just that I was only able to do a comparison with an old BIOS running 11 and a new BIOS running 12 so I couldn't tell.
(In reply to Adriaan de Groot from comment #19) I won't be able to try it with actual hardware until probably Monday, I hope that's OK.
I tested this successfully on a Supermicro X11SSH-F with FreeBSD 13. Thanks!