Bug 240294

Summary: x11-drivers/xf86-video-ast does not work on FreeBSD 12
Product: Ports & Packages Reporter: Daniel O'Connor <darius>
Component: Individual Port(s)Assignee: freebsd-x11 (Nobody) <x11>
Status: Closed FIXED    
Severity: Affects Some People CC: adridg, pete, zeising
Priority: --- Keywords: needs-qa
Version: LatestFlags: zeising: maintainer-feedback+
koobs: merge-quarterly?
Hardware: Any   
OS: Any   
Description Flags
Register dump from the working (11.x) system.
Register dump from the broken (12.x) system.
port patch to fix issue
Port patch without the cruft none

Description Daniel O'Connor 2019-09-03 05:54:27 UTC
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:

If this was working as expected in the FreeBSD-11.x this may be a kernel bug.
Comment 2 Daniel O'Connor 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 Daniel O'Connor 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 freebsd_committer 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 Daniel O'Connor 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 freebsd_committer 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 Daniel O'Connor 2019-09-09 02:22:47 UTC
Created attachment 207306 [details]
Register dump from the working (11.x) system.
Comment 8 Daniel O'Connor 2019-09-09 02:25:42 UTC
Created attachment 207307 [details]
Register dump from the broken (12.x) system.
Comment 9 Daniel O'Connor 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 freebsd_committer 2020-09-17 10:12:00 UTC
Is this still relevant?
Comment 11 Daniel O'Connor 2020-09-17 11:17:32 UTC
Yes, although they didn't get back to me about it.
Comment 12 Daniel O'Connor 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 Daniel O'Connor 2020-09-17 14:27:36 UTC
I did some more digging and found this patch to the Linux DRM driver:

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 Daniel O'Connor 2020-09-18 00:01:03 UTC
Created attachment 218037 [details]
port patch to fix issue
Comment 15 Daniel O'Connor 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.
Comment 16 Daniel O'Connor 2021-07-08 07:35:05 UTC
Created attachment 226295 [details]
Port patch without the cruft
Comment 17 Niclas Zeising freebsd_committer 2021-07-08 07:40:36 UTC
LGTM, approved.
Comment 18 commit-hook freebsd_committer 2021-07-09 11:26:10 UTC
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(-)
Comment 19 Adriaan de Groot freebsd_committer 2021-07-09 11:45:44 UTC
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.
Comment 20 Daniel O'Connor 2021-07-09 12:31:59 UTC
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.
Comment 21 Daniel O'Connor 2021-07-09 12:32:45 UTC
(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.
Comment 22 Daniel O'Connor 2021-07-12 02:52:15 UTC
I tested this successfully on a Supermicro X11SSH-F with FreeBSD 13.