AST2500 Video Driver failing on multiple motherboards

evanevery · October 22, 2018, 9:07pm

deano_ferrari:

I’m not sure from if any module needs to be blacklisted, just the “nomodeset” boot option and /etc/X11/xorg.conf.d/50-device.conf AFAIU…
Section "Device" 
   Identifier "Default Device" 
# 
   Driver "ast"
# 
EndSection 

Just to be sure, I tried setting the video driver in 50-device.conf and then booting both WITH and WITHOUT “nomodeset”. In BOTH cases all I get is a blinking screen (probably as X tries to initialize over and over)…

If I’m reading the associated logs (Xorg.0.log) properly:

booting with driver set in 50-device.conf and WITHOUT “nomodeset” still says “kernel has device claiming it” and then stops abruptly with “No devices detected”

https://susepaste.org/19353972

booting with driver set in 50-device.conf and WITH “nomodeset” looks like the ast driver tries to load but fails on all sorts of resolution errors:

https://susepaste.org/27875665

oldcpu · October 22, 2018, 10:09pm

I’ve been watching this thread, and while 5 years back I attempted to help a user with AST hardware, its not clear to me how successful my efforts may have been. I think with ‘nomodeset’ together with ‘ast’ in the 50-device.conf, some progress was made. The nomodeset allows an attempt at loading the ast driver (via the 50-device.conf), and we can now look in to that. Having typed that, I suspect this current thread issue is beyond my expertise to help.

Still, I think I could learn some things and I have a dumb question, based on my assuming no resolution appeared to have worked. … I am curious, was your monitor correctly identified? I note from the xorg.conf.log file:

 
    62.059] (II) AST(0): Manufacturer: SNY  Model: 2670  Serial#: 16843009
...
    62.060] (II) AST(0): Monitor name: SDM-X73

was that a correct identification?

oldcpu · October 22, 2018, 10:27pm

Assuming a correct monitor identification, I note when you boot without ‘nomodest’ and without a custom ‘50-device’ conf (and obtain a frame buffer (?)) setup, I see this in the xorg.conf.log file you posted:


Successfull boot

    51.535] (II) modeset(0): Not using mode "1280x1024" (bad mode clock/interlace/doublescan)
    51.535] (II) modeset(0): Printing probed modes for output VGA-1
    51.535] (II) modeset(0): Modeline "1280x1024"x60.0  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
    51.535] (II) modeset(0): Modeline "1024x768"x75.0   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
    51.535] (II) modeset(0): Modeline "1024x768"x70.1   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
    51.535] (II) modeset(0): Modeline "1024x768"x60.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
    51.535] (II) modeset(0): Modeline "800x600"x72.2   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
    51.535] (II) modeset(0): Modeline "800x600"x75.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
    51.535] (II) modeset(0): Modeline "800x600"x60.3   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
    51.536] (II) modeset(0): Modeline "640x480"x75.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
    51.536] (II) modeset(0): Modeline "640x480"x72.8   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
    51.536] (II) modeset(0): Modeline "640x480"x59.9   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)

But when you boot the PC with ‘nomodeset’ and ‘50-device.conf’ specifying the ‘ast’ driver (and the boot fails) you get this:


    62.060] (II) AST(0): Modeline "1280x1024"x**0.0**  108.00  1280 1328 1440 1688  1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP)
    62.060] (II) AST(0): Modeline "800x600"x**0.0**   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz e)
    62.060] (II) AST(0): Modeline "640x480"x**0.0**   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz e)
    62.060] (II) AST(0): Modeline "640x480"x**0.0**   31.50  640 664 704 832  480 489 492 520 -hsync -vsync (37.9 kHz e)
    62.060] (II) AST(0): Modeline "640x480"x**0.0**   25.18  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz e)
    62.060] (II) AST(0): Modeline "720x400"x**0.0**   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz e)
    62.060] (II) AST(0): Modeline "1280x1024"x**0.0**  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz e)
    62.060] (II) AST(0): Modeline "1024x768"x**0.0**   78.75  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.0 kHz e)
    62.060] (II) AST(0): Modeline "1024x768"x**0.0**   75.00  1024 1048 1184 1328  768 771 777 806 -hsync -vsync (56.5 kHz e)
    62.060] (II) AST(0): Modeline "1024x768"x**0.0**   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz e)
    62.060] (II) AST(0): Modeline "800x600"x**0.0**   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz e)
    62.060] (II) AST(0): Modeline "800x600"x**0.0**   50.00  800 856 976 1040  600 637 643 666 +hsync +vsync (48.1 kHz e)
    62.060] (II) AST(0): Modeline "1280x960"x**0.0**  108.00  1280 1376 1488 1800  960 961 964 1000 +hsync +vsync (60.0 kHz e)
    62.060] (II) AST(0): <default monitor>: Using hsync range of 28.00-65.00 kHz
    62.060] (II) AST(0): <default monitor>: Using vrefresh range of 57.00-75.00 Hz
    62.060] (II) AST(0): <default monitor>: Using maximum pixel clock of 115.00 MHz
    62.060] (II) AST(0): Estimated virtual size for aspect ratio 1.2593 is 1280x1024
    62.060] (II) AST(0): Clock range:   9.50 to 200.00 MHz

i.e. the specific frequencies associated with specific resolutions appear not to have been identified.

Perhaps there is a logical explanation for that ? But if so, it exceeds my knowledge.

deano_ferrari · October 22, 2018, 10:30pm

The fatal error that caught my attention was…

(EE) AST(0): Map FB Memory Failed

…but I’m not sure what is needed to get around this.

oldcpu · October 22, 2018, 10:35pm

Would specifying the resolution modelines with a correct frequency in a configuration file work around that memory map failure ? I don’t know enough about this to say whether that even a relevant suggestion.

evanevery · October 22, 2018, 10:46pm

Yes, the monitor was correctly identified though I’m not sure why all those frequencies are being rejected (nomodeset w/50-device.conf)…

I’ve also just put in a low end Nvidea card and the nouveau driver appears to be properly implemented (not a long term solution). Just a cross-check…

I can try a newer monitor to see if that changes the freq problems…

deano_ferrari · October 23, 2018, 12:23am

What little I know about the ast driver came from here…

With this being a server-oriented graphics chip, the AST KMS driver design is a bit different from the other Linux KMS drivers and it ends up putting the KMS console into system RAM since the video RAM on these chips tend to be low capacity. The driver then does dirty updates to a copy in the video RAM. When user-space sets a new scanout buffer it then forcefully evicts the video RAM console so X can create a frame-buffer using all of the video RAM.

The AST DRM/KMS driver is using TTM for video memory management.

There isn’t going to be a user-space driver for the ASpeed hardware but rather this driver is intended to go with the xf86-video-modesetting DDX driver.

evanevery · October 23, 2018, 3:12pm

I was wondering about shared memory and this may be a key consideration. We don’t need much memory though as this is only for a server console.

I am going to push forward with nomodeset + 50-device.conf and try to manually define some frequencies and resolutions.

I was also copied on an inter-office message within aspeedtech in a request for support. So maybe something is moving on that end as well…

mrmazda · October 23, 2018, 5:06pm

That says the AST driver is a KMS driver. Cmdline option nomodeset disables KMS. X drivers Amdgpu, ATI, Intel, Modesetting and Nouveau are all disabled by the nomodeset option. Thus I fully expect the same with the AST driver, and effort to get the AST driver working with nomodeset on cmdline to be wasted effort.

xf86-video-modesetting no longer exits dating back IIRC to 42.1, as it was merged directly into the Xorg server. Its use in 15.0 should be automatic absent something that explicitly disables it.

Given comment #1 it seems to have worked for 42.3, it seems time to file an openSUSE bug to get “SLE” devs to look at this.

evanevery · October 23, 2018, 6:23pm

Bug posted here: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963

mrmazda · October 23, 2018, 7:52pm

After reading the bug I put more thought into this. The bug’s Xorg.0.log indicates modeset is engaged as expected. It looks to me like

    50.733] (EE) ast: The PCI device 0x2000 at 02@00:00:0 has a kernel module claiming it.
    50.733] (EE) ast: This driver cannot operate until it has been unloaded.

may be less important than

(EE) modeset(0): glamor initialization failed

since this is a performance problem, not a pass/fail problem. Glamor is an OpenGL X acceleration module.

deano_ferrari · October 23, 2018, 8:04pm

mrmazda:

After reading the bug I put more thought into this. The bug’s Xorg.0.log indicates modeset is engaged as expected. It looks to me like
    50.733] (EE) ast: The PCI device 0x2000 at 02@00:00:0 has a kernel module claiming it.
    50.733] (EE) ast: This driver cannot operate until it has been unloaded.
may be less important than
(EE) modeset(0): glamor initialization failed
since this is a performance problem, not a pass/fail problem. Glamor is an OpenGL X acceleration module.

I think both are significant here. The glamor module is loaded by the Xorg modeset driver, but something causing it to fail.

Tyler_K · October 23, 2018, 9:35pm

Background

[ul]
[li]there is the kernel drm driver “ast.ko” … see /lib/modules/yourkernelversion/kernel/drivers/gpu/drm/ast[/li][LIST]
[li]it’s a KMS (kernel mode setting) based driver by default [/li][li]it apparently still has UMS (user mode setting) support … see “/usr/sbin/modinfo ast” … i.e. enable/disable modesetting [/li][/ul]

[li]and then there is the userland xorg driver “ast_drv.so” … see /usr/lib64/xorg/modules/drivers/[/li][ul]
[li]“but I can’t find it there!” you say … well, as reported earlier in the thread, it was apparently there in prior leap editions … and you can get/d/l one from aspeed anyways [/li][li]it is apparently only UMS based [/li][/ul]

[li]and then there is also the userland, now built into X server, modesetting driver[/li][ul]
[li]it’s to be used with KMS based kernel drivers [/li][/ul]

[/LIST]

Results
[ul]
[li]Using the ast.ko in KMS mode + dumbass ast_drv.so xorg driver installed in place + modesetting driver = glamor not initializing so performance falls back to sloooooow motion [/li][/ul]
whereas

[ul]
[li]using ast.ko in UMS mode (i.e. nomodeset on kernel cmdline) + dumbass ast xorg driver = a modesetting problem [/li][/ul]

Recommendation
[ul]
[li]Use KMS mode [/li][li]ditch the ast xorg driver … remove all traces/mention of it from any xorg configuration file and allow the system to automagically configure itself [/li][/ul]

If glamor initializing problem persists: bug xorg people … hit them with a stick.

deano_ferrari · October 24, 2018, 1:06am

and then there is the userland xorg driver “ast_drv.so” … see /usr/lib64/xorg/modules/drivers/

“but I can’t find it there!” you say … well, as reported earlier in the thread, it was apparently there in prior leap editions … and you can get/d/l one from aspeed anyways

it is apparently only UMS based

The Xorg driver component is available via the xf86-video-ast driver package…

# rpm -ql  xf86-video-ast 
/usr/lib64/xorg/modules/drivers
/usr/lib64/xorg/modules/drivers/ast_drv.so
/usr/share/doc/packages/xf86-video-ast
/usr/share/doc/packages/xf86-video-ast/COPYING
/usr/share/doc/packages/xf86-video-ast/ChangeLog
/usr/share/doc/packages/xf86-video-ast/README