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