|Summary:||x11-drivers/xf86-video-ast does not work on FreeBSD 12|
|Product:||Ports & Packages||Reporter:||darius|
|Component:||Individual Port(s)||Assignee:||freebsd-x11 (Nobody) <x11>|
|Severity:||Affects Only Me||CC:||pete, zeising|
Description darius 2019-09-03 05:54:27 UTC
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..
Comment 1 pete 2019-09-03 16:31:44 UTC
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.
Comment 2 darius 2019-09-03 23:31:15 UTC
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..)
Comment 3 darius 2019-09-04 01:53:50 UTC
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.
Comment 4 Niclas Zeising 2019-09-04 07:58:35 UTC
(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.
Comment 5 darius 2019-09-04 08:00:18 UTC
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.
Comment 6 Niclas Zeising 2019-09-04 08:09:02 UTC
(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.
Comment 7 darius 2019-09-09 02:22:47 UTC
Created attachment 207306 [details] Register dump from the working (11.x) system.
Comment 8 darius 2019-09-09 02:25:42 UTC
Created attachment 207307 [details] Register dump from the broken (12.x) system.
Comment 9 darius 2019-11-21 06:45:46 UTC
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..
Comment 10 Niclas Zeising 2020-09-17 10:12:00 UTC
Is this still relevant?
Comment 11 darius 2020-09-17 11:17:32 UTC
Yes, although they didn't get back to me about it.
Comment 12 darius 2020-09-17 12:25:30 UTC
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.
Comment 13 darius 2020-09-17 14:27:36 UTC
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.
Comment 14 darius 2020-09-18 00:01:03 UTC
Created attachment 218037 [details] port patch to fix issue
Comment 15 darius 2020-09-18 00:02:07 UTC
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.