In D49077#1120387, @imp wrote:

I thought that we checked for raw because we couldn't guarantee that all other implementations had the right pre-req to allow this safely.
I remember getting burned by something similar because we weren't completely consistent... Maybe f->f_dev isn't always set? It's been a while.

In D49073#1119536, @jkim wrote:

I tried gop blt off on my old laptop and it worked there. Surprisingly, gop blt off case is significantly *slower* than gop blt on case.

In D49073#1119425, @kenrap_kennethraplee.com wrote:

I'm having this same problem with the GOP Blt rendering the framebuffer at my monitor's 4K resolution. It makes rendering to the next part of the loader crawl very slowly against my screen at a row-by-row basis.

I took a video recording and uploaded on Streamable to show as an example (skip to 26s to see it finally process the "2nd" row):

https://streamable.com/nj4mkb

At that speed, I feel it'll likely take 2 hours or more to get to the full rendering of the menu before I can hit enter to load the kernel.

I should note that not all graphics cards I've used on my system have this problem. Since I recently started using an RX 7800 XT GPU, it was the one that ramped up the Blt to 4K where as other GPUs would use 1080p even when they render 4K in X11/Wayland.

What I do to work around this problem is by using rEFInd as an intermediary and config it to lower the Blt resolution before transitioning to the loader. This dramatically speeds up the rendering to the menu which allows me to boot and finally use this graphics card for this system as shown in the following:

https://streamable.com/jlm7ig

I've also tested gop blt off and it doesn't solve my problem without rEFInd. And after using rEFInd and it just doesn't render the menu after a bit of time and goes right to showing the kernel being loaded, as shown here:

https://streamable.com/esgqn3

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

In D49073#1119151, @imp wrote:

it's ok I guess, but seems like yet another hack. Is there some way we can know if blt is slow?

thanks!

fix typo

This change should really posted to OpenZFS too.

Thanks!

In D43914#1001826, @imp wrote:

In D43914#1001802, @tsoome wrote:

alloca or local variable does allocate from stack (which may be in collision with bss), the opther option there to get low memory allocation is to use bio_alloc() and bio_free().

Pnp nodes are like 32 bytes... and must be in the lower MB.

alloca or local variable does allocate from stack (which may be in collision with bss), the opther option there to get low memory allocation is to use bio_alloc() and bio_free().

The trick question there is, the bootonce property is supposed to have generic boot descriptor, it does not have to be just zfs dataset name.... of course, if you have pools, then most likely you only do use zfs datasets.

hm, do we actually need this preprocessor #if statement?

In D40011#911068, @emaste wrote:

Yeah. In the past I would have argued that we should work on support it (back when Intel had viable contemporary 32-bit hw and a 32-bit Tianocore to go with it) but at this point i386's future overall is not clear and we're not going to put effort into this.

In D39799#906388, @imp wrote:

so how was all this working before?
or is SEGDESC_t not all that important?

In D39323#895597, @manu wrote:

In D39323#895586, @hselasky wrote:

I think doing a functional function trace is mandatory before this commit, seeing what code is calling into what code, and what locks are in use.

If you need help ask, @zlei .

What @gbe reports clearly shows we can do better than just pushing changes and waiting for others to fix them.

--HPS

Nobody here said anything about "waiting for others to fix them". I hope that you understand that we cannot test every configuration possible.
And, sure, since now we have a report that it doesn't work on hyper-v nothing will be commited before the problem is understood and fixed.