Paths

Table of Contentst

stand: More sensible defaults when ConOut is missing
ClosedPublic
Actions

Authored by imp on Aug 22 2022, 9:32 PM.

Details

Reviewers

manu
emaste

Commits

rGf80cdedebe9f: stand: More sensible defaults when ConOut is missing
rGdf065f699f1f: stand: More sensible defaults when ConOut is missing

Summary

When ConOut is missing, we used to default to serial. Except we did it
in the worst way possible by just setting the howto bits and not
updating the console setting, which lead to weird behavior where we'd
get some things on the video port, others on serial.

Instead, set console to "efi,comconsole" for this case. Also set
RB_MULTIPLE always (so we get dual consoles from the kernel) and or in
RB_SERIAL when we can't find GOPs that suggest the precense of a video
console. This will put output in the most places and have a sensible
default for 'primary' console.

Diff Detail

Repository

rG FreeBSD src repository

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

imp created this revision.Aug 22 2022, 9:32 PM

Herald added a reviewer: manu. · View Herald TranscriptAug 22 2022, 9:32 PM

Herald added subscribers: dab, bcran. · View Herald Transcript

imp requested review of this revision.Aug 22 2022, 9:32 PM

Harbormaster completed remote builds in B47062: Diff 109686.Aug 22 2022, 9:32 PM

imp mentioned this in D36286: stand: Document EFI consoles.Aug 22 2022, 9:36 PM

I will give this a try on the affected machine.

LGTM, hopefully it will solve @emaste problem.

This revision is now accepted and ready to land.Aug 23 2022, 7:01 AM

This is certainly an improvement for PR265980.

Two issues remain:

we show the text mode loader, not graphical
with the serial port disabled via BIOS the system hangs on boot, an earlier boot -v showed it hung after

pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0

The second is I believe not an issue with the loader per se. For the first issue it's something we can consider later on.

In D36299#824637, @emaste wrote:

This is certainly an improvement for PR265980.

Two issues remain:

we show the text mode loader, not graphical

Yeah this is known, as soon as we have a serial present loader will use text mode everywhere.

with the serial port disabled via BIOS the system hangs on boot, an earlier boot -v showed it hung after

pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0

The second is I believe not an issue with the loader per se. For the first issue it's something we can consider later on.

Yeah this is known, as soon as we have a serial present loader will use text mode everywhere.

Right, but in this case we don't actually have a serial interface.

In the case of no ConOut but GOP modes exist we could decide not to enable serial. I'm not sure if that's a good idea or not -- if there's other hardware that needs to have serial enabled in that case. In any case I think we should consider that as a second step, after this change goes in.

In D36299#824655, @manu wrote:

In D36299#824637, @emaste wrote:

This is certainly an improvement for PR265980.

Two issues remain:

we show the text mode loader, not graphical

Yeah this is known, as soon as we have a serial present loader will use text mode everywhere.

It's also the lessor of two evils. If the BIOS is not providing this information that's basically mandatory, we have to be very conservative about what we do and use. While we might be able to do more on Ed's laptop, there's no guarantees other devices that are similar will behave in a similar manner.

A slightly more robust method would be to find a serial port to use via the UEFI BIOS calls that allow that. However, we're really not setup to that in a robust manner right now...

with the serial port disabled via BIOS the system hangs on boot, an earlier boot -v showed it hung after

pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0

The second is I believe not an issue with the loader per se. For the first issue it's something we can consider later on.

I agree, that's beyond the scope of the loader.

In D36299#824668, @emaste wrote:

Yeah this is known, as soon as we have a serial present loader will use text mode everywhere.

Right, but in this case we don't actually have a serial interface.

Having a serial or RB_SERIAL is the same for loader :P (kinda)

In the case of no ConOut but GOP modes exist we could decide not to enable serial. I'm not sure if that's a good idea or not -- if there's other hardware that needs to have serial enabled in that case. In any case I think we should consider that as a second step, after this change goes in.

Someone (tm) should really take the time to rewrite all console stuff for loader so we can do much nicer things with a few loader.conf/loader.env vars.
And by someone that might be me soon as we will have the problem for $WORK

In D36299#824668, @emaste wrote:

Yeah this is known, as soon as we have a serial present loader will use text mode everywhere.

Right, but in this case we don't actually have a serial interface.

In the case of no ConOut but GOP modes exist we could decide not to enable serial. I'm not sure if that's a good idea or not -- if there's other hardware that needs to have serial enabled in that case. In any case I think we should consider that as a second step, after this change goes in.

I'm not at all sure that this is the right choice in the general case. I hate generalizing from one example. There are similar setups in the embedded world and the right choice there is to do serial.

It likely should be rolled into the longer-term plan of being able to use the ACPI UID to describe which serial port to use (or not). The comconsole code is written so that it won't hang if the hardware isn't there, so we should fail safe with the present code. Talking to I/O ports that don't decode hardware is very well defined....

It's also the lessor of two evils. If the BIOS is not providing this information that's basically mandatory, we have to be very conservative about what we do and uses.

It may not be, though - if there are no systems that have GOP modes, no ConOut, but must use serial then I'd say we'd be better served by not setting RB_SERIAL/RB_MULTIPLE. But, we'd have to be certain that there are no such systems. Or, perhaps we special case vendor==ASUS. But either way something to consider independent of / after this change.

While we might be able to do more on Ed's laptop,

It's a consumer desktop board, and it has affected several people who tried Alder Lake:

In D36299#824673, @emaste wrote:

It's also the lessor of two evils. If the BIOS is not providing this information that's basically mandatory, we have to be very conservative about what we do and uses.

It may not be, though - if there are no systems that have GOP modes, no ConOut, but must use serial then I'd say we'd be better served by not setting RB_SERIAL/RB_MULTIPLE. But, we'd have to be certain that there are no such systems. Or, perhaps we special case vendor==ASUS. But either way something to consider independent of / after this change.

Yes. Vendor == ASUS is likely too broad.

The kernel already knows how to cope with no video when RB_MULTIPLE is set. I've run systems w/o video like that since my Timing Solutions days, though maybe I just got lucky...

While we might be able to do more on Ed's laptop,

It's a consumer desktop board, and it has affected several people who tried Alder Lake:

https://lists.freebsd.org/archives/freebsd-stable/2021-October/000249.html

https://lists.freebsd.org/archives/freebsd-current/2022-August/002464.html

https://lists.freebsd.org/archives/freebsd-current/2022-August/002468.html

Right, but we only know for sure what happens on your laptop with this change... Any more sophisticated change will need testing in more areas than just AlderLake laptops (eg the riscv workaround I tagged likely can be removed completely now). The diversity of the deployed UEFI base has made me very cautious in reacting to one bad actor.