> On 24 Aug 2019, at 10:07, O'Connor, Daniel <darius at dons.net.au> wrote: >> On 24 Aug 2019, at 02:23, Pete Wright <pete at nomadlogic.org> wrote: >> On 8/23/19 7:30 AM, O'Connor, Daniel wrote: >>> Hi, >>> We have a Supermicro X11SSH-F motherboard which has a ASPEED AST2400 video chipset with FreeBSD 12.0-RELEASE r341666 GENERIC amd64 on it. >>> Unfortunately I am unable to get X working with it properly, I have the xf86-video-ast package (version 1.1.5_2) installed, however X seems to hang when started. >> >> would you be able to share the Xorg.log from when it hangs? > > Ah yes of course :) > > I also see that xinit is stuck in 'pause' then goes to 'select': > xauth: file /root/.serverauth.4556 does not existI tried the binary driver from http://upload.aspeedtech.com/BIOS/v10902_linux_freebsd_solaris.zip (the xorg78_5 one) and while it works I would claim it's any faster (certainly not smooth). I built the source version from http://upload.aspeedtech.com/BIOS/v11001_linux.zip which was a slightly newer version by replacing the source in the usual port, but it behaved the same as the binary version. I also had an idea to try a last ditch hail Mary and set write combining with memcontrol like the good old days of PCI VESA cards but.. [chumphon 4:05] ~> dmesg|grep vgapci vgapci0: <VGA-compatible display> port 0xc000-0xc07f mem 0xde000000-0xdeffffff,0xdf000000-0xdf01ffff irq 18 at device 0.0 on pci4 vgapci0: Boot video device [chumphon 4:06] ~> sudo memcontrol set -b 0xde000000 -l 0x1000000 -o vga write-through write-combine memcontrol: can't set range: Invalid argument Although I could set uncacheable (no difference). Next stop will be obscure BIOS settings I suppose. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
> On 27 Aug 2019, at 13:45, O'Connor, Daniel <darius at dons.net.au> wrote: > > Although I could set uncacheable (no difference). > > Next stop will be obscure BIOS settings I suppose.I couldn't find anything useful there. I realised that my scfb failure was because I am booting BIOS rather than UEFI but I will have to reinstall before I can fix that. There was a thread about a performance regression in Linux (https://ubuntuforums.org/showthread.php?t=2399941) but that applies to KMS.. I checked the drm-kmod port but there is no ASPEED driver there. -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum
> On 27 Aug 2019, at 18:10, O'Connor, Daniel <darius at dons.net.au> wrote: > >> On 27 Aug 2019, at 13:45, O'Connor, Daniel <darius at dons.net.au> wrote: >> >> Although I could set uncacheable (no difference). >> >> Next stop will be obscure BIOS settings I suppose. > > I couldn't find anything useful there. > > I realised that my scfb failure was because I am booting BIOS rather than UEFI but I will have to reinstall before I can fix that.I reinstalled with UEFI and scfb works now (not sure if it's any faster yet). It didn't fix ast though. I rebuilt the AST driver with debugging and found it was stuck at.. 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. If I comment that out X runs but the AST driver then rejects every mode line, eg [ 48784.246] (II) AST(0): Not using driver mode "1920x1080" (bad mode clock/interlace/doublescan) I checked the code against what is working in FreeBSD 11 and it is identical. That does use an older Xorg server though so I am not sure if it is FreeBSD 12 (compiler or kernel or..) or an Xorg change that has broken things. I modified the driver on the working system to dump the values that ASTGetDRAMInfo extracts and hard coded them and it works(!) on the FreeBSD 12 system. Obviously while this works for me it's not a long term solution :) 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 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 Any suggestions welcome :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum