Z50 - "wsdisplay_console_initted < 2" panic on hpcmips HEAD

[David Brownlee <abs%absd.org@localhost>]

Alex noted that the following panic triggers on HEAD for the z50

panic: kernel diagnostic assertion "wsdisplay_console_initted < 2"
failed: file "/usr/src/sys/dev/wscons/wsdisplay.c", line 927

(Fortunately he has the setup for serial console so this doesn't block
testing other changes, but its probably not a nice way to leave HEAD)

This is just me thinking aloud here - I'm not a kernel dev, but for
our purposes I can wave my hands around enough to help anyone reading
who has absolutely no kernel knowledge to get a basic idea :)

nxr.netbsd.org is an excellent resource if you do not have a local
source tree to hand (and also handy even if you do), so looking at the
source this in wsdisplay_cnattach
https://nxr.netbsd.org/xref/src/sys/dev/wscons/wsdisplay.c#927
and a quick search for wsdisplay_console_initted
https://nxr.netbsd.org/search?q=wsdisplay_console_initted&project=external&project=src
shows it is only ever set to 2 at line 950 of wsdisplay_cnattach,
which is after the panic line in the control flow.

So, either something very wacky is going on (a herd of unicorns with
prime numbers of legs running by), the hooves we're hearing are most
likely caused by wsdisplay_cnattach being called twice

So why might this be an issue? The wsdisplay(9) manpage
http://man.netbsd.org/wsdisplay.9 defined wsdisplay_cnattach as

              Attach this display as the console input by specifying the num-
              ber of columns ccol and number of rows crows.  The argument
              defattr specifies the default attribute (color) for the console.

(we might have been able to guess that from the name, but it's good to
check docs. It's even better to find that there are some covering what
you are looking for :)

So, what calls wsdisplay_cnattach - well, I'm glad you asked - as nxr
can easily give us that info
https://nxr.netbsd.org/source/s?refs=wsdisplay_cnattach&project=src
... which runs to 81 entries across all ports (we can exclude the
actual definition and declaration, and anything on other ports or dev
hardware we do not have on a z50).
It looks very likely that the winner is the only entry with "hpc" in its path
https://nxr.netbsd.org/xref/src/sys/dev/hpc/hpcfb.c#413

A quick check to see when the wsdisplay_console_initted was added to
wsdisplay.c (in case its something new that the z50 port has not been
updated for) clicking the Annotated link at the top of the page to
give https://nxr.netbsd.org/xref/src/sys/dev/wscons/wsdisplay.c?a=true
- it turns out the setting and checking to 2 was in at least 1.105
from... 2006/11/06 - OK, so it's more likely a change in or around the
z50/hpcmips code

So it could be:
- two different devices are trying to attach as console
- some single device trying to attach twice as console, possibly once
in some MI code which has been updated and another in port specific MD
code which had not

It could even be some code which is missing the check to see if it's
being asked to be the console and trying to claim it in all cases, or
something else (cue large hand wave)

Looking at a reference dmesg from a boot of recent current on serial
console (Thanks again Alex:) we have
https://dmesgd.nycbug.org/index.cgi?do=view&id=6096

hpcfb0 at ite8181video0
wsdisplay0 at hpcfb0 kbdmux 1

ite8181video0 - thats interesting...

https://nxr.netbsd.org/xref/src/sys/arch/hpcmips/dev/ite8181.c#301
https://nxr.netbsd.org/xref/src/sys/dev/hpc/hpcfb.c#413

I think we have our smoking "double attach" gun. I suspect hpcfb.c was
updated for another hpc* port (hpcarm I'm looking at you), and
hpcmip's ite8181 was missed.

Anyway - enough for tonight - will actually start looking at code tomorrow

David