Bug 240294 - x11-drivers/xf86-video-ast does not work on FreeBSD 12
Summary: x11-drivers/xf86-video-ast does not work on FreeBSD 12
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-x11 mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-03 05:54 UTC by darius
Modified: 2019-09-09 02:25 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
Register dump from the working (11.x) system. (768.00 KB, text/plain)
2019-09-09 02:22 UTC, darius
no flags Details
Register dump from the broken (12.x) system. (768.00 KB, text/plain)
2019-09-09 02:25 UTC, darius
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
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 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 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 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 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.