Raptor Computing Systems Community Forums (BETA)
Software => User Zone => Topic started by: FlyingBlackbird on January 27, 2020, 01:53:31 pm
-
I have installed Ubuntu Server 19.10 with Gnome and lightdm and use the Xorg config from the wiki to enable full HD resolution (https://wiki.raptorcs.com/wiki/Troubleshooting/GPU#Display_stuck_at_default_low_resolution_with_AST_HDMI_GPU).
According to the brief spec (https://www.aspeedtech.com/products.php?fPath=20&rId=440) the AST2500 also supports 1920x1200@60 Hz but I could not successfully enable this resolution.
How do I have to configure Xorg (or is it an error in the spec?)?
My steps tried so far (using the cvt tool to create a modeline for the Xorg.conf and adding this to the Xorg conf file as described in the above link):
# usage: cvt [-v|--verbose] [-r|--reduced] X Y [refresh]
cvt 1920 1200 60
cvt -r 1920 1200 60
cvt 1920 1200 30
I have also added the modeline name to the "modes" line of the display (without success):
Ubuntu is never using this resolution and does also not offer it in the display resolution settings dialog of Gnome.
-
I have found the correct settings now by modiying the xorg.conf from the Raptor wiki just a little bit.
The reason why it didn't work were the conservative HorizSync and VertRefresh settings. After commenting them it did work (at least in Fedora 31)
# AST2500
Section "Device"
Identifier "GPU0"
Driver "modesetting"
BusID "PCI:2@5:0:0"
VendorName "ASpeed Corporation"
EndSection
# configure as appropriate for your monitor -- a standard 1080p screen is assumed below
Section "Monitor"
Identifier "Monitor0"
# HorizSync 30.0-70.0
# VertRefresh 50.0-70.0
Modeline "1920x1080" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync
EndSection
# this is absolutely necessary, it tells xorg which GPU to use for the screen
Section "Screen"
Identifier "Screen0"
Monitor "Monitor0"
Device "GPU0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1920x1080" "1920x1200"
EndSubSection
EndSection
I would be happy if somebody could confirm that these settings are working - I will add them then to the according Raptor wiki page.
-
Sadly, I can't test myself. But on the RCSwiki you could describe how to get the needed modeline using cvt command, modeline calculator or looking into Xorg.0.log for supported resolutions etc..
-
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync
I would be happy if somebody could confirm that these settings are working - I will add them then to the according Raptor wiki page.
It worked until yesterday update (but I think that the Fedora 31 updated just the kernel, not the Xorg?!).
Do you have similar experience?
-
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync
I would be happy if somebody could confirm that these settings are working - I will add them then to the according Raptor wiki page.
It worked until yesterday update (but I think that the Fedora 31 updated just the kernel, not the Xorg?!).
Do you have similar experience?
My Blackbird planar is dead since February (RMA is done but the new planar is still at USPS in the USA due to Corona transportation bottlenecks so I cannot say anything.
I hope your planar is not dead too ;-)
-
It worked until yesterday update (but I think that the Fedora 31 updated just the kernel, not the Xorg?!).
Do you have similar experience?
What's the problem in detail? Does 1080 resolution work?
-
What's the problem in detail? Does 1080 resolution work?
Blank screen, monitor says "no signal". But 1080 works normally (I'm using it now). I had only the 1920x1200 in my Xorg configuration file soi I had to add the 1080 one to see at least something.
Now I have 1920x1080, 1920x1200, 1280x1024 configured (the 1920x are from Raptor Wiki) and I can go to 1280x1024 and back to 1920x1080 but when I trt the 1920x1200 the I got blank the abovementioned blank screen.
-
You could use the cvt command to look if the 1200 modelines has changed.
Otherwise, the Xorg logfile would be useful.
-
I'm sorry for late reply.
My X11 boot to 1920x1080 now. Then I have tried to changer resolution to 1280x1024 (it obviously worked) and then to 1920x1200 (blank screen).
The Xorg log file is (attached).
-
What modelines gives you the cvt command?
-
What modelines gives you the cvt command?
# 1920x1200 59.88 Hz (CVT 2.30MA) hsync: 74.56 kHz; pclk: 193.25 MHz
Modeline "1920x1200_60.00" 193.25 1920 2056 2256 2592 1200 1203 1209 1245 -hsync +vsync
# 1920x1080 59.96 Hz (CVT 2.07M9) hsync: 67.16 kHz; pclk: 173.00 MHz
Modeline "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync
# 1280x1024 59.89 Hz (CVT 1.31M4) hsync: 63.67 kHz; pclk: 109.00 MHz
Modeline "1280x1024_60.00" 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync
-
It should work, I guess. Maybe someone else have a clue.
-
Is there possibly a risk of "overclocking"? Any documentation available that says wrong modelines do not destroy the AST2500?
-
Is there possibly a risk of "overclocking"? Any documentation available that says wrong modelines do not destroy the AST2500?
I don't thing so. I didn't find any such statement.
Moreover, it still works in 1920x1080 (after three months in 1920x1200).
-
I just tried to boot to the "rescue mode" of my Fedora (it is labelled "F30") and ... the 1920x1200 works.
If I boot with the F32 or the F31 kernel (5.6.8 or 5.6.7) then it does not work (1920x1080 is the maximum).
So can it be a kernel issue?
-
Interesting. Would be good to have a xorg log when 1200 is selected.
-
[ 19.961] (II) modeset(0): Disabling kernel dirty updates, not required.
[ 35.360] (II) modeset(0): Allocate new frame buffer 1920x1200 stride
[ 35.362] (EE) modeset(0): failed to set mode: Cannot allocate memory
[ 35.376] (EE) modeset(0): failed to set mode: Invalid argument
-
Looks like a Kernel bug. I got a few Google results.
-
On Debian, 1920x1200 support for the Talos II's AST2500 was broken between Linux 5.5.0-2 and Linux 5.6.0-1. My suspicion is that the breakage is because of Linux commit 9253f830c9166bfa6cc07d5ed59e174e9d5ec6ca. This commit added a VRAM size check to the ast driver, which considers double-buffering as mandatory. 1920x1080 resolution at 4 bytes per pixel with 2 buffers is 16.6 MB, while bumping that to 1920x1200 results in 18.4 MB. According to "lspci -v -s 0005:02:00.0", The Talos II's VRAM size is 16 MiB == 16.8 MB, which explains why 1920x1200 no longer works.
I asked on IRC, and dormito pointed out that the AST2500 supports both 16 MiB and 64 MiB VRAM size, and that in both cases, the VRAM is stolen from the BMC's RAM (512 MiB total). The default configuration is controlled by a hardware pin (no idea why Raptor picked 16 MiB), but dormito thinks it may be possible to reconfigure the AST2500's VRAM size by writing to a register on the BMC (before the host boots).
In the meantime it definitely seems like a Linux bug should be filed about this, since single-buffered 1920x1200 used to work fine but no longer does.
-
I see the same bug on an x86_64 Fedora 36 machine with an ASRock Rack Tommy 90-SC02P1-00UBNZ GPU (AST2510 chipset, 16 MiB VRAM just like the Talos II's AST2500). Kernel 5.5.17-200.fc31.x86_64 works with 1920x1200 on that machine; Kernel 5.6.0-1.fc33.x86_64 does not (maxes out at 1920x1080). That's consistent with the Debian results I got on my Talos II, and with the hypothesis that Linux commit 9253f830c9166bfa6cc07d5ed59e174e9d5ec6ca broke this.
-
Filed a bug with Red Hat, feel free to follow along there: https://bugzilla.redhat.com/show_bug.cgi?id=2136950
-
Filed a bug with upstream dri-devel at Dan Horák's request, feel free to follow along there: https://lists.freedesktop.org/archives/dri-devel/2022-October/377090.html
-
Thanks for doing this.
-
I can confirm that the bug is fixed in the drm-tip branch (as of 2022 November 20), as stated in the linked dri-devel thread. Per the thread, the fix is expected to be released in Linux v6.3.
-
It looks like the fix has successfully advanced from drm-tip to drm-next, and is still on track for Linux 6.3: https://cgit.freedesktop.org/drm/drm/commit/?id=f2fa5a99ca81ce1056539e83c705f3d6bec62e31
I haven't had a chance to test drm-next yet, and probably will not have time to do so before the Linux 6.3 merge window opens in February.
-
Linux v6.3 release candidates are in Fedora Rawhide now, and I can confirm that the bug is fixed there (tested with Linux fedora 6.3.0-0.rc5.20230407gitf2afccfefe7b.46.fc39.ppc64le).
-
Linux v6.3 is now in Fedora stable, and 1920x1200 works fine there. \o/