At 4:47 PM -0700 2003/09/17, Doug White wrote:
This came up at the developer summit. We do need to upgrade/make
significant changes to gdb for it to understand threaded debugging. The
panics might be interesting as it might be tickling other issues, but
before we can really debug threaded
On Thu, 18 Sep 2003, Brad Knowles wrote:
At 4:47 PM -0700 2003/09/17, Doug White wrote:
This came up at the developer summit. We do need to upgrade/make
significant changes to gdb for it to understand threaded debugging. The
panics might be interesting as it might be tickling other
On Tue, 16 Sep 2003, Morten Rodal wrote:
So this brings up the question, is there a known problem with
debugging multi-threaded applications (which use libkse) that can
cause a panic? I will bring home my laptop, and will be able to use a
serial debugger if that would help anyone willing to
show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
panic messages:
---
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
cpuid = 0; lapic.id = 0100
Stack
cannot call smp_ipi_shootdown with interrupts already disabled
panic messages:
---
panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled
cpuid = 1; lapic.id =
Stack backtrace:
boot() called on cpu#1
syncing disks, buffers remaining... panic: absolutely cannot call
Peter Wemm writes:
Eww! Care to confirm that the following works? I was going to just commit
it since it is pretty obvious, but a brief sanity check would probably
be an idea. (beware, xterm cut/paste whitespace damage).
ddb runs with interrupts disabled and the other cpus halted.
