Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!oakhill!dover!spanky.sps.mot.com!anderson
From: anderson@spanky.sps.mot.com
Newsgroups: comp.sys.apollo
Subject: Failure of tb after aqdev
Message-ID: <1682@dover.sps.mot.com>
Date: 16 Aug 89 17:32:44 GMT
Sender: news@dover.sps.mot.com
Reply-To: anderson@spanky.sps.mot.com ()
Distribution: na
Organization: Motorola, Inc., Semiconductor Products Sector
Lines: 78

Refinement of information:

Under release 10.1... 

While  a device is acquired, any program failing in any pad fails
to          produce          traceback          data           in
/sys/node_data/system_logs/proc_dump.   NOTHING  is  ever written
to the proc_dump file while a device is acquired no  matter  what
programs  fail  on  the  machine.   In  fact,  if  you delete the
proc_dump file, while aqdev is in effect, you will  see  that  no
attempt  is  ever  made  to  recreate  it  no matter what program
signals are generated.  (If the device is released and a  program
then  fails,  proc_dump  is  recreated  immediately  and contains
proper information concerning the failure.)

You can test this yourself.  Do "ld  -a  /dev",  look  for  "ddf"
files.  Here are some from our network:  

 char  ddf            2      2048  P    prwx-        dt2821
 char  ddf            2      2048  P    prwx-        dt2821F
 char  ddf            2      2048  P    prwx-        dt2821G
 char  ddf            2      2048  P    prwx-        dt2827
 char  ddf            2      2048  P    prwx-        dt2828
 char  ddf            2      2048  P    prwx-        pio_ddf
 char  ddf            2      2048  P    prwx-        sio2_ddf
 char  ddf            2      2048  P    prwx-        sio3_ddf
 char  ddf            2      2048  P    prwx-        exatape0

Use aqdev to acquire one of the "ddf" files, i.e.:

 $ aqdev /dev/sio2_ddf
 Device 4 acquired.  

While  acquired, you will see traceback and other debugging tools
that  depend  upon  sys/node_data/system_logs/proc_dump  rendered
useless. 

A ctrl z will release the device. 

 $ *** EOF *** 
 Device 4 released. 

Specific information regarding my node is:

Domain/OS  kernel(7),  revision  10.1.1.2, April 4, 1989  5:22:10
pm

  NODE CONFIGURATION
    Node Type:  DN3500
    Display type:  1024 x 800 color display
    68882 Floating Point Unit present. 
    Peripheral configuration:
        Disks:  winchester
        Networks: Ring
        Peripheral bus:  AT-bus
        Tapes:  none
    Disk types:  MSD-380M  -FA


I have a Data Translation DT-2823 digitizer  board  and  software
that  I  wrote  that  never  failed on release 9.7 but is failing
occasionally under release 10.1.  The board works  fine.   I  get
A/D  and D/A conversion as before but something is failing when I
take Fourier transforms of the  data  collected.   The  error  is
perhaps  because  of  the  new  unix-like libraries that are more
sensitive than the 9.7 Apollo  libraries.   (For  example  log(0)
under  9.7  yields  zero  -  under  10.1 log(0) yields "log: SING
error" and, if you get enough of  them,  eventually  aborts  your
program??)   Anyway  the  dt2821 device must be acquired in order
to run my program and the program aborts presumably  due  to  the
new  unix-like  libraries  but  it  is  difficult  to debug since
nothing is ever  written  to  sys/node_data/system_logs/proc_dump
while the device is acquired.  

Any  ideas  regarding how to get traceback data while a device is
acquired will be greatly appreciated. 

Howard C. Anderson   anderson@spanky.sps.mot.com