illumos gate

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

Screenshots of issue:

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.

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

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

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

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.

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

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.

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

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?

Toomas Soome wrote in #note-10:

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

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

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.

Just as another data point -- I am able to boot Tribblix, and even install it -- without video corruption, although the line drawing for the menu is painfully slow.

Thanks! :-)

Will B wrote in #note-14:

Just as another data point -- I am able to boot Tribblix, and even install it -- without video corruption, although the line drawing for the menu is painfully slow.

Thanks! :-)

please post output from prtvonf -vd

Also, if you do not mind to try the very latest omnios or smartos boot image, just to get confirmation this is openindiana issue.

Will B wrote in #note-16:

Toomas Soome wrote in #note-15:

please post output from prtvonf -vd

I tried the above command, but it didn't work. I thought maybe you meant 'prtconf' so I attached the output of that to this message.

Thanks! :-)

indeed, I meant prtconf. thanks.

Toomas Soome wrote:

Also, if you do not mind to try the very latest omnios or smartos boot image, just to get confirmation this is openindiana issue.

• The latest OmniOS behaved exactly like OI: slow menu line drawing and corrupted video after 'Booting...' message

• The latest SmartOS worked: The menu line drawing was instantaneous (although the corners drew slowly) and the video never became corrupted after boot messages.

Thanks Toomas! :-)

Will B wrote in #note-18:

Toomas Soome wrote:

Also, if you do not mind to try the very latest omnios or smartos boot image, just to get confirmation this is openindiana issue.

• The latest OmniOS behaved exactly like OI: slow menu line drawing and corrupted video after 'Booting...' message

• The latest SmartOS worked: The menu line drawing was instantaneous (although the corners drew slowly) and the video never became corrupted after boot messages.

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

BTW, I tried OI and omniOS and saw the same corupt screen behavior so switched to SmartOS.

Thanks in advance for any advice.

Rasaki

Thanks Toomas! :-)

Rasaki Temidire wrote in #note-19:

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

Greetings!

I was never able to get any distro using Illumos working on my 2012 mini. I no longer use a mini and instead have moved to a newer Intel Mac. No, while OI booted farther and didn't have graphical corruption, it died into maintenance mode and never completed boot on this newer Mac. (sigh)

Will B wrote in #note-20:

Rasaki Temidire wrote in #note-19:

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

Greetings!

I was never able to get any distro using Illumos working on my 2012 mini. I no longer use a mini and instead have moved to a newer Intel Mac. No, while OI booted farther and didn't have graphical corruption, it died into maintenance mode and never completed boot on this newer Mac. (sigh)

Thanks for the quick reply Will. It's good to know that someone is out there trying this stuff on this hardware. It would be a shame if it didn't work in the end. I will try SmartOs and OI on a MacBook Pro 2014 later today and see if that works without any Ethernet issues. I like the hardware but MacOS with openZFS doesn't have the great built in SMB and NFS as first class citizens concept like illumos does. Sigh indeed.

Rasaki

Rasaki Temidire wrote in #note-21:

Will B wrote in #note-20:

Rasaki Temidire wrote in #note-19:

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

Greetings!

I was never able to get any distro using Illumos working on my 2012 mini. I no longer use a mini and instead have moved to a newer Intel Mac. No, while OI booted farther and didn't have graphical corruption, it died into maintenance mode and never completed boot on this newer Mac. (sigh)

Thanks for the quick reply Will. It's good to know that someone is out there trying this stuff on this hardware. It would be a shame if it didn't work in the end. I will try SmartOs and OI on a MacBook Pro 2014 later today and see if that works without any Ethernet issues. I like the hardware but MacOS with openZFS doesn't have the great built in SMB and NFS as first class citizens concept like illumos does. Sigh indeed.

Rasaki

I myself do not have no access to mini, so I can not experiment with it myself. But I can help with consulting and such -- if there is an interest.

Toomas Soome wrote in #note-22:

Rasaki Temidire wrote in #note-21:

Will B wrote in #note-20:

Rasaki Temidire wrote in #note-19:

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

Greetings!

I was never able to get any distro using Illumos working on my 2012 mini. I no longer use a mini and instead have moved to a newer Intel Mac. No, while OI booted farther and didn't have graphical corruption, it died into maintenance mode and never completed boot on this newer Mac. (sigh)

Thanks for the quick reply Will. It's good to know that someone is out there trying this stuff on this hardware. It would be a shame if it didn't work in the end. I will try SmartOs and OI on a MacBook Pro 2014 later today and see if that works without any Ethernet issues. I like the hardware but MacOS with openZFS doesn't have the great built in SMB and NFS as first class citizens concept like illumos does. Sigh indeed.

Rasaki

I myself do not have no access to mini, so I can not experiment with it myself. But I can help with consulting and such -- if there is an interest.

Thanks for the offer Toomas but this is just a home project so I can't incur any consulting fees. I will have to start searching for issues with the illumos bge driver and see if anyone has found tools for diagnosing the slowness and intermittent connectivity. All I know for sure now is that iper3 tests show that traffic is running to and from the internet but drops to 0 bytes between bursts.

Rasaki Temidire wrote in #note-23:

Toomas Soome wrote in #note-22:

Rasaki Temidire wrote in #note-21:

Will B wrote in #note-20:

Rasaki Temidire wrote in #note-19:

Will and Toomas, Thanks for this discussion. I was able to get the latest SmartOS (20220310) running on my Mac Mini 2014 but the ethernet (bge0) seems to be working intermittently. It will start transfers from SmartOS or through iperf3 quickly then drop off to sending 0 bytes and then ramp up again and drop off again. Did either of you notice this behaviour and know why it might be happening and how I can get around it. Otherwise, having a smoothly running SmartOS for ZFS and zones on a repurposed Mac Mini would be great!

Greetings!

I was never able to get any distro using Illumos working on my 2012 mini. I no longer use a mini and instead have moved to a newer Intel Mac. No, while OI booted farther and didn't have graphical corruption, it died into maintenance mode and never completed boot on this newer Mac. (sigh)

Thanks for the quick reply Will. It's good to know that someone is out there trying this stuff on this hardware. It would be a shame if it didn't work in the end. I will try SmartOs and OI on a MacBook Pro 2014 later today and see if that works without any Ethernet issues. I like the hardware but MacOS with openZFS doesn't have the great built in SMB and NFS as first class citizens concept like illumos does. Sigh indeed.

Rasaki

I myself do not have no access to mini, so I can not experiment with it myself. But I can help with consulting and such -- if there is an interest.

Thanks for the offer Toomas but this is just a home project so I can't incur any consulting fees. I will have to start searching for issues with the illumos bge driver and see if anyone has found tools for diagnosing the slowness and intermittent connectivity. All I know for sure now is that iper3 tests show that traffic is running to and from the internet but drops to 0 bytes between bursts.

nono, I did not mean any fees, just that without an access to hw, I can only try to give some advice what to check and such. From screenshots above, we can see the early kernel can output on console just fine, so it would be a question, what is different when gfx_private is loaded. But that will require time and digging and more time.

Toomas Soome wrote in #note-24:

nono, I did not mean any fees, just that without an access to hw, I can only try to give some advice what to check and such. From screenshots above, we can see the early kernel can output on console just fine, so it would be a question, what is different when gfx_private is loaded. But that will require time and digging and more time.

I was still willing to help troubleshoot this, but I guessed that Toomas became too busy to continue, then I nearly died from a severe illness. I'd be okay to try again as I still have two Mac minis that I can experiment with.

Will B wrote in #note-25:

Toomas Soome wrote in #note-24:

nono, I did not mean any fees, just that without an access to hw, I can only try to give some advice what to check and such. From screenshots above, we can see the early kernel can output on console just fine, so it would be a question, what is different when gfx_private is loaded. But that will require time and digging and more time.

I was still willing to help troubleshoot this, but I guessed that Toomas became too busy to continue, then I nearly died from a severe illness. I'd be okay to try again as I still have two Mac minis that I can experiment with.

oops... Hope you are better now? anyhow, sure, sometimes I'm more busy, but I'm usually quite reachable either by mail or on irc:) To get back on topic; as we have established, early kernel does draw just fine. So I would add a bit of code to draw something simple from gfx_private itself - like horizontal and vertical line. That should help to identify the distortion and see what is going wrong. Without working console it would be rather pain, so, you would like to have bootable image which does provide ssh access, so you can access mdb etc.