Opened 13 months ago
Closed 13 months ago
Last modified 13 months ago
#17632 closed bug (fixed)
Freezes/crashes when booting on non-VESA/GOP graphics
|Reported by:||Cacodemon345||Owned by:||rudolfc|
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.
Change History (33)
comment:1 by , 13 months ago
by , 13 months ago
Syslog in question
comment:2 by , 13 months ago
|Component:||- General → Drivers/Graphics/intel_extreme/skylake|
comment:3 by , 13 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 , 13 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 would reside: It should be called intel_extreme, and it should contain one line:
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.
comment:5 by , 13 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 , 13 months ago
comment:6 by , 13 months ago
you can disable SMAP in the boot menu as a workaround until this is corrected.
comment:7 by , 13 months ago
hrev55928 should help with the SMAP warning.
comment:8 by , 13 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 , 13 months ago
yes, already pushed this change
comment:10 by , 13 months ago
Thanks! So, Cacodemon345, please retry with hrev55928 or later..
by , 13 months ago
ROM file of Intel graphics
comment:11 by , 13 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 , 13 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 , 13 months ago
Hi again, If you have a rather new CPU with SMAP/SMEP (I think it's called), you'll need hrev55928 or later. The earlier version crashes to KDL on these systems..
by , 13 months ago
comment:14 by , 13 months ago
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..
comment:15 by , 13 months ago
Yes, changing resolutions works.
comment:16 by , 13 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 , 13 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 , 13 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 , 13 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 , 13 months ago
It's inside the system UEFI/BIOS.
comment:21 by , 13 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 , 13 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 , 13 months ago
Or rather, fiddle with the block above 4g bios setting and see if the driver now just keeps working :-)
comment:24 by , 13 months ago
Yes, it now works.
by , 13 months ago
comment:25 by , 13 months ago
What's the native resolution?
comment:26 by , 13 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 , 13 months ago
|Milestone:||Unscheduled → R1/beta4|
|Status:||new → closed|
comment:28 by , 13 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.
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.