home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sun / admin / 10645 < prev    next >
Encoding:
Text File  |  1993-01-22  |  3.4 KB  |  89 lines
  1. Newsgroups: comp.sys.sun.admin
  2. Path: sparky!uunet!cs.utexas.edu!wotan.compaq.com!moxie!lobster!uhura1!synercom!medley
  3. From: medley@sun44.synercom.hounix.org (Bert Medley)
  4. Subject: SUMMARY: SunOS v4.1.1 and getty (DTR kept low)
  5. Message-ID: <1993Jan21.215140.17981@sun44.synercom.hounix.org>
  6. Summary: Telebit T2500 takes longer to reset than SunOS likes 
  7. Keywords: Telebit, T2500, SunOS, getty, DTR 
  8. Organization: Synercom Technology, Inc., Houston, TX
  9. Date: Thu, 21 Jan 1993 21:51:40 GMT
  10. Lines: 77
  11.  
  12. I wrote:
  13. > 
  14. > I am having a sporadic, frequent problem with getty.  The configuration is a
  15. > Sun Sparc2 running SunOS v4.1.1 with the jumbo DNI and serial port patches
  16. > installed.  About every day or two the following hits:
  17. > 
  18. > Jan  7 16:02:06 sun44 getty: ioctl(TCGETS): Bad file number
  19. > Jan  7 16:02:06 sun44 getty: ioctl(TCGETS): Operation not supported on socket
  20. > Jan  7 16:02:06 sun44 getty: ioctl(TCGETS): Operation not supported on socket
  21. > 
  22. > But nothing seems to be wrong.  I am assuming that getty could not open a 
  23. > socket for some reason and gets the above error.  When it happens, DTR gets
  24. > dropped (Telebit T2500) and never gets raised, causing all incoming dialups 
  25. > to fail (NO ANSWER).  Does anyone have any ideas.  I will summarize if 
  26. > any answers are received (post or mail).  Thanks!
  27.  
  28. My thanks to the following people:
  29.  
  30.       dem@meaddata.com (David Myers) for a whole *slew* of messages and
  31.                      the correct solution.
  32.       vic@cd.com (Vic Serbe)
  33.       Kevin Cosgrove 642-2676 <qiclab!solomon!kevinc>
  34.  
  35.  
  36. It became apparent that this topic was discussed at length some time ago.  As
  37. a result I stongly urge that it appear in the FAQ as SUN, according to one
  38. sysadmin, will not respond to this problem.  The problem is that the Telebit
  39. T2500 takes longer to reset than the serial port driver allows for.  The 
  40. proper method to correct this situation follows:
  41.  
  42. ==============
  43.  
  44. From mail supplied by dem@meaddata.com (David Myers) who in turn had it
  45. from eggert@twinsun.com (Paul Eggert)
  46.  
  47. This is a all-too-well-known problem.  Here's how to fix it on a Sparc.
  48. Go to your kernel configuration files, find zs_async.o, and patch it as follows:
  49.  
  50.     # adb -w zs_async.o
  51.     zsadtrlow?W 6
  52.     $q
  53.  
  54. Then rebuild your kernel.  (You can patch the kernel directly if you like.)
  55. I haven't tried this on a Sun-3 but I wouldn't be surprised if the
  56. same fix worked there, too. 
  57.  
  58. zsadtrlow controls how long DTR is kept low when a connection is dropped.
  59. Sun ships it with the value of 3, but some modems (notably Telebit T2500s)
  60. need a larger value; without it, SunOS sometimes gets confused and keeps DTR
  61. low forever after a connection is dropped.
  62.  
  63. Question: is it true that in Solaris 2.0, you won't be able to make
  64. patches like this with Sun software without forking over extra bucks?
  65. That is, will adb be unbundled too?
  66.  
  67. Credits: jh@moon.nbn.com (John Harkin) posted this patch in
  68. <1991Nov6.181150.25181@moon.nbn.com>.  He credited Erik J. Murrey
  69. (ejm@riscit.NOC.Vitalink.COM) and Dean Long (dlong@oak.ucsc.edu) for
  70. the original fix.
  71.  
  72. =================
  73.  
  74. It was also suggested to modify the gettytab file as follows:
  75. From:      Kevin Cosgrove 642-2676 <qiclab!solomon!kevinc>
  76.  
  77.  
  78.     I forgot to mention that I added "to#60" to /etc/gettytab
  79.     to restart the getty after a 60 second timeout.  If you've
  80.     been having to kill your getty's to get them to restart,
  81.     this could really help.
  82.  
  83. =================
  84.  
  85. Thanks to all who responded!
  86. -- 
  87. Bert Medley                medley@synercom.hounix.org     [work]
  88.                     bert@medley.ssdl.com        [home]
  89.