On Sun, Feb 08, 2026 at 10:15:46AM +0300, Vitaliy Makkoveev wrote:
> On Sat, Feb 07, 2026 at 07:20:04PM +0100, Kirill A. Korinsky wrote:
> > On Sat, 07 Feb 2026 14:11:05 +0100,
> > Vitaliy Makkoveev <mvs@openbsd.org> wrote:
> > > 
> > > On Fri, Feb 06, 2026 at 06:39:03PM +0100, Kirill A. Korinsky wrote:
> > > > > > 
> > > > > > What about my suggestion to have a dummy framebuffer?
> > > > > > 
> > > > > 
> > > > > I had tried, but I wasn't able make something that works.
> > > > > 
> > > > > Or better to say all my attemt leads to that machine still hungs.
> > > > > 
> > > > > Here hard part: this is remote machine, I haven't got access to serial
> > > > > console on it, I can only boot it, or boot in "rescue mode" (Linux) or as
> > > > > to attach KVM.
> > > > > 
> > > > > ... and without the way to debug I can't figure out why and where it hangs.
> > > > >
> > > > 
> > > > Shall I drop this diff ?
> > > > 
> > > 
> > > I agree with Mark. The dummy console which you intentionally enable via
> > > /etc/boot.conf like "set tty dummy" is the right way.
> > > 
> > 
> > Well, I think this is another feature.
> > 
> > On this machine, it doesn't matter whether I set tty dummy or com0.
> > 
> > However, Linux boots headless on this machine and uses vgaarb for the video
> > card, even though nothing is connected to it. My diff replicates the logic
> > to decide that it is safe to use as VGA compatible card.
> > 
> > I think we need https://marc.info/?l=openbsd-tech&m=176980480915521&w=2 to
> > support this setup, as I've seen a few reports of similar behavior.
> > 
> 
> This machine boots only if it has monitor connected, right? Otherwise it
> panics somewhere.

My understanding was that it doesn't _panic_, but init is unable to open
/dev/console.

In normal use, the machine is using amdgpu to provide a wsdisplay device.

When using the ramdisk kernel, since amdgpu is not available, we would expect
the machine to fall back to efifb, which it _does_ IFF a monitor is connected,
(or likely more accurately, if the firmware can read EDID data from such a
monitor).

However if a monitor is not connected, the firmware of the machine does not
configure a graphical efi framebuffer, and sets the efi framebuffer base
address to 0x00, which correctly causes our efifb driver NOT to attach.

The firmware itself and the OpenBSD bootloader are presumably using efi text
mode to function.  But efi text mode is not available after you make the call
to exit boot services, so a kernel driver cannot, (easily), be written to use
it.

In the past, most machines in this situation had one or both of:

* Working VGA hardware, that the vga driver in the ramdisk kernel could attach
  to.

OR

* Operators knowledgable enough to recognise what was going on and work around
  it, (E.G. use a serial console).

This hardware does not have fully enabled legacy VGA.

So no console device is available when booting the ramdisk kernel.

Various solutions have been proposed, each of which has downsides:

* Fake a serial console.

* Fake a VGA device, and write to the memory locations traditionally associated
  with VGA hardware regardless of the consequences.

* Make a good-faith attempt to verify that there is actually VGA hardware at
  those addresses and then write to them.

* Write a simple EFI application to reinit the hardware and enable the
  graphical efi console regardless of whether a monitor is physically present.

* Fake a VGA device with system memory allocated to a dummy frame buffer.

* (a new one) write a kernel device driver that wsdisplay can attach to which
  does nothing, or simulates an MDA or whatever.

> Seems your video card reports wrong data in the
> headless mode.

Not really.  The UEFI firmware gets no EDID data from the monitor, and as a
result of that, does not confiure a framebuffer.  That's a valid, if unusual,
behaviour for the firmware to take.  UEFI doesn't guarantee the presence of a
graphical framebuffer.