[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference hydra::axp-developer

Title:	Alpha Developer Support
Notice:	[email protected], 800-332-4786
Moderator:	HYDRA::SYSTEM

Created:	Mon Jun 06 1994
Last Modified:	Fri Jun 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3722
Total number of notes:	11359

3583.0. "Autometric" by HYDRA::AMORELLI () Mon May 05 1997 15:34

    Company Name :  Autometric
    Contact Name :  Nancy Kusnierz
    Phone        :  (207)945-6353
    Fax          :  
    Email        :  
    Date/Time in :  5-MAY-1997 13:28:20
    Entered by   :  Carl Amorelli
    SPE center   :  MRO

    Category     :  unix
    OS Version   :  4.0b
    System H/W   :  Alphaserver 500


    Brief Description of Problem:
    -----------------------------

    New installation of Digital Unix 4.0b on loaner system. System crashes
    when running dbx or Ladebug. All langauges tested fail: Fortran, C, C++.

    $dbx <program-name>
    (dbx) run

T.R	Title	User	Personal Name	Date	Lines
3583.1	Been there, done that (note 3457 in this conference)	HYDRA::NEWMAN	Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26	`Mon May 05 1997 16:56`	43
	<<< HYDRA::DISK_NOTES$LIBRARY:[000000]AXP-DEVELOPER.NOTE;1 >>> -< Alpha Developer Support >- ================================================================================ Note 3457.1 Khoral Research, Inc. 1 of 5 HYDRA::NEWMAN "Chuck Newman, 508/467-5499 (DTN 297), MRO1-3/F26" 34 lines 9-APR-1997 10:58 -< Looks like a known problem with kernel parameter db_enable >- -------------------------------------------------------------------------------- <<< TURRIS::DISK$NOTES_PACK2:[NOTES$LIBRARY]DIGITAL_UNIX.NOTE;1 >>> -< DIGITAL UNIX (FORMERLY KNOWN AS DEC OSF/1) >- ================================================================================ Note 8562.1 system crash when using dbx on V4.0B 1 of 2 QUARRY::petert "rigidly defined areas of doubt and uncertainty" 26 lines 23-JAN-1997 12:02 -< Been QAR'd as a showstopper, workaround explained below. >- -------------------------------------------------------------------------------- This is a known kernel problem. I imagine people are working on it as I've filed a show stopper on it. But, in the meantime... This will only happen on a system that is built with KDEBUG set up in the kernel config file, /sys/conf/XXXX where XXXX is the uppercase system name. The problem has to do with the kernel variable db_enable. This is a relatively new kernel variable, and gets set to 1 when KDEBUG is configured. You can resolve this by going into ladebug or dbx as superuser and doing the following dbx -k /vmunix /* or whatever you are running as the OS assign db_enable = 0 and then quit. This will take care of the current session, but db_enable will be reset if you have to reboot. To take care of that: dbx /vmunix /* no -k this time, we want the disk version... patch db_enable = 0 and you'll be set for the life of this particular kernel. Note that you'll have to do this all over again if you rebuild the kernel and leave KDEBUG set. As I found out this morning. Sigh.... PeterT
3583.2		HYDRA::AMORELLI		`Tue May 06 1997 12:12`	44
	From: HYDRA::AMORELLI 5-MAY-1997 17:24:03.45 To: US6RMC::"[email protected]" CC: AMORELLI Subj: Work-around for Ladebug bug Nancy, After looking around awhile, I'm still not sure the patches we discussed would help. In the meantime, here are a few work-arounds. Regards, Carl --------- From the developers. There are three easy workarounds for this: 1. Comment out options KDEBUG in /usr/sys/conf/SYSTEM-NAME: #options KDEBUG 2. As root: Fix the running kernel: . # dbx -k /vmunix . (dbx) a db_enable = 0 . (dbx) q Fix the on-disk kernel image, in case of reboots: . # dbx /vmunix . (dbx) patch db_enable = 0 . (dbx) q 3. Yet another workaround is: Add the following to the /etc/sysconfigtab as a workaround. kdebug: kdebug_saveterm = 0