Hi Paul,
> On Fri, Mar 03, 2017 at 08:54:02AM +0100, Jan Stary wrote:
> | On Mar 03 08:46:11, h...@stare.cz wrote:
> | > This is current/amd64 (dmesg below). I got me this
> | > https://www.alza.cz/EN/axago-pcea-s2-d277216.htm
> | > to have two extra serial ports to connect to my ALIXes.
> | > It shows up in dmesg as
> | >
> | > puc0 at pci2 dev 0 function 0 "NetMos Nm9922" rev 0x00: ports: 1 com
> | > com4 at puc0 port 0 apic 2 int 16: st16650, 32 byte fifo
> | > puc1 at pci2 dev 0 function 1 "NetMos Nm9922" rev 0x00: ports: 1 com
> | > com5 at puc1 port 0 apic 2 int 17: st16650, 32 byte fifo
> |
> | Hm, puc(4) says
> |
> | The current design of this driver keeps any com ports on these
> | cards from easily being used as console. Of course, because boards with
> | those are PCI boards, they also suffer from dynamic address
> | assignment, which also means that they can't easily be used as console.
> |
> | What do people use as a serial port expansion then
> | to connect to the ALIX serial console?
>
> Using a com(4) port as console means the kernel writes its messages
> there during boot. The bootloader prompts you on it. You can run a
> getty(8) there so you can log in to the system. This is what you want
> to do on your ALIXes.
>
> On your machine with puc(4), you can simply use the additional com(4)
> ports to talk to the consoles on your ALIXes by using cu. Point it at
> the proper outgoing terminal device (for /dev/cuaXX, use -l cuaXX) and
> use the correct speed (e.g. -s 19200).
>
> The machine that has puc(4) may have its console on a glass terminal
> (using a monitor and keyboard), or it itself may have a serial
> console. In that case *THAT* should use an onboard serial port, not
> one behind puc(4).
Yes. Sorry for the confusion. Indeed, it is the ALIX's console
I want to connect *to* form this machine (which has a monitor),
using the new com at pcu.
Anyway, waht is it that makes the new com(4)s
hang on 'ttyflags -a' at rc(8) time?
Jan
