Damon McMahon wrote:
> Thanks for the response, Nick, I'm almost there and just one further query:
>
> On 18/02/07, Nick Holland <[EMAIL PROTECTED]> wrote:
...
> The Aptiva has an anaemic BIOS program, but by disabling one of the
> two serial interfaces I now appear to have eliminated IRQ conflicts
> and acquired a working serial console - BUT I lose nearly all of the
> dmesg(8) and init(8) output at boot, with it being directed to the
> screen instead. I also note that boot(8) tells me I have com0 and no
> com1 (which is expected since I disabled it in the BIOS) whereas
> dmesg(8) tells me I have pccom1 but no pccom0 and this seems a little
> strange to me.
boot(8) tells you what the BIOS tells it. boot(8) uses the BIOS to
communicate.
dmesg(8) tells you what hardware OpenBSD actually found.
The BIOS can define ports as it wishes.
OpenBSD defines ports as spec'd in /usr/src/sys/arch/i386/conf/GENERIC
>From your dmesg,
> pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
That's not the standard definition for com0 (DOS COM1), but rather,
com1 (DOS COM2:)
>From pccom(4):
pccom0 at isa? port 0x3f8 irq 4
pccom1 at isa? port 0x2f8 irq 3
>
> To clarify, boot(8) tells me I have com0 available at boot. So in
> /etc/boot.conf I tell it:
>
> set tty com0
>
> and it switches to the console but all that is output to the console is:
>
>>> OpenBSD/i386 BOOT 2.10
> boot>
> booting hd0a:/bsd: 4966344+867848 [52+255872+237161]=0x608d64
> entry point at 0x100120
so once the kernel is loaded, your redirection is screwed up...
> That's it for the output seen on the terminal, at this point the
> dmesg(8) and init(8) output is directed to the screen. Then when
> getty(8) is executed interactivity for _both_ the keyboard and the
> serial console are restored.
I haven't played with this kind of config, but my guess is you are
sending the output to a non-existant com0, so the system falls back to
using the screen.
You get the serial IO again after boot because of your ttys setting
which has tty01 turned on, you would get the login prompt on the
serial port even if you didn't do the "set tty com0".
> Any further thoughts will be appreciated; dmesg(8) and ttys(5) are
> included below:
...thanks, snipped for size
>
> # head -n 20 /etc/ttys
> #
> # $OpenBSD: ttys,v 1.17 2002/06/09 06:15:14 todd Exp $
> #
> # name getty type status comments
> #
> console "/usr/libexec/getty Pc" vt220 off secure
> ttyC0 "/usr/libexec/getty Pc" vt220 on secure
> ttyC1 "/usr/libexec/getty Pc" vt220 on secure
> ttyC2 "/usr/libexec/getty Pc" vt220 on secure
> ttyC3 "/usr/libexec/getty Pc" vt220 on secure
> ttyC4 "/usr/libexec/getty Pc" vt220 off secure
> ttyC5 "/usr/libexec/getty Pc" vt220 on secure
> ttyC6 "/usr/libexec/getty Pc" vt220 off secure
> ttyC7 "/usr/libexec/getty Pc" vt220 off secure
> ttyC8 "/usr/libexec/getty Pc" vt220 off secure
> ttyC9 "/usr/libexec/getty Pc" vt220 off secure
> ttyCa "/usr/libexec/getty Pc" vt220 off secure
> ttyCb "/usr/libexec/getty Pc" vt220 off secure
> tty00 "/usr/libexec/getty std.9600" vt220 on secure
> tty01 "/usr/libexec/getty std.9600" vt220 on secure
What's hurting you is that non-standard first com port. Take another
look at your BIOS setup, see if there is anything that allows you to
change how it is defined. Also check to make sure you don't have any
BIOS-based redirection going..that can cause various problems that
might be similar to this on some machines. (BIOS redirection is
great, but unfortunately, not at all standardized, so results are
sometimes unpredictable.)
Nick.
