Freezes/crashes when booting on non-VESA/GOP graphics

[Cacodemon345]

When attempting to boot Haiku x86_64 hrev55923 on UEFI, I can't seem to get into the desktop.

These are my results so far: Both AMD Radeon RX 460 and Intel HD Graphics 530 enabled: Freezes in the boot screen right when it is supposed to load the desktop.

Intel HD Graphics 530 as primary boot device (AMD still enabled): Same result.

Only AMD Radeon RX 460 enabled: Crashes into the debugger, attempts to get a backtrace are unsuccessful because the debugger just freezes when attempting to do so.

I haven't tried to boot with GOP fallback on nor did I try booting with CSM on with VESA graphics yet.

[Cacodemon345]

GOP works.

Enabling debug onscreen output reveals that the driver freezes after failing to find any displays despite one being connected when attempting to get a frame buffer configuration.

[Cacodemon345]

Syslog in question

[rudolfc]

Thank you! From the looks of it the hardware is not responding.. There is another ticket with the same problem, I don't know howto fix it yet.

If I find out more, I'll let you know!

[rudolfc]

Oh, btw, last night I did a commit which should at least let the driver find the native internal panel's modeline, that is, if we are talking about a laptop (are we?).

In that case please try hrev55927 since from now on, it might well be you'll boot to the desktop even though the hardware does not respond, as the deskop will then be in the same mode as you have booted in (I expect).

Modesetting won't work however, except just maybe colordepth changes. If you get a desktop I would be interested to know if GLTeapot spins for you at 60Hz as well.

Please upload a syslog if you can: also upload the intel_extremexxxx.rom file from your home folder if you can (create a file in home/config/settings/kernel/drivers, where also the vesa file would reside: It should be called intel_extreme, and it should contain one line:

dump_rom true

After a reboot the kerneldriver will create a file in your home folder, I expect you will be able to grab it and upload it.

Thank you!

[Cacodemon345]

Now the system crashes into the KDL when booting, so I can't get either the syslog (especially since I don't have any serial outputs hooked up) or the ROM.

[Cacodemon345]

KDL message

[korli]

you can disable SMAP in the boot menu as a workaround until this is corrected.

[korli]

hrev55928 should help with the SMAP warning.

[rudolfc]

Ah, should the mapping use B_KERNEL_READ_AREA instead of B_READ_AREA @Korli? I see the crash happens upon access to the mapped memory..

[korli]

yes, already pushed this change

[rudolfc]

Thanks! So, Cacodemon345, please retry with hrev55928 or later..

[Cacodemon345]

ROM file of Intel graphics

[Cacodemon345]

Can confirm it at least boots to the desktop. GLTeapot spins at 60Hz as well. Still on hrev55927 with SMAP disabled.

[rudolfc]

Nice! That means the interrupt structures are running OK as well. Can you also upload a syslog? (/var/log/syslog file)

I'd like to see the details of the driver's behaviour :-)

[rudolfc]

hmm.. ok, wrong ticket ;-) Please upload a syslog as mentioned just now,

Thank you!

[Cacodemon345]

Syslog file

[rudolfc]

Hello again,

Well, this is interesting. Now the hardware -is- responding. I wonder what happened in between.. It wasn't me! :-) (you can recognize this by the content of tra. trb and trc (if I have the names right): these were all 'fffffff's (generally means: nothing's there, nothings connected) and now I have a real valid content. Might it have something todo with which gfx card you had enabled upon boot?

Anyhow, we are way further on route now indeed, though there's still possibly an error. That is: Please try to set a number of resolutions to see if that works? Could be all is ok now..

Thank you!

[Cacodemon345]

Yes, changing resolutions works.

[rudolfc]

Ah, very nice!

So, if I understand you correctly, all problems are solved with the driver now? If so, we can close this ticket. If there's still an open issue of which I am unaware in that case, what is it?

Thanks again :-)

[rudolfc]

Oh, any idea on what might have fixed the 'no register access' problem on your system? (something with boot graphics card selection or so?)

Any pointer you might have is appreciated :-)

[Cacodemon345]

Turns out that if I enable the Above 4G decoding option in the firmware PCIe configuration menu, the problem will resurface.

So it looks like Haiku hates the Above 4G decoding option.

[rudolfc]

Hi, Well, this is some important observation indeed. I'll dive into this specific subject concerning the intel graphics cards and get back at you! I am assuming, that is, that you mean above 4Gbyte memory. Is this option inside the system (UEFI)BIOS? or in bootoptions menu from Haiku?

[Cacodemon345]

It's inside the system UEFI/BIOS.

[Cacodemon345]

If I enable both the Above 4G decoding option from the firmware and the option to ignore all memory beyond 4GB in the Haiku boot loader, it will boot successfully but the output will be stuck in the pre-desktop screen while everything else (including keyboard and the machine power button to shut down) will work.

[rudolfc]

Hi, so I determined it's the BAR's: they are 64bit instead of 32. I have been testing with modified intel_gart and intel_Extreme driver. But I don't need to commit as:

Hmm, and I'm bypassed I see ;-) You can check tommorrow's nighty as Jerome Duval just added the same extensions as I did.

please test hrev55946 or later and upload a new syslog!

Thank you :-)

[rudolfc]

Or rather, fiddle with the block above 4g bios setting and see if the driver now just keeps working :-)

[Cacodemon345]

Yes, it now works.

[Cacodemon345]

Syslog 2

[korli]

What's the native resolution?

[rudolfc]

Hi, well, that's nice!

@Korli: this system is OK, including native resolution wise if all is right. Otherwise there probably would not be a working screen yet. On all those systems where the VBT info is wrong you'll notice that, and -if- this info is wrong, it doesn't help to manually 'force' native resolution via bootmenu, vesa file or app_server since the settings done by the driver will be wrong per definition.

Next up should be finding a solution for the VBT trouble on some systems. That being said, if you start to look for it, you'll see that on Linux this problem exists as well sometimes, and people are even flashing BIOSes in this respect to get around that AFAICT.

While searching the net I more or less came to the conclusion already we're doing nothing wrong here in where we fetch the modeline info. Things that might help:

• add more EDID fetch stuff for internal panels: routing could be fetched from the OpRegion instead of how we are doing it now (a lot of rework of which I think I'll postpone it a bit)
• add a fallback (or rather: first action):
• that searches for the modeline inside gfx card's registers and use that instead of VBT info,
• unless it cannot be determined, in that case use VBT from OpREgion,
• with as a fallback fetch that from BIOS.

For this ticket: closing ticket as problem is solved. IF I shouldn't have done that feel free to re-open it!

Cacodemon345, thanks a lot for your help here :-)

[rudolfc]

Oh, BTW: the modeline VBT info in OpRegion or BIOS is -only- valid on mobile systems 'per definition' (see intel doc). The definition is that there -must- be a modeline, even if there is no panel, though not all BIOSes respect that demand. a fake panel of 1024x768 is quite commonly found on desktop systems.