On 03/03/17 07:31, Jan Stary wrote: > 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
I've seen this behavior on some rather attractive priced 8 port PCI serial cards which attached as puc(4). What I found is that they hung on Piii-class machines, but "worked" on P4 machines, at least until realized the P4 was sucking huge amounts of power, fans running at full speed, pumping out lots of heat, and showing huge interrupt loads when the machine was idle, and removing the 8 port card eliminated the problems. Heh. From memory, I think those were NetMos based cards, too. So, it seems some puc(4) devices end up causing horrible interrupt storms. There ARE two port PCI cards that work just fine. So I'd suggest trying other cards if two ports is all you need. In a project where I wanted some serial consoles on a remote system, and was told "don't do puc(4)", I ended up using a USB to 8-serial port device -- I think we were able to get this for under $150US. Here's how it shows in dmesg, attached to an Alix system: uhub6 at usb6 "ATI OHCI root hub" rev 1.00/1.00 addr 1 uhub7 at uhub0 port 5 "NEC product 0x0050" rev 2.00/1.00 addr 2 uftdi0 at uhub7 port 1 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 3 ucom0 at uftdi0 portno 1 uftdi1 at uhub7 port 2 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 4 ucom1 at uftdi1 portno 1 uftdi2 at uhub7 port 3 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 5 ucom2 at uftdi2 portno 1 uftdi3 at uhub7 port 4 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 6 ucom3 at uftdi3 portno 1 uftdi4 at uhub7 port 5 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 7 ucom4 at uftdi4 portno 1 uftdi5 at uhub7 port 6 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 8 ucom5 at uftdi5 portno 1 uhub8 at uhub7 port 7 "NEC hub" rev 2.00/1.00 addr 9 uftdi6 at uhub8 port 1 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 10 ucom6 at uftdi6 portno 1 uftdi7 at uhub8 port 2 configuration 1 interface 0 "FTDI FT232R USB UART" rev 2.00/6.00 addr 11 ucom7 at uftdi7 portno 1 So the eight port device is actually six one port devices attached to one hub, two one port devices attached to another hub, and the two hubs are attached to one hub, and back to the computer. I've got another one which is two four-port devices with a hub between them. Good news: in a year or so of operation, I've never seen the ports "jump around" (so that one moment, ucom2 is servicing machineB, next week, it's servicing machineD). So far, perfectly predictable (and I suspect it will stay that way). Bad news: we HAVE had problems with the device locking up. Now, our machine with the eight port USB->serial device is devoted to being the serial console for five other machines, so a quick reboot when we need console is no big deal, and this fixes the port lockups. But if you are hoping an important production machine can ALSO be the console for other important machines...this is probably not your best choice. Nick.
