Conference turris::digital_unix

8608.0. "DU40B and EV45 crash." by SEPPLT::MARK (Mark Garrett) Tue Jan 28 1997 01:50

I have a problem that maybe a bug. Could any one with a 1000A 4/266 or maybe 
any machine with a ev45 processor and Digital UNIX 4.0B to do the following

compile a simple program . When I do this on my 1000A 266 it panic's with

_panic_string:  0xfffffc00005f3cd8 = "trap: illegal instruction"
If you want to see the full text of the crash-data

ftp://nonull.sno.dec.com/pub/ned/crash-data.1


I'd like some one with similar hardware to try this. I sort of hope to to the 
same feature?

I even tried taking the firmware back to the 3.7CD which was feature compatible
:(


eg.
cc -g test.c -o tst
dbx tst
(dbx) stop in main
(dbx) run < test.c

/* test.c */

#include <stdio.h>

main()
{
        char    buf[1024];

        int     i=0;

        while ( !feof(stdin) && ( i < 1024 )) {
                buf[i] = fgetc( stdin);
                i++;
        }
        fprintf(stdout, "%s\n", buf);
}

Sigh...

Do this to determine if you are running into this (to me) infamous bug.
su

dbx -k /vmunix
p db_enable

if db_enable is set to 1, then you have most likely built the kernel
with KDEBUG set.  This in turn sets db_enable to 1.  Somewhere in the 
kernel, db_enable is causing the system to crash as it takes a path
it would not take if db_enable were 0.

The workaround -  set db_enable to 0.

To fix the running kernel

dbx -k /vmunix
assign db_enable = 0

To fix the disk copy (so you don't have to redo the live kernel after a reboot)

dbx /vmunix          /* Important!  No -k here
patch db_enable = 0

And you'll be all set.  QAR 50184 has been entered, but I don't know of 
the current status.

PeterT

    Not yet.  This still crashes my machine after installing the fix.
    I'll be working with the kernel developer on this, lending him
    my machine to ferret this out.
    
    PeterT