| Something is slightly flakey with the console attachment on my Ultra10.
| The keyboard probes like this:
|    com0 at ebus0 addr 3083f8-3083ff ipl 41: ns16550a, working fifo
|    com0: console
|    kbd0 at com0 (console input)
|
| And pcons doesn't attach:
|    pcons at mainbus0 not configured

Looks fine to me.

| During the boot process, the "ipl 41" on the com0 attach line is the
| last thing output, until /sbin/init starts /etc/rc.  If I boot single user
| the keyboard eventually flakes out, where keys repeat, or I type a command
| and hit enter and need to keep hitting keys to "flush" the keyboard buffer
| or something.

That is due to nasty interaction between the keyboard line mode and PROM
output.

| Looking at com_ebus.c it appears that com_ebus_isconsole() returns true 
| if com0 is stdin _or_ stdout.  Shouldn't it need to be both before it is
| considered the "console" device?

No.  It gets a bit complicated.

Early PCI based machines switched from using zs8530 serial controllers for
both keyboard and serial ports to using 16550 clones for the keyboard and
mouse, and sab8253x for the serail ports.  Later machines use the 16550s
for the serial ports and either USB or another 16550 for the keyboard and
mouse.

If you have a keyboard on a 16550, then you want to have the console input
directed there, but console output directed somewhere else, probably the
PROM console.

If you have a 16550 serial port, then you probably want both input and
output going to that 16550.

What gets more interesting is when you have intput going from one device
such as the keyboard, and output going to a completely unrelated device,
such as a serial port.  Unfortunately, the com driver is completely unable
to handle that sort of thing.

Now, if you have a keyboard attached to the com driver, the order of attachment
is interesting:

First the com driver is attached as the console.

Then the keyboard driver attaches.  It stashes the com console vectors in a
private structure and installs itself as the console.  

Hm.  On the other hand, there is a small problem:  com_ebus_attach() needs
to stash away the original cn_tab while attaching the com driver and restore
it afterwards so the original PROM output vector remains in place.  It might
be better to just install the appropriate input our output vectors in cn_tab
if com could handle different instances doing input and output, which it
doesn't.

| I ask because in pcons.c pconsmatch() has the following:
|         /* Only attach if no other console has attached. */
| 	return ((strcmp("pcons", ma->ma_name) == 0) &&
| 		(cn_tab->cn_getc == prom_cngetc));
|
| This always returns zero on my Ultra10.  My assumption is the com0 attachment
| is hosing this, but?

No, the pcons driver is there for things like open() and close().  Once you
have a keyboard attached the keyboard driver will take over those functions,
so pcons never needs to be attached.

Eduardo