mabrey@vax1.acs.udel.EDU (Dennis W Mabrey) (03/25/88)
The company I work for has an AT compatable running
SCO XENIX. We sometimes get the message on our main console
that says:
init:/dev/ttyx05: getty keeps dying. There may be a problem
None of our manuals tell us any information.
Does anyone know what the problem/solutions is??jack@turnkey.TCC.COM (TCC Software Developer) (03/29/88)
In article <884@udccvax1.acs.udel.EDU> mabrey@vax1.acs.udel.EDU (Dennis W Mabrey) writes: > > The company I work for has an AT compatable running > SCO XENIX. We sometimes get the message on our main console > that says: > > init:/dev/ttyx05: getty keeps dying. There may be a problem ^^^^^ More information about your hardware is necessary to give thorough advise on this problem, I am unsure if the above is a typo or you are using somebody's multiport card with special tty drivers. > > None of our manuals tell us any information. > Does anyone know what the problem/solutions is?? The general answer is that as init tries to spawn a getty on the port of this tty it is dying off. When init must respawn too frequently it will give you this message. If it is a special multiport card it may be the problem, check all connections, power down and reseat the card, check all external connectors as well. If you meant to say 'tty05' you have a problem in the basic system somewhere since that is not even a real serial port, but a multiscreen. If you care to email me more detail on the hardware, and ,say, frequency of the problem I could perhaps make more concrete suggestions. Good luck, -- Jack F. Vogel Turnkey Computer Consultants, Costa Mesa, CA UUCP: ...!uunet!turnkey!jack Internet: jack@turnkey.TCC.COM
uhclem@trsvax.UUCP (04/01/88)
<> Base notes wants help on message: B> init:/dev/ttyx05: getty keeps dying. There may be a problem As one of the responses has noted, this message may have come from init for having to spin-off too many gettys in a short time. If this is a real IBM AT serial/parallel adapter or one that is an exact clone (used same RS232-C line receivers) then this information may assist. The line driver IBM used the 75154 line receiver which is sensitive to noise, more so than the 1489 which more systems use for RS232-C line receivers. Anyway, we found if you had an IBM AT adapter in your machine and a non-ribbon cable (6ft) other than IBM's connected and it was not connected to anything, if you enabled the line, the earlier releases of XENIX-286 would bog down or die after a while. The above message appears to part of a way of keeping that from happening in the new releases. It does come from /etc/init. We did something similar in one of our own XENIX releases. What causes it? We found that when the line was enabled, the CD line would be floating high enough to cause a getty to be started. The banner would be transmitted and these transitions would cause the CD line to swing low and high, very minute, but enough to generate 8 to 10 interrupts per character requesting the getty by killed and another started. The real, sold by big-blue IBM serial cable is shielded and does not exhibit this problem unless you extend it with a lot of unshielded stuff. Perhaps a better word for the message might have been "thrashing". We also found that ribbon cable did not seem to have this problem - apparently enough distance between 8 and 2/3 to reduce induction. Adapter cards from other vendors we tried all used 1489's and did not display this problem. The moral of all this was not to enable a line that did not have a computer, modem or terminal attached. Hope that helps. <This information is provided by an individual and is not nor should be construed as being provided by Radio Shack or Tandy Corp. Radio Shack/Tandy Corp has no obligation to support the information provided in any way. Over half of the hydrocarbon pollution in Tarrant county comes from the northern third of the county which is in the country. What's doing it? Cows burping. How do you fit a smog device on that?> "Thank you, Uh Clem." Frank Durda IV @ <trsvax!uhclem> ...decvax!microsoft!trsvax!uhclem ...convex!infoswx!hal6000!trsvax!uhclem
greg@csanta.UUCP (Greg Comeau) (04/05/88)
> getty keeps dying
We've had this problem on our WYSE 286 box after rebooting XENIX
from a shutdown. Solution seems to be the need to power off the machine
before the reboot so as to reset the terminal in some way or another.
If this is happening to you just all of a sudden after XENIX has been up
for at least a few minutes, then I'm not sure what's wrong. One possibility
is that you've got noise on the line that's producing the console messages.
You might want to try a different cable...donegan@stanton.TCC.COM (Steven P. Donegan) (04/06/88)
In article <160@turnkey.TCC.COM>, jack@turnkey.TCC.COM (TCC Software Developer) writes: In article <884@udccvax1.acs.udel.EDU> mabrey@vax1.acs.udel.EDU (Dennis W Mabrey) writes: > > The company I work for has an AT compatable running > SCO XENIX. We sometimes get the message on our main console > that says: > > init:/dev/ttyx05: getty keeps dying. There may be a problem I too have had getty die, one thing I've noted is that a terminal connected as a non-modem (such as a 'm' gettydef code in /etc/ttys) can have serious problems if the device/terminal is powered off while physically connected to the PC's serial port. My 'fix' to this gettydeath has been simply powering off the terminal, doing an /etc/haltsys, powering off the PC, waiting the required 30 seconds for the power supply to bleed off and then re-starting the terminal, PC, XENIX etc. This cycle always works for me. Seems that the 8250 or 16450 chip gets lost in space somewhere and XENIX's getty doesn't know or try a full reset when it dies...sigh If you had a REAL computer (like a cray, doesn't everyone need one at home?) this WOULDN'T HAPPEN! :-) donegan@stanton -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp.
fred@cdin-1.uucp (Fred Rump) (04/08/88)
port 5 is not plugged in.
jkimble@crash.cts.com (Jim Kimble) (04/11/88)
In article <3@stanton.TCC.COM> donegan@stanton.TCC.COM (Steven P. Donegan) writes: >My 'fix' to this gettydeath has been simply powering >off the terminal, doing an /etc/haltsys, powering off the PC, waiting the >required 30 seconds for the power supply to bleed off and then re-starting >the terminal, PC, XENIX etc. This cycle always works for me. Seems that the >8250 or 16450 chip gets lost in space somewhere and XENIX's getty doesn't >know or try a full reset when it dies...sigh I found it to be a lot quicker to just do the following: (Power the problem terminal back on, first of all) # disable ttyx05 # enable ttyx05 The port is turned off and then turned back on, so a new getty is spawned. Quicky and dirty, but it works.... --Jim Kimble "I used to be into necrophillia, flagellation, and beastiality -- but my friends said I was just beating a dead horse." UUCP: {hplabs!hp-sdd, sdcsvax, nosc}!crash!jkimble ARPA: crash!jkimble@nosc INET: jkimble@crash.CTS.COM
det@hawkmoon.MN.ORG (Derek E. Terveer) (04/11/88)
In article <3@stanton.TCC.COM>, donegan@stanton.TCC.COM (Steven P. Donegan) writes: > In article <160@turnkey.TCC.COM>, jack@turnkey.TCC.COM (TCC Software Developer) writes: > In article <884@udccvax1.acs.udel.EDU> mabrey@vax1.acs.udel.EDU (Dennis W Mabrey) writes: > > init:/dev/ttyx05: getty keeps dying. There may be a problem > [description of how to fix a bad getty] > If you had a REAL computer (like a cray, doesn't everyone need one at home?) > this WOULDN'T HAPPEN! :-) I believe this phenomenah is called "bird dogging", i'm not sure why. We once had, through the vagaries of our terminal server, one of our login ports hooked up to another login port. First I found out about it was when users started complaining about massive (more than usual (:-)) system degradation. Our getty was spawning and respawning fairly quickly. -- Derek Terveer det@hawkmoon.MN.ORG uunet!rosevax!elric!hawkmoon!det
donegan@stanton.TCC.COM (Steven P. Donegan) (04/12/88)
> I found it to be a lot quicker to just do the following: > > (Power the problem terminal back on, first of all) > # disable ttyx05 > # enable ttyx05 > > The port is turned off and then turned back on, so a new getty is spawned. > Quicky and dirty, but it works.... > > --Jim Kimble Thanks for a better solution, mine was too involved and 'dirty'. I hope that SCO does better on the more recent releases (I run 2.2.1). -- Steven P. Donegan Sr. Telecommunications Analyst Western Digital Corp. donegan@stanton.TCC.COM