Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jul 2002 14:14:06 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Andrew Gallatin <gallatin@cs.duke.edu>
Cc:        freebsd-current@freebsd.org
Subject:   Re: panic: absolutely cannot call smp_ipi_shootdown with interrupts already disabled 
Message-ID:  <20020715211406.451A43811@overcee.wemm.org>
In-Reply-To: <15667.13541.978257.347017@grasshopper.cs.duke.edu> 

next in thread | previous in thread | raw e-mail | index | archive | help
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.  We could not
get the 'ack' from the IPI.  The panic was real - you'd have locked up hard
if it had not triggered.

db_write_bytes temporarily changes a local cpu mapping and changes it back
while everything else is frozen.  We do not need to do a coherent invalidate.

--- i386/i386/db_interface.c      12 Jul 2002 07:56:08 -0000      1.66
+++ i386/i386/db_interface.c      15 Jul 2002 21:09:38 -0000
@@ -276,7 +276,7 @@
                }
            }
 
-           pmap_invalidate_all(kernel_pmap);
+           invltlb();
        }
 
        dst = (char *)addr;
@@ -292,7 +292,7 @@
            if (ptep1)
                *ptep1 = oldmap1;
 
-           pmap_invalidate_all(kernel_pmap);
+           invltlb();
        }
 }

Andrew Gallatin wrote:
> 
> I was attempting to set a breakpoint; upon continuation, the kernel
> panic'ed with:
> 
> gm0: <Myrinet PCI interface> mem 0xfb000000-0xfbffffff irq 11 at
> device 1.0 on pci1
> 
> Debugger("here") # breakpoint I put in my module's load path
> 
> Stopped at      Debugger+0x55:  xchgl   %ebx,in_Debugger.0
> db> break generic_bzero
> db> c
> panic: absolutely cannot call smp_ipi_shootdown with interrupts
> already disabled
> cpuid = 1; lapic.id = 01000000
> boot() called on cpu#1
> 
> syncing disks... panic: bremfree: bp 0xce67d2b4 not locked
> cpuid = 1; lapic.id = 01000000
> boot() called on cpu#1
> Uptime: 2m9s
> Dumping 511 MB
> 
> 
> The stack looks like this (apologies for formatting errors).
> 
> 
> 
> (kgdb) where
> #0  doadump () at ../../../kern/kern_shutdown.c:213
> #1  0xc01df7b6 in boot (howto=260) at
> ../../../kern/kern_shutdown.c:345
> #2  0xc01dfa44 in panic () at ../../../kern/kern_shutdown.c:491
> #3  0xc021fa77 in bremfree (bp=0xce67d2b4) at
> ../../../kern/vfs_bio.c:633
> #4  0xc0221498 in vfs_bio_awrite (bp=0x3) at
> ../../../kern/vfs_bio.c:1627
> #5  0xc01afde5 in spec_fsync (ap=0xda0e885c)
>     at ../../../fs/specfs/spec_vnops.c:403
> #6  0xc01af908 in spec_vnoperate (ap=0x0)
>     at ../../../fs/specfs/spec_vnops.c:121
> #7  0xc02a1aca in ffs_sync (mp=0xc157bc00, waitfor=2, cred=0xc1571f00,
>     td=0xc03669e0) at vnode_if.h:463
> #8  0xc02310f8 in sync (td=0xc03669e0, uap=0x0)
>     at ../../../kern/vfs_syscalls.c:127
> #9  0xc01df3cb in boot (howto=256) at
> ../../../kern/kern_shutdown.c:254
> #10 0xc01dfa44 in panic () at ../../../kern/kern_shutdown.c:491
> #11 0xc02f33db in smp_tlb_shootdown (vector=0, addr1=0, addr2=0)
>     at ../../../i386/i386/mp_machdep.c:2260
> #12 0xc02f361b in smp_invltlb () at
> ../../../i386/i386/mp_machdep.c:2366
> #13 0xc02f574d in pmap_invalidate_all (pmap=0x1)
>     at ../../../i386/i386/pmap.c:677
> #14 0xc02e3123 in db_write_bytes (addr=3224341392, size=1, 
>     data=0xda0e89ac "\2158 \2158\211\016 ")
>     at ../../../i386/i386/db_interface.c:279
> ---Type <return> to continue, or q <return> to quit---
> #15 0xc0142121 in db_put_value (addr=0, size=0, value=0)
>     at ../../../ddb/db_access.c:98
> #16 0xc01423a7 in db_set_breakpoints () at ../../../ddb/db_break.c:191
> #17 0xc0144dc4 in db_restart_at_pc (watchpt=0) at
> ../../../ddb/db_run.c:209
> #18 0xc01456b6 in db_trap (type=3, code=0) at
> ../../../ddb/db_trap.c:75
> #19 0xc02e2edd in kdb_trap (type=3, code=0, regs=0xda0e8a8c)
>     at ../../../i386/i386/db_interface.c:161
> #20 0xc02fa427 in trap (frame=
>       {tf_fs = -1051262952, tf_es = -1001979888, tf_ds = -1051262960,
> tf_edi = -1051203200, tf_esi = -1001936896, tf_ebp = -636581160,
> tf_isp = -636581192, tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 17,
> tf_trapno = 3, tf_err = 0, tf_eip = -1070714411, tf_cs = 8, tf_eflags
> = 646, tf_esp = -1070279997, tf_ss = -1001622092}) at
> ../../../i386/i386/trap.c:604
> #21 0xc02e4678 in calltrap () at {standard input}:99
> #22 0xc44bb7e8 in ?? ()
> #23 0xc44bfefb in ?? ()
> #24 0xc44bf864 in ?? ()
> #25 0xc44bb11a in ?? ()
> #26 0xc01f10bf in device_probe_and_attach (dev=0x0) at device_if.h:39
> #27 0xc01f1e1e in bus_generic_driver_added (dev=0xc157ea80,
> driver=0xc44f2128)
>     at ../../../kern/subr_bus.c:1449
> #28 0xc01efd05 in devclass_add_driver (dc=0xc156dc80,
> driver=0xc44f2128)
>     at bus_if.h:71
> #29 0xc01f2e45 in driver_module_handler (mod=0xc4262940, what=0, 
>     arg=0xc44f2144) at ../../../kern/subr_bus.c:1810
> #30 0xc01d4ec1 in module_register_init (arg=0xc44f215c)
>     at ../../../kern/kern_module.c:107
> #31 0xc01cf670 in linker_file_sysinit (lf=0x0)
>     at ../../../kern/kern_linker.c:192
> #32 0xc01cf936 in linker_load_file (filename=0xc036ce90 " +3@tf_esp =-1077938
    260, tf_ss = 47})
>     at ../../../i386/i386/trap.c:1049
> #36 0xc02e46ad in syscall_with_err_pushed () at {standard input}:129
> 
> 
> Cheers,
> 
> Drew
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-current" in the body of the message
> 

Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020715211406.451A43811>