I’ve been working with Linux since virtually its inception. It appears that we are back to the good ole days of video “challenges”… I don’t want to waste too much time on the intro to this problem but please appreciate that I’ve been struggling with this issue for almost a week and that I’ve done a lot of Googling and Tried a bunch of things. I’m simply running out of options (other than going back to 42.X or installing a new video card) and I’m hoping some insight from the community may help. Additionally, I’m a system integrator and the image I’m trying to build will be rolled out to multiple customers. So, the decision to install and alternate video card has greater ramifications than just one card…
The general problem is that It appears that all of my attempted LEAP 15.0 builds (on multiple motherboards) are using the fbdev framebuffer driver instead of the built-in (or upgraded) ast video driver. The frame buffer performance is pretty miserable and particularly painful during screen refreshes/repaints. I have applied ANY/ALL software updates to ensure everything is current. Here are some details:
I originally had this on a SuperMicro X11DPH-T motherboard candidate, so I switched to trying the install on an Asus WS C621 Sage motherboard. Same problem. Both motherboards are dual Xeon boards using the Intel 621 chipset and have an integrated ast 2500 video chipset. Two similar boards from different vendors - same problem.
I’m getting an error in the Xorg log which basically says the following:
ast: The PCI device 0x2000 at 02@00:00:0 has a kernel module claiming it.
ast: This driver cannot operate until it has been unloaded.
It does look like there indeed is an “ast” driver built in to the kernel, but perhaps X11 is not using it? It looks like X11 is trying to re-load the same driver but is complaining that the kernel already has it loaded?
I tried blacklisting the module from the boot screen (modprobe.blacklist=ast) but then X won’t load at all. It just keeps flashing the text screen and retrying. I don’t remember the exact Xorg log message but it basically said no driver existed for the “card”.
I tried updating the ast driver from a download on their website (lxdrv) but this appeared to change nothing…
I also tried “nomodeset” on boot but that also resulted in a flashing text screen.
If someone could point me in the right direction, I would surely appreciate it. I’m pretty exhausted and frustrated at this point… I’ld post the full Xorg log if I could only find a way to attach it…
Yup, the video chipset is integrated on the motherboard. I can disable it but that would be a shame. I don’t need 3D or extreme graphics performance as these are server builds. I don’t want to have to put a graphics card in every server if its not necessary.
/lib/firmware/ast_dp501_fw.bin (3 Aug 2018 26808) exists…
Here’s the output you requested:
linux-x29a:~ # /sbin/lspci -nnk | egrep -A3 “VGA|Display|3D”
02:00.0 VGA compatible controller : ASPEED Technology, Inc. ASPEED Graphics Family [1a03:2000] (rev 41)
Subsystem: ASUSTeK Computer Inc. Device [1043:86ed]
Kernel driver in use: ast
Kernel modules: ast
AIUI, uncommon gfx (non-Intel, non-AMD, non-NVidia) were a significant consideration in the effort that went and continues to go into Xorg’s integrated modesetting driver. As your Xorg.0.log shows, modeset(0) is clearly in use, not FBDEV, and without any attributed (EE) messages, I’m inclined to think you’re experiencing a bug that needs to be reported to the modesetting driver component of Xorg, and/or to the kernel devs.
BTW, susepaste is a command for uploading logs - no need for a web browser. Maybe you should try using it for dmesg and/or journal?
'cmon man! I spent a week on this with two different motherboards. I already said I tried to update the driver. Why would you think I DIDN’T read the README file?
Built-in kernel driver didn’t work…
Downloaded/Updated driver (from Aspeed) didn’t change anything (although the auto-update.sh reported success)… They didn’t have a pre-packed RPM for LEAP though, so I expect their willingness to support this distro will be somewhat “unenthusiastic”…
I’ve Googled for ast driver issues in opensuse and LEAP 15 endlessly and I’ve found nothing. (However, I did find info on how to disable the driver-built in to the kernel (modprobe.blacklist) based on some nouveau-related postings…)
it appears that integrated Ast video is pretty popular with Xeon Motherboard manufacturers (at least with both SuperMicro and Asus)
That’s why I’m asking the community here for support!
My reading is the EEs apply to an “ast” driver, not the modeset(0) driver that subsequently loads without claiming any errors.
If PCI device 0x2000 at 02@00:00:0 is the AST gfxchip, what kernel module is claiming it?
[li][ 50.733] (II) modeset(0): using drv /dev/dri/card0[/li]Good!?!?!, unless there is an AST driver that’s supposed to be preferred. If there is such, I’d expect it to be in either its own xf86 rpm available in openSUSE repos via upstream source package, or in a manner equivalent to the proprietary NVidia driver. Before this thread I’d not heard of AST since two decades ago. I thought it was a dead brand.
OTOH, could it be there is an available AST module or driver that needs a special cmdline parameter to prevent the Xorg-integrated modesetting driver blocked?
[li][ 50.733] (WW) Falling back to old probe method for fbdev[/li]No matter, since we don’t want FBDEV slowing everything to a crawl.
[li][ 50.733] (II) Loading sub module “fbdevhw”
[/li]> [li][ 50.733] (II) LoadModule: “fbdevhw”
Am I misunderstanding something?
It kinda looks like its falling back to “fbdevhw” (at least to me). Its also performing similarly (frame buffer).
These seem expected to me. Submodule fbdevhw is currently engaged here on Intel 4th Gen gfx.
(Did I not use susepaste properly in my last message?
No problem, just noting, since it can be easier.
It is the kernel graphics drivers that communicate with the hardware. The Xorg (user-space) drivers provide support for OpenGL and 2D acceleration. The modesetting driver is a basic Xorg driver (supporting KMS graphics drivers) and uses GLAMOR to provide 2D acceleration over OpenGL.
While searching online, I found an old openSUSE thread discussing an AST graphics issue. A suggestion by oldcpu given in this post turned out to be helpful…
Booting with ‘nomodeset’ by itself, and also booting with ‘nomodeset’ and having a custom /etc/X11/xorg.conf.d/50-device.conf file (to call the ‘ast’ driver) are IMHO viable options to try.
Back when 12.2 (or perhaps it was 12.1) was in milestone release phone, the only way to get to the ‘radeon’ driver with my AMD HD3450 graphic hardware was to boot with ‘nomodeset’ (to disable the KMS automatic driver assignment efforts) and also in addition to ‘nomodeset’ (in the same boot) specify the ‘radeon’ driver in the /etc/X11/xorg.conf.d/50-device.conf. Hence my thinking one could try both with the ‘ast’ driver.
The OP later reported (post #41 onwards) that this approach seemed to have worked successfully. It’s a long thread and there were some other anomalies discussed as well which may not apply here. Anyway, I wanted to share it just in case it is helpful here.
Nice find Deano! In this era of automagic it’s too easy to forget sometimes manual configuration with absent or missing instruction is required for extraordinary hardware. Not only might Driver in *-device.conf be one necessary solution, there may be a comparable cmdline option, if only it could be discovered.
I went to https://www.aspeedtech.com/support.php and downloaded the v1.08 DRM package and took a looksee. To me, who knows all but nothing about building anything from source, it suggests a need to try an SLE 4.4 kernel, or build a 4.12 DRM module from the provided SLE kernel 4.4 source.
I take that back. Even 42.3 has an xf86-video-ast rpm. With it installed, I’d expect 50-device.conf to do the job.
I believe I tried nomodeset with 50-device.conf. I know I did modprobe.blacklist with 50-device.conf. It was a long week though so its worth trying again just to be sure… I’ll do that this morning and report back.
FYI - The vendor (Aspeed) is posting various packaging of relatively “fresh” drivers and multiple vendors (Asus, SuperMicro) server boards are using this chipset for integrated video. It appears that this video chipset is far from “dead”…
I posted a support message with the vendor but I’m not sure they got it. The online submission page did not reply with a confirmation page or anything (just a blank page)… I’ll try again today.