Date: Sun, 20 Sep 2020 23:46:56 +0200 From: Crest <crest@rlwinm.de> To: freebsd-hackers@freebsd.org Subject: Re: ASPEED video driver Message-ID: <8b15ca21-07d1-7eb1-4d99-3654af585052@rlwinm.de> In-Reply-To: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au> References: <8851FC7F-979D-4CDC-8513-CE893B2EF269@dons.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07.09.20 05:32, O'Connor, Daniel via freebsd-hackers wrote:
> Hi,
> Has anyone had success with the ASPEED Xorg driver? I have tried several versions (in ports, from ASPEED directly, from freedesktop.org etc) and they all hang trying to read DRAM information in ASTGetDRAMInfo. I am running FreeBSD 12 on a Supermicro X11SSH-F.
>
>
> The hang is here:
> do {
> ;
> } while (*(volatile ULONG *) (pAST->MMIOVirtualAddr + 0x10000) != 0x01);
>
> I patched it to use some hard coded values I extracted from an old system where it worked and it does run but the performance is quite terrible.
>
> I've also tried scfb (performance is so so but it's stuck and 1024x768) and VESA (runs at 1920x1080 but the performance is intolerable).
>
> I'm not expecting mind blowing performance but even the best performing option above is quite painful to use. These systems are mostly unattended but the bad performance does make the setup and test during installation quite painful.
>
> Performance used to be tolerable but it seems to have gotten significantly worse in newer BIOS versions.
>
> For now we are putting passively cooled GT710s in them but it would be nice to fix it properly.
>
> I note that Linux has a DRM driver for these https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/ast
>
> However I'm not sure how that integrates with X.. If Linux doesn't actually use the Xorg driver then I suppose that would explain why it's rotted and useless.
>
> If that is the case, does anyone know difficult it would be to port the Linux DRM driver?
>
> I did try contacting ASPEED and Supermicro but they pointed the finger at each other and then blamed FreeBSD so I'm a bit stuck.
>
> Thanks.
I have no solution for the question you've asked, but I may have a
solution for your problem. Over the years I've found the different IPMI
KVM implementations terrible to use (slow to update, ridiculous input
lag, keyboard layout fuck ups, etc.). Instead I prefer to use the IPMI
Serial over LAN interface to install fresh systems avoiding the trouble
of emulating a keyboard (and mouse) and capturing the video output. On
most servers you can interrupt the boatloader via the serial connection
and enable dual console operation in FreeBSD. Some of the buggier IPMI
implementations work better with *only* a serial console enabled.
This example should work for most modern x64 server boards (with minimal
changes)
boot_multicons="YES" # Enable multi console support
boot_serial="YES" # Enable serial output
console="comconsole,vidconsole" # On UEFI systems try efi instead
comconsole_speed="115200" # Most boards default to 115200 baud instead
of the 9600 FreeBSD uses for legacy reasons
# comconsole_port="0x2f8" # If the Serial over LAN is mapped to COM2,
check dmesg | grep uart
Sorry if this reads like a "you're holding it wrong" kind of answer, but
I haven't had much success with IPMI keyboard and video redirection over
the years.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8b15ca21-07d1-7eb1-4d99-3654af585052>