app_server: Use 2576x1118 (8) instead

[yangh]

I'm trying to install Haiku into my new laptop, HP Envy x360 2020 AMD Ryzen R5 4700 + Radeon graphics card + 8G RAM.

I flashed the Nightly build 54487 into a USB 2.0 stick drive, disabled the secure boot in the BIOS, and the laptop booted into Haiku on the USB stick, but it stuck at the bootsplash and never show the desktop. USB 3.0 stick drive doesn't work neither.

I captured an image after enabled the debug log on screen. Please help to check what happened, if any new log needed, I can try to obtain more logs from the laptop.

Thanks

[waddlesplash]

Can you try enabling "use fail safe video mode" in the bootloader? This may be an appserver bug however...

[yangh]

Samiliar error printed on screen even enabled fail safe graphics driver

[yangh]

Replying to waddlesplash:

Can you try enabling "use fail-safe video mode" in the bootloader? This may be an appserver bug however...

The log shows that no supported devices found for both radeon_hd/i810 driver, then vesa init succeeded.

Does the 2576x1118 resolution mater?

[yangh]

Hi Wad/axeld Any suggestion for debugging? Can I add some debug info and build a new hpkg to replace which one in USB stick, then boot the laptop with this USB stick for debugging?

Thanks Walter

[waddlesplash]

I use Haiku with a 4K resolution larger than that, so it should not be a problem for app_server. I guess you can try a lower one and see if something different happens.

[MelanieFox]

One Problem with Ryzens especially zen2 is a cpu bug when using vm8086 mode which the vesa driver relies on.

The only time Haiku ran on my baremetal way way ago when the radion drivers still worked and the efi framebuffer driver was responsible for splash.

i don't know if it helps or what happens then, but maybe you could try the don't call the bios option.

[pulkomandy]

That video resolution of 2576x1118 seems a bit strange. There is another reference to it in #15036 but it seems to not be a standard one. A Google search shows some pages saying that would be the total horizontal/vertical sizes for a 1080p display (including hsync/vsync, porch and border areas). It is also strange that app_server is trying to use an 8bpp (256 colors) mode instead of 32bpp.

So it looks like we end up using the wrong part of the timing infos, or somehow what we get from VESA in terms of available video mode is not handled correctly.

I think it would help if you could share pictures of earlier screens in the boot log, in particular, near the start of the log, the VESA driver will dump the list of available video modes.

[yangh]

Replying to pulkomandy:

So it looks like we end up using the wrong part of the timing infos, or somehow what we get from VESA in terms of available video mode is not handled correctly.

I've set up a virtual box env and succeeded to build Haiku x86_64 any boot iso, I can add some debug info into the VESA driver or app_server now.

How can I replace the haiku kernel? is it as easy as replacing the haiku_r1beta...hpkg in system/packages? I would like to replace some packages in the USB stick instead of flashing the iso for each updating.

I think it would help if you could share pictures of earlier screens in the boot log, in particular, near the start of the log, the VESA driver will dump the list of available video modes.

I enabled debug message on screen and disabled paging, then I check the logs on-screen line by line. There is no more message from VESA driver beside the Attachment: log-on-screen.jpg.

Thanks

[pulkomandy]

Yes, you can simply replace the haiku package for testing a new version.

I guess it makes sense that the early logs from the vesa driver won't get to the on screen debug since they are logged before the screen is set up.

You may be able to enter KDL (alt + printscreen + d) and use the syslog command there to get the early part of the syslog, where the info should be available.

[yangh]

I've dumped modes returned from fHWInterface->GetModeList(&modes, &count),

status_t Screen::SetBestMode(uint16 width, uint16 height, uint32 colorSpace,

float frequency, bool strict)

{

search for a matching mode display_mode* modes = NULL; uint32 count; status_t status = fHWInterface->GetModeList(&modes, &count);

Please refer to the haiku-envy-x360-modes-dump.jpeg​, the output shows that there are two mode available, both are 1920x1080, so could not matches 1024x768 or 800x600 from:

VirtualScreen::AddScreen(Screen* screen, ScreenConfigurations& configurations) {

screen_item* item = new(std::nothrow) screen_item; if (item == NULL)

return B_NO_MEMORY;

item->screen = screen;

status_t status = B_ERROR;

...

if (status != B_OK) {

status_t status = screen->SetPreferredMode(); if (status != B_OK)

status = screen->SetBestMode(1024, 768, B_RGB32, 60.f);

if (status != B_OK)

status = screen->SetBestMode(800, 600, B_RGB32, 60.f, false);

if (status != B_OK) {

debug_printf("app_server: Failed to set mode: %s\n",

strerror(status));

}

Then, I added a new mode before 1024x768:

if (status != B_OK)

status = screen->SetBestMode(1920, 1080, B_RGB32, 60.f);

Then it matched, but I still can't see the desktop, and the boot process stopped at the red rocket which is the same as before, the on-screen debug message stopped after the new mode matched.

Why haiku_loader could display normally and also the splash screen? Any suggestions for the next step?

Since this is a brand new CPU and GPU (embedded in the SoC), should I try to hack the Radeon driver?

Thanks Walter

[MelanieFox]

Maybe you could try to peek how Linux does this. What irritates me is that radeon_hd should be responsible as far as i know thats the driver for far older models and radeon driver should be in charge.

Hopefully you stumble about some solutions, And maybe the even help me out.

[pulkomandy]

Replying to MelanieFox:

What irritates me is that radeon_hd should be responsible as far as i know thats the driver for far older models and radeon driver should be in charge.

?

radeon is the driver for older cards (radeon 7000 and 9250, that kind of things from the early 2000s) and radeon_hd is for the new ones.

Anyway, app_server will just try all accelerants when starting, until one finds that a matching driver is loaded, and use vesa/frambuffer if no driver is loaded. So it's not unexpected to get logs from all the accelerants as this is done during init.

In this case here the card is probably too new and not handled yet by the radeon_hd driver. And so we try vesa/framebuffer but we are not too succesful with that either.

[MelanieFox]

Okay. Thx. for the elaboration. So it's basically the other way around like

with Linux and such.

Well vesa with it's bios and vm86 Calls is a culprit since zen1 arch.

Don' expect to get meaningfull or correct data at all Times.

You might be lucky or not. Vesa on zen x works in virtualbox, vmware as lang as the fake resonable results, which they can with hostos data and never enter vm86 mode.

Vesa fb on linux on baremetal is also impossible for me. Pagefaults, Triple-Faults or obviously stupid data.

Stack corruptions... Well the CPU just don't behaves like specified.

An AGESA Update solves this problem. But only for WinXP +, BSD 10 Series, Linux 4.10+

For what reason ever getting the e820 map works pretty good. Most Times.

Maybe you could have this in mind.

Also an Intel CPU wothout that Bug and AmD graphics works like a Charme.

AMD only stated its possible to worl around via Software.

Most solutions avoid the Bug by stubbing vm86 or never ever even need this.

[pulkomandy]

On 64bit Haiku we don't use vm86. We run the VESA BIOS inside a software emulator already. Does 32 vs 64bit Haiku make a difference then?

[waddlesplash]

No, we do the same on 32bit; VM86 support was completely removed from the kernel years ago.

[yangh]

Add device id for Radeon Renoir 1636 in Ryzen 2

[yangh]

radeon_hd driver starts to work after Add device id for Radeon Renoir 1636 in Ryzen 2

[yangh]

radeon_hd driver PANIC in radeon_hd_init()

[MelanieFox]

Weird. Could you check if there is some mtrr dump Debugger command? (Type help)

Maybe there are too many drivers using mtrr's insteat of Page Table Attributes and your CPU doesn't have enough of them?

I guess the panic occured when radeon_hd mapped the framebuffer and instructed the vm manager to set it to write combine via mtrr.

(topic vesa: sorry looked into the wrong source files. boot/vesa instead of the kernel driver)

[yangh]

It seems that the last range with size 0x80000 (512M? 512K?) could not be set as MTRR.

[yangh]

Added a while(true); before the panic()at arch/x86/arch_vm.cpp, enabled arch vm trace so we have more log in the screen.

[pulkomandy]

The MTRR problems are already mentionned in #5353 but from my understanding the only downside (for the use in graphics, at least) is that write combining will not be enabled, resulting in slow framebuffer). Is the panic continuable? (by just typing "continue" or "co" at the KDL prompt).

In that other ticket, there are discussions for using other mechanisms on Pentium 3 and later. Maybe it's time we start considering to use these. But in the meantime, from your logs, I'd say the setup could be improved as documented in that ticket (using a more complex but more intelligent combination of MTRR entries to achieve what we want).

[yangh]

As you said, The mtrr error could be ignored. Now it runs in to a new issue, atom bios on the gpu is not found.

[diver]

From #15060 it looks like enabling CSM could be a workaround.

[dpirate]

I have the same problem with a Radeon HD 6670 + 4K 27" LG screen. Haiku boots and then I get a black screen instead of the desktop. Enabling failsafe VGA works. The same card used to work fine with a Samsung Full HD 27" screen which was replaced with the LG 4K one.

[korli]

dpirate, please attach a syslog

[dpirate]

As I didn't know which syslog file is needed exactly I attached a zip file with everything that is in /var/log after reproducing the bug and restarting in failsafe mode.