[solved]override width in setfont for consolefont?

[vaxbrat]

TLDR: HDMI cables may screw you on 4k+ panels. Use Displayport instead. END EDIT

I'm trying to get a new system stabilized with a ryzen 1700x and a Gigabyte RX 460 video card. I started with kernel 4.12.5, but that appears to have troubles loading the polaris11 firmware mc bin file when amdgpu is loaded. So it falls back to a standard vesa style framebuffer with a sane looking consolefont.

I unmasked unstable for the gentoo-sources and got and built 4.13.1. That does load amdgpu and firmware but now the console font in the high res text mode looks like garbage since the characters are getting slammed into each other as if the mode width was shorter than what the font was using. I looked into setfont and its man pages suggest

[vaxbrat]

I don't want to try nomodeset for the grub command line args but I did play around with adding things like video=HDMI-A:1280X1024 to it, setting GRUB_GFXMODE to 1280x1024 and GRUB_GFXPAYLOAD_LINUX=keep and then eventually to GRUBGFXPAYLOAD_LINUX=text. The initial boot screen looks like 1280x1024 which would be the limit for a standard VESA video mode. Tweaking the other two affect the intermediate period when the kernel is booting before amdgpu gets loaded and fires up. However after that it would appear that the framebuffer in the virtual consoles goes to 3440x1440 mode, and that's when the console fonts go to hell in a handbasket:

[vaxbrat]

Going back to xorg-server-1.18.4 gets rid of the segfault when I try to Xorg -configure but then it claims that there we have no devices to configure:

[vaxbrat]

From last message at end:

[vaxbrat]

So I had an initial install with a stage 3 minimal tarball from the last few weeks thus using gcc 5.4. Things seemed a little hinky building out because gcc would bomb out on me periodically with a segfault or other apparently random error. Then yesterday I decided to unmask gcc to unstable and got 6.4. Started an emerge -e world and things have been going non-stop since. Today I see the ryzen thread update in the forums and noticed that the first post in the thread mumbled something about missing a couple of instructions versus bulldozer and using gcc 6.x instead. I wonder if this is what was biting me in the posterior all along with the amdgpu heartburn. Film at 11.

[mir3x]

There is another thread - Segfaults during compilation on AMD Ryzen.

https://forums.gentoo.org/viewtopic-t-1061546-highlight-ryzen.html

Basically if your ryzen is produced <= 25 week there is high chance it will segfault, and u will have to RMA it.
Probabaly if u try emerge gcc7.2 10 times in a row and mesa 30 times and it wont segfault u should have good one ( it depends also on bios and kernel settings how often it will occur).
Week info is only on cpu, so no chance to see it without removing fan.

There is also wiki page for ryzen
https://wiki.gentoo.org/wiki/Ryzen
_________________
Sent from Windows

[vaxbrat]

And if you follow those, you would see me talking about that part of the problem. I've gotten one successful round of emerge -e system and emerge -e world out of the way and found that getting rid of the non-zen bulldozer instructions and throttling back to at least -j8 fixes my segfault issue. I just started another round after switching from hdmi to displayport 4k cables during a reboot where I've kicked things back up to -j16.

As for the AMDGPU issue.... it is now happily driving my dell panel over a displayport cable which specifically says 4k res on the package. I could have sworn the hdmi cable I bought way back when was good enough, but you never really know just looking at the shells. So now I know what sort of garbage you get when you try to use a slower hdmi standard cable when trying to drive 4k modes. The console text looks like everything got squashed to the left, and the xorg display pretty much just gives up and goes into power save mode, never to return.