home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / apollo / 3109 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  4.1 KB
  1. Path: sparky!uunet!bcstec!aw108!grv9020
  2. From: grv9020@aw2.fsl.ca.boeing.com (Jerry Vanden Heuvel)
  3. Newsgroups: comp.sys.apollo
  4. Subject: Fed up with Support Center, help requested from net
  5. Message-ID: <1992Jul20.234751.4911@aw2.fsl.ca.boeing.com>
  6. Date: 20 Jul 92 23:47:51 GMT
  7. Organization: none
  8. Lines: 68
  9.  
  10. I've made several calls to the Support Center in the last week with Domain/OS
  11. specific information requests or problems, each time getting the same person
  12. who has been less than helpful and almost surly in attitude.  Lacking any
  13. place else to turn to, I'd appreciate any help from anyone on the net with
  14. the two problems below.
  15.  
  16. The first problem involves an application conversion from BSD to SysV.  We
  17. are using the BSD gettimeofday function to get a system clock value with the
  18. highest resolution value possible (gettimeofday is 4 microseconds, supposedly).
  19. Gettimeofday returns the timeval structure of two ints in seconds and
  20. microseconds.  There is no analogous System V function (that I know of) which
  21. returns anything with finer resolution than seconds (time(2)).  This is a
  22. general System V problem from the checks I made on other System V implement-
  23. ations I have access to.  There is a structure definition in the Apollo
  24. base.h header file which maps directly into the BSD timeval structure, if
  25. you believe the definition and comments in the header file.  Unfortunately,
  26. I can't find any reference to this structure in the Apollo system call man
  27. pages.  Does anyone know if there is an Apollo specific system call which
  28. returns the time_$timeval_t structure defined in base.h or, even better, a
  29. System V function with seconds and microseconds resolution?
  30.  
  31. The second problem is again part of our conversion from BSD to System V.  We
  32. are switching from BSD signals with sigblock/sigmask usage to System V
  33. semaphores.  Periodically a startup of the initial process will hang creating
  34. the second of two semaphore sets, each with a maximum of 34 numbers, after
  35. the creation of a shared memory region.  If we try to execute any command
  36. which attempts to access the shared memory region (our own applications) or
  37. use the System V ipcs and/or ipcrm commands, these commands also hang.  After
  38. several minutes, the hung commands return after completing successfully, and
  39. the initial process terminates with a segmentation fault with the following
  40. traceback:
  41.  
  42. Process        6660 (parent 5738, group 6660)
  43. Time           92/07/20.15:07(PDT)
  44. Program        //aw308/u6/psim/ver_g00/psim/g00/startup
  45. Status         00040004: reference to illegal address (OS/MST manager)
  46. In routine     "baf_$alloc" line 279
  47. Called from    "unix_sem_$get" line 561
  48. Called from    "semget" line 40
  49. Called from    "psim_semcreate" line 788
  50. Called from    "main" line 773
  51. Called from    "unix_$main" line 114
  52. Called from    "_start" line 132
  53. Called from    "PM_$CALL" line 176
  54. Called from    "pgm_$load_run" line 903
  55. Called from    "pgm_$invoke_uid_pn" line 1124
  56.  
  57. The shared memory region can't be removed with ipcrm (it gets marked with a
  58. "D" for deletion), there are no user processes still attached to it and any
  59. attempts to run the application again result in "too many files open" from
  60. the shget(2) call.  The only recourse is to reboot the node.  The Support
  61. Center always wants a reproduceable example of a problem which is not always
  62. possible, as in this case.  The same application runs fine at times and will
  63. only hang periodically.
  64.  
  65. We are currently building this application under BSD, accessing the System V
  66. IPC header files via "-I/sys5.3/usr/include".  We've been using System V
  67. shared memory on the Apollo this way since SR9.5 with Domain/IX with no
  68. problems.  We just switched to System V semaphores at SR10.3.5.
  69.  
  70. Any information about the two problems above will be helpful.  Please email
  71. to the address below, if you can.  I'll try to keep up with the articles in
  72. this newsgroup for a couple weeks for posted help.  Thanks.
  73. -- 
  74. Jerry Vanden Heuvel         | Voice: (206) 237-3834
  75. Boeing Commercial Airplane Group | Internet:   grv9020@aw300.fsl.ca.boeing.com
  76. P.O. Box 3707, M/S 66-04     | Boeing net: grv9020@aw300
  77. Seattle, WA  98124-2207         | UUCP: ..!uunet!bcstec!aw300!grv9020
  78.