Opened 9 months ago

Closed 9 months ago

Last modified 9 months ago

#17632 closed bug (fixed)

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

Reported by: Cacodemon345 Owned by: rudolfc
Priority: high Milestone: R1/beta4
Component: Drivers/Graphics/intel_extreme/skylake Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

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.

Attachments (5)

IMG_20220305_152946.jpg (4.5 MB ) - added by Cacodemon345 9 months ago.
Syslog in question
IMG_20220307_161610.jpg (4.6 MB ) - added by Cacodemon345 9 months ago.
KDL message
intel_extreme.8086_1912_000200.rom (8.0 KB ) - added by Cacodemon345 9 months ago.
ROM file of Intel graphics
syslog (393.7 KB ) - added by Cacodemon345 9 months ago.
Syslog file
syslog.2 (510.4 KB ) - added by Cacodemon345 9 months ago.
Syslog 2

Change History (33)

comment:1 by Cacodemon345, 9 months ago

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.

by Cacodemon345, 9 months ago

Attachment: IMG_20220305_152946.jpg added

Syslog in question

comment:2 by diver, 9 months ago

Component: - GeneralDrivers/Graphics/intel_extreme/skylake
Owner: changed from nobody to rudolfc

comment:3 by rudolfc, 9 months ago

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!

comment:4 by rudolfc, 9 months ago

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 is: 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!

Version 1, edited 9 months ago by rudolfc (previous) (next) (diff)

comment:5 by Cacodemon345, 9 months ago

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.

by Cacodemon345, 9 months ago

Attachment: IMG_20220307_161610.jpg added

KDL message

comment:6 by korli, 9 months ago

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

comment:7 by korli, 9 months ago

hrev55928 should help with the SMAP warning.

comment:8 by rudolfc, 9 months ago

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

comment:9 by korli, 9 months ago

yes, already pushed this change

comment:10 by rudolfc, 9 months ago

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

by Cacodemon345, 9 months ago

ROM file of Intel graphics

comment:11 by Cacodemon345, 9 months ago

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

comment:12 by rudolfc, 9 months ago

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

comment:13 by rudolfc, 9 months ago

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

Thank you!

Last edited 9 months ago by rudolfc (previous) (diff)

by Cacodemon345, 9 months ago

Attachment: syslog added

Syslog file

comment:14 by rudolfc, 9 months ago

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!

Last edited 9 months ago by rudolfc (previous) (diff)

comment:15 by Cacodemon345, 9 months ago

Yes, changing resolutions works.

comment:16 by rudolfc, 9 months ago

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

comment:17 by rudolfc, 9 months ago

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

comment:18 by Cacodemon345, 9 months ago

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.

comment:19 by rudolfc, 9 months ago

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?

comment:20 by Cacodemon345, 9 months ago

It's inside the system UEFI/BIOS.

comment:21 by Cacodemon345, 9 months ago

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.

comment:22 by rudolfc, 9 months ago

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

comment:23 by rudolfc, 9 months ago

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

comment:24 by Cacodemon345, 9 months ago

Yes, it now works.

by Cacodemon345, 9 months ago

Attachment: syslog.2 added

Syslog 2

comment:25 by korli, 9 months ago

What's the native resolution?

comment:26 by rudolfc, 9 months ago

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

comment:27 by rudolfc, 9 months ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

comment:28 by rudolfc, 9 months ago

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.

Last edited 9 months ago by rudolfc (previous) (diff)
Note: See TracTickets for help on using tickets.