Project

General

Profile

Actions

Bug #13774

open

[OpenIndiana Hipster 2021.04] Slow then unusable video after startup menu on 2012 Mac mini

Added by Will B 4 days ago. Updated 1 day ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
video, intel
Gerrit CR:

Description

When attempting to use Hipster 2021.04 Live USB on a 2012 Mac mini, the initial boot menu draws very slowly (you can see the line art drawing ever so slowly, line over line). After what seems to be about 30 seconds, you then can press Enter to boot.

The messages " Loading unix... " to " Booting... " display correctly, but then the video appears to change modes and all new video output appears to be squashed vertically and repeated. It is completely unreadable.

I have enabled 'VESA driver' in the boot options, but this made no difference.

(Video captures and dmesg will be added soon.)

The Mac mini I'm using has the following specs:
- - -
  • Processor: 2.3 GHz Intel Core i7
  • Graphics: Intel HD Graphics 4000 1536 MB
  • Memory: 16 GB

Thank you!

Actions #2

Updated by Toomas Soome 3 days ago

Will B wrote in #note-1:

Video of issue:
https://www.pismotek.com/media/OpenIndiana-2021-04-Mac-mini-video-problem.mp4

Screenshots of issue:

if you press esc on boot menu and on OK prompt enter: set console=text - does it fix the screen draw?

For corruption; the big question is, why there is a change in gfx mode... obviously this does not update the gfx state and therefore we do get messy screen.

Actions #3

Updated by Will B 3 days ago

if you press esc on boot menu and on OK prompt enter: set console=text - does it fix the screen draw?

For corruption; the big question is, why there is a change in gfx mode... obviously this does not update the gfx state and therefore we do get messy screen.

Hello Toomas,

I just tried set console=text and boot and the corruption still exists.

Thanks! :-)

Actions #4

Updated by Toomas Soome 3 days ago

Will B wrote in #note-3:

if you press esc on boot menu and on OK prompt enter: set console=text - does it fix the screen draw?

For corruption; the big question is, why there is a change in gfx mode... obviously this does not update the gfx state and therefore we do get messy screen.

Hello Toomas,

I just tried set console=text and boot and the corruption still exists.

Thanks! :-)

Yes, we did not thing about the corruption; but the question is, after this command, is the screen draw ok?

is this UEFI boot or BIOS (bootcamp?)? also, can you paste output from: framebuffer get

Actions #5

Updated by Will B 3 days ago

Yes, we did not thing about the corruption; but the question is, after this command, is the screen draw ok?

To me, what you are asking is the same, so I apologize. After doing the set console=text and boot everything after the boot message is corrupted. If you are asking about the line drawing around the boot menu, pressing Esc does not take effect until after the line drawing completes.

is this UEFI boot or BIOS (bootcamp?)?

This is UEFI booting.

also, can you paste output from: framebuffer get

I have tried to type it correctly below, but see the picture for actual output.

ok framebuffer get
Framebuffer mode: on
EDID 1920x1200 1680x1050 1280x1024 1440x900 1280x960 1280x800 1280x720
GOP mode 0: 1920x1200x32, stride=1920
    frame buffer: address=90000000, size=8ca000
    color mask: R=00ff0000, G=0000ff00, B=000000ff
ok

Thank you! :-)

Actions #6

Updated by Toomas Soome 3 days ago

Will B wrote in #note-5:

Yes, we did not thing about the corruption; but the question is, after this command, is the screen draw ok?

To me, what you are asking is the same, so I apologize. After doing the set console=text and boot everything after the boot message is corrupted. If you are asking about the line drawing around the boot menu, pressing Esc does not take effect until after the line drawing completes.

right, yes, once you set console, type menu to get menu up again:D

is this UEFI boot or BIOS (bootcamp?)?

This is UEFI booting.

also, can you paste output from: framebuffer get

I have tried to type it correctly below, but see the picture for actual output.

[...]

Thank you! :-)

nothing too obvious there. Can you experiment with other modes? framebuffer list will show the alternates.

There is one more thing you can test, if you enter: boot -B prom_debug=true,kbm_debug=true

This will print out lot of lines from dboot and then early kernel; my guess is, the dboot part will be OK and we get corruption later.

Actions #7

Updated by Will B 3 days ago

Toomas Soome wrote in #note-6:

right, yes, once you set console, type menu to get menu up again:D

Oh, okay. Thanks for your patience. I tried this after setting the console=text and the line drawing was still very slow.

nothing too obvious there. Can you experiment with other modes? framebuffer list will show the alternates.

I will have to do this after work as I need to work right now. :)

There is one more thing you can test, if you enter: boot -B prom_debug=true,kbm_debug=true

Here is the video with the output of that command (sorry, cannot type the hundreds of lines ;) ):

https://www.pismotek.com/media/OpenIndiana-2021-04-Mac-mini-video-problem-02.mp4

Here is the last part of the output, right before the mode seems to change and there's corruption:

Thank you! :)

Actions #8

Updated by Toomas Soome 3 days ago

Will B wrote in #note-7:

Toomas Soome wrote in #note-6:

right, yes, once you set console, type menu to get menu up again:D

Oh, okay. Thanks for your patience. I tried this after setting the console=text and the line drawing was still very slow.

OK, the problem there is that we are drawing line by pixels, seems we should optimize this to put more data on screen at a time...

nothing too obvious there. Can you experiment with other modes? framebuffer list will show the alternates.

I will have to do this after work as I need to work right now. :)

There is one more thing you can test, if you enter: boot -B prom_debug=true,kbm_debug=true

Here is the video with the output of that command (sorry, cannot type the hundreds of lines ;) ):

not expecting that:D

https://www.pismotek.com/media/OpenIndiana-2021-04-Mac-mini-video-problem-02.mp4

Here is the last part of the output, right before the mode seems to change and there's corruption:

Thank you! :)

Yea, I do not think there is mode switch happening, there is nothing to perform such switch:D but seems like some sort of memory mapping issue. We are drawing screen just fine till gfx_private is loaded to draw the console... or so it seems.

Actions #9

Updated by Will B 2 days ago

Toomas Soome wrote in #note-8:

Yea, I do not think there is mode switch happening, there is nothing to perform such switch:D but seems like some sort of memory mapping issue. We are drawing screen just fine till gfx_private is loaded to draw the console... or so it seems.

Tonight I tried every framebuffer mode listed when I issue: framebuffer get but all it would do is clear the screen. Then, when booting, the corruption would happen as before. The mode did not seem to change at all when I would try different modes, just clear the screen. The only thing that made a difference is if I issued: framebuffer off then it would change and everything was in the center of the screen with a different font, but when it continued booting, the text was output in the same old spot as before and became corrupted.

A long time ago I heard about a 'keep' command or keyword for keeping the UEFI resolution during boot, but I don't know where to set this and don't even know if it's possible. It might be a grub-only thing. Also my mini was running very hot while I tried these debugging things, so maybe it's just not possible to run OI on here? That's too bad -- I really like OI when I can get it to run.

Thanks! :-)

Actions #10

Updated by Toomas Soome 2 days ago

Will B wrote in #note-9:

Toomas Soome wrote in #note-8:

Yea, I do not think there is mode switch happening, there is nothing to perform such switch:D but seems like some sort of memory mapping issue. We are drawing screen just fine till gfx_private is loaded to draw the console... or so it seems.

Tonight I tried every framebuffer mode listed when I issue: framebuffer get but all it would do is clear the screen. Then, when booting, the corruption would happen as before. The mode did not seem to change at all when I would try different modes, just clear the screen. The only thing that made a difference is if I issued: framebuffer off then it would change and everything was in the center of the screen with a different font, but when it continued booting, the text was output in the same old spot as before and became corrupted.

A long time ago I heard about a 'keep' command or keyword for keeping the UEFI resolution during boot, but I don't know where to set this and don't even know if it's possible. It might be a grub-only thing. Also my mini was running very hot while I tried these debugging things, so maybe it's just not possible to run OI on here? That's too bad -- I really like OI when I can get it to run.

Thanks! :-)

Can you test with FreeBSD 13 or FreeBSD current (14), does its kernel get the corruption too?

Actions #11

Updated by Will B 2 days ago

Toomas Soome wrote in #note-10:

Can you test with FreeBSD 13 or FreeBSD current (14), does its kernel get the corruption too?

I tried with FreeBSD 13:
  • When choosing the 'EFI boot' item it took a very long time to get to the boot menu, and the line drawing was dreadfully slow, just like on OI, so it appears to be an upstream issue. When I booted, it took a while, but there was no corruption -- all text wrote to the screen properly.
  • When choosing the 'Windows' (non-EFI?) boot item, everything was as expected -- the boot menu wrote normally to the screen (no slowness) and it booted fine without corruption.

Thank you! :-)

Actions #12

Updated by Toomas Soome 1 day ago

Will B wrote in #note-11:

Toomas Soome wrote in #note-10:

Can you test with FreeBSD 13 or FreeBSD current (14), does its kernel get the corruption too?

I tried with FreeBSD 13:
  • When choosing the 'EFI boot' item it took a very long time to get to the boot menu, and the line drawing was dreadfully slow, just like on OI, so it appears to be an upstream issue. When I booted, it took a while, but there was no corruption -- all text wrote to the screen properly.

yea, the upstream in this case is illumos:D but that slowness was expected. but it is good to know, the VT driver does not corrupt the screen in your case.

  • When choosing the 'Windows' (non-EFI?) boot item, everything was as expected -- the boot menu wrote normally to the screen (no slowness) and it booted fine without corruption.

Thank you! :-)

thanks.

Actions

Also available in: Atom PDF