mikes@sir-alan.UUCP (Mike Squires) (12/11/89)
On "sir-alan", a Tandy 4000LX running SCO XENIX V 2.3.2 GT with VP/ix (update A installed) failing to log out of VP/ix before a reboot will lock the comm port used by VP/ix (tty2a in this case) so that a power on/off cycle must be used to reset the port. Enabling/disabling the port seems to do nothing; XENIX comm programs can't talk to the port until the hardware is recycled. Any ideas?
frankb@usource.SARASOTA.FL.US (Frank Bicknell) (12/13/89)
In article <184@sir-alan.UUCP> mikes@sir-alan.UUCP (Mike Squires) writes: > On "sir-alan", a Tandy 4000LX running SCO XENIX V 2.3.2 GT with > VP/ix (update A installed) failing to log out of VP/ix before a > reboot will lock the comm port used by VP/ix (tty2a in this case) > so that a power on/off cycle must be used to reset the port. > > Enabling/disabling the port seems to do nothing; XENIX comm > programs can't talk to the port until the hardware is recycled. > Any ideas? I have found that this happens under certain situations with our port without VP/ix comming into play. Here's how it happens: If the port is enabled and I bring the system down by cheating (ie umnt -r + sync;haltsys)... the 'TR' remains on after Xenix dies. I must then cycle the power to the machine to get that port reset. If I kill the getty process on that port (preventing another from being spawned first, of course), the light goes off and I can re-use the port after the reboot. My theory is that it has more to do with the com port hardware and very little if anything to do with Xenix or, in your case, VP/ix. Having only one port so far, I haven't been able to verify my theory, however :) . -- Frank Bicknell UniSource; 1405 Main St, Ste 709; Sarasota, FL 34236 attctc!usource!frankb || frankb@usource.SARASOTA.FL.US