Opened 22 months ago

Last modified 4 months ago

#16463 new bug

app_server: Use 2576x1118 (8) instead

Reported by: yangh Owned by: axeld
Priority: normal Milestone: Unscheduled
Component: Servers/app_server Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #14302, #15060, #16992, #17201, #17424
Platform: All

Description (last modified by 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

Attachments (11)

stuck-on-splash.jpg (1.4 MB ) - added by yangh 22 months ago.
log-on-screen.jpg (4.0 MB ) - added by yangh 22 months ago.
enabled-fail-safe-graphics-driver.jpg (2.9 MB ) - added by yangh 22 months ago.
Samiliar error printed on screen even enabled fail safe graphics driver
haiku-envy-x360-modes-dump.jpeg (1.4 MB ) - added by yangh 20 months ago.
radeon-hd-add-renoir-1636.patch (649 bytes ) - added by yangh 20 months ago.
Add device id for Radeon Renoir 1636 in Ryzen 2
IMG_20200930_223613R.jpg (2.9 MB ) - added by yangh 20 months ago.
radeon_hd driver starts to work after Add device id for Radeon Renoir 1636 in Ryzen 2
IMG_20200930_223619R.jpg (3.4 MB ) - added by yangh 20 months ago.
radeon_hd driver PANIC in radeon_hd_init()
IMG_20201001_210238R.jpg (2.4 MB ) - added by yangh 20 months ago.
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.
IMG_20201001_220321R.jpg (2.1 MB ) - added by yangh 20 months ago.
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.
syslog55780 (184.8 KB ) - added by pragmavalue 5 months ago.
syslog.zip (128.0 KB ) - added by dpirate 4 months ago.

Change History (39)

by yangh, 22 months ago

Attachment: stuck-on-splash.jpg added

by yangh, 22 months ago

Attachment: log-on-screen.jpg added

comment:1 by yangh, 22 months ago

Description: modified (diff)

comment:2 by waddlesplash, 22 months ago

Component: - GeneralServers/app_server
Owner: changed from nobody to axeld

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

by yangh, 22 months ago

Samiliar error printed on screen even enabled fail safe graphics driver

in reply to:  2 comment:3 by yangh, 22 months ago

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?

comment:4 by yangh, 22 months ago

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

comment:5 by waddlesplash, 22 months ago

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.

comment:6 by MelanieFox, 20 months ago

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.

comment:7 by pulkomandy, 20 months ago

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.

in reply to:  7 comment:8 by yangh, 20 months ago

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

comment:9 by pulkomandy, 20 months ago

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.

comment:10 by yangh, 20 months ago

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

comment:11 by MelanieFox, 20 months ago

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.

in reply to:  11 comment:12 by pulkomandy, 20 months ago

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.

comment:13 by MelanieFox, 20 months ago

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.

comment:14 by pulkomandy, 20 months ago

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?

comment:15 by waddlesplash, 20 months ago

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

by yangh, 20 months ago

Add device id for Radeon Renoir 1636 in Ryzen 2

by yangh, 20 months ago

Attachment: IMG_20200930_223613R.jpg added

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

by yangh, 20 months ago

Attachment: IMG_20200930_223619R.jpg added

radeon_hd driver PANIC in radeon_hd_init()

comment:16 by MelanieFox, 20 months ago

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)

comment:17 by yangh, 20 months ago

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

by yangh, 20 months ago

Attachment: IMG_20201001_210238R.jpg added

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.

comment:18 by pulkomandy, 20 months ago

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).

by yangh, 20 months ago

Attachment: IMG_20201001_220321R.jpg added

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.

comment:19 by diver, 7 months ago

Summary: HP Envy x360 2020 AMD Ryzen R4 4700 supportapp_server: Use 2576x1118 (8) instead

comment:20 by diver, 6 months ago

Blocking: 16992 added

comment:21 by diver, 6 months ago

Blocking: 17201 added

comment:22 by diver, 6 months ago

Blocking: 17424 added

comment:23 by diver, 6 months ago

Blocking: 15060 added

comment:24 by diver, 6 months ago

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

Last edited 6 months ago by diver (previous) (diff)

comment:25 by diver, 5 months ago

Blocking: 14302 added

by pragmavalue, 5 months ago

Attachment: syslog55780 added

comment:26 by dpirate, 4 months ago

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.

comment:27 by korli, 4 months ago

dpirate, please attach a syslog

by dpirate, 4 months ago

Attachment: syslog.zip added

comment:28 by dpirate, 4 months ago

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.

Note: See TracTickets for help on using tickets.