Software > User Zone

Configure Xorg for AST2500 max resolution of 1920x1200 on Ubuntu Server 19.10

<< < (4/6) > >>

MPC7500:
Interesting. Would be good to have a xorg log when 1200 is selected.

jirka:

--- Code: ---[    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
--- End code ---

MPC7500:
Looks like a Kernel bug. I got a few Google results.

JeremyRand:
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.

JeremyRand:
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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page