Slackware Linux 14.1 on Intel NUC DN2820FYKH
with ATEN UC232A usb-serial.
I have 12 systems built for a customer and they are to be deployed in the in an unattened environment.
I have a getty login running on the ttyUSB1 port on the linux NUC
The final deployment will have modems connect to the UC232A the problem
is the modem dialup ppp login stops working after 15min - 2 hrs.

The test setup to trouble shoot the problem has an XP PC plugged into the UC232A running putty
in serial mode (acting as a terminal) which also exhibits the problem

The getty login works after boot ok but after a period (which seems to vary from 15 min to 2 hours)
the login stops echoing key strokes back to putty
If I kill the getty process a new login spits on the putty but I still cannot type anything (however I can see the led on the UC232A flashing when I type)..
Replugging the usb-serial from the NUC usb port starts it working again.

Iv'e tried disabling usbcore autosuspend in the Linux kernel but has effect.

I have also tried writing to
echo "-1" >/sys/bus/usb/devices/1-3/power/autosuspend_delay_ms
echo "0" >/sys/bus/usb/devices/1-3/power/autosuspend
echo "enabled" >/sys/bus/usb/devices/1-3/power/wakeup

Also tried to run a script to to cycle the usb power hoping it would simulate replugging the usb
echo "1-3:1.0" >/sys/bus/usb/drivers/pl2303/unbind
sleep 5
echo "1-3:1.0" >/sys/bus/usb/drivers/pl2303/bind

I have also tried tieing the rs232 hand shake lines thinking that the RTS is some how going inactive
but with no success.

Additional
I also have a another UC232A on ttyUSB0 capturing data from a PABX
the getty login that stops working is a on second UC232A on ttyUSB1
The UC232A on ttyUSB0 connected to the PABX still continues to work fine after the issue with the getty login occurs on ttyUSB1

Also I';ve tries swapping the USB order so that the getty is on ttyUSB0
and the PABX is on USB1 without success the getty still failes to allow login

I've tested on the older slackware 14.0, and the getty login works fine, and does not fail.

The driver is pl2303

What type of serial cable are you using? Are all the pins connected?
You could try using a serial cable which connects only a subset of the pins (only those required for the communication, at least TX, RX and GND.) I have used those converters with various hardware devices and sometimes the cable had an influence on the communication.
Just a guess.

It is an ATEN UC232A USB-Serial cable, (Prolific chip set), have have tries all the possiblilities with a serial vreakout box. (tieing hanshake, and siconecting all but needed pins.)
The problem is in the Slackware 14.1, (14.0 works fine). I suspect wither some change in the pl2302 device driver, or with the getty.

Giving up tring to get slackare 14.1 to work properly with the ATEN usb-serial,
moving all units back to 14.0.

It could be a driver issue. Did you try using a newer kernel? Often a getty will not issue a timeout unless init says so or the inittab configuration has it timeout after a period of inactivity. A driver could be affected by a power management issue or a connectivity timeout from a daemon. If a driver is bad it can cause loading issues but that would affect the primary loading, not after the fact. What software is being used to manage the connection?

I did not try a newer kernel,
I have tried addin the getty timeout, without success.
I have played around with the power management, and alo disable the usb-core autosuspend.
I also believe the issue is the the pl2303 driver on SW14.1
The units are being used as data loggesr and the usb-serialhas a modem which which is dialed up by a server on a regular basis
and logs in as a specific user the runs the pppd

I would test an updated kernel before fully committing. It sounds like there may be a new option in the kernel source that might need to be reconfigured for your needs. Check the kernel configuration and maybe do a diff check against the 14.1 kernel config versus the 14.0 kernel config for your hardware.

Thanks for your help, but I have rebuilt all the units to SW14.0 as they needed to be deployed.
I may revisit this down the track.