Date: Fri, 01 Mar 1996 13:53:27 -0800 From: Paul Traina <pst@shockwave.com> To: questions@freebsd.org Cc: hackers@freebsd.org Subject: using ddb to debug a double-panic? Message-ID: <199603012153.NAA00721@precipice.shockwave.com>
next in thread | raw e-mail | index | archive | help
I'm seeing something -very- strange while working on a device driver. When I add a delay to some code that's doing direct I/O to the parallel port, I get a system hang (but I can pop out to ddb and look at things, however ddb is showing that I'm just waiting in the idle loop). It seems like something is going to sleep on a system resource and never coming back. So, I figured, what the heck, I'd add a couple of kernel printfs in strategic places so I could find out where it was actually hanging (I didn't feel like doing breakpoints). I -thought- our kernel printf was supposed to be safe to use. I'm not at raised IPL and I don't believe I'm overflowing the stack anywhere, but without fail, I get a perfectly reproducable double-panic which takes me out to DDB. Now, the question I'm asking is: Could someone give me a leg-up on tracking the original problem that caused the first panic to occur? Obviously, the stack/frame pointer from the double panic point to the panic code, but the original stuff does (?) get saved somewhere. Is there a simple sequence I can type into ddb to switch stack pointers and frames so I can do a "where" to see where I was when the first panic occured? Thanks, a confused Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199603012153.NAA00721>