wdavis@x102c.harris-atd.com (davis william 26373) (02/02/90)
I have a co-processor card and a device driver for it for A/UX. I am trying to debug the card (purchased) and driver (written by me). I am looking for something like kdb that can be used to poke around after a kernel panic. I am trying to debug a random kernel panic and cannot get enough information from the short message that panic prints out to the console. Interrupts can still occur because tracing in the driver indicates this (when I build tracing in). Has anyone out there done this? Where is 'kdb' that is in other versions of Unix. There is a file that can be built into the kernel for a 'debugger' driver. Does anyone know how to activate this? Thanks for any help.
dwb@archer.apple.com (David W. Berry) (02/02/90)
In article <3138@trantor.harris-atd.com> wdavis@x102c.harris-atd.com (davis william 26373) writes: >I have a co-processor card and a device driver for it for A/UX. >I am trying to debug the card (purchased) and driver (written >by me). I am looking for something like kdb that can be used >to poke around after a kernel panic. I am trying to debug a random >kernel panic and cannot get enough information from the short >message that panic prints out to the console. Interrupts >can still occur because tracing in the driver indicates >this (when I build tracing in). Has anyone out there done >this? Where is 'kdb' that is in other versions of Unix. >There is a file that can be built into the kernel for a >'debugger' driver. Does anyone know how to activate this? >Thanks for any help. As you have guessed, debugger is a module which can be configured into the kernel via "newunix debugger" Once installed, it is activated by pressing the interrupt switch on the side of your mac. Output and input is via the modem port, (or maybe it's the printer port, but I don't think so) Typing ? will get you a list of commands.
wdavis@x102c.harris-atd.com (davis william 26373) (02/03/90)
Thanks to everyone that sent instructions on using the modem port and NMI switch to access the debugger.o code when it is built into the kernel. With the debugger I was able to track the problem far enough to guess at what was wrong. Apparently, there is some problem with interrupt routines interacting with the floating point coprocessor. The panic I wad getting was an unexpected trap. The trap I was getting was 13 (the 68881 coprocessor interrupt?). It was coming in during the context switch that follows an interrupt routine that has done a wakeup() call. Since I don't use floating point in the driver, I used the -F option to the C compiler. This eliminated the save of floating point state at the front of each function and its restoration at the end of the function. I already knew from previous experience not to use the -O option on a driver. Perhaps someone at Apple would like to add these options to the Release Notes for the Device Driver Kit? Or maybe this is actually a latent bug in the A/UX support routines?