Re: r187880 causes fatal trap 30 when unloading drivers

On 2/17/09, Andrew Gallatin <gallatin_at_cs.duke.edu> wrote:
> I'm seeing a panic when I unload if_mxge.  I suspect it was caused by
> the recent change to allocate apic vectors on a per-CPU basis.
>
> I see the panic only when running an SMP kernel, and only on our 8-way
> opterons (a dual-core athlon64 is fine).  This is on a box with 2
> NICs.  Every time I unload my driver, 2 CPUs panic at the same time
> slightly after unloading the driver.  It occurs both when I use a
> single MSI, or legacy interrupts.  Untangling the garbled jibberish, I
> see this on console:
>
> Fatal trap 30: reserved (unknown) fault while in kernel mode
> cpuid = 2; apic id = 02
> instruction pointer     = 0x8:0xffffffff807ded46
> stack pointer               = 0x10:0xfffffffe40063b70
> frame pointer               = 0x10:0xfffffffe40063b80
> code segment                = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, IOPL = 0
> current process             = 11 (idle: cpu2)
> trap number             = 30
>
> Fatal trap 30: reserved (unknown) fault while in kernel mode
> cpuid = 1; apic id = 01
> instruction pointer     = 0x8:0xffffffff807ded46
> stack pointer               = 0x10:0xfffffffe40068b70
> frame pointer               = 0x10:0xfffffffe40068b80
> code segment                = base 0x0, limit 0xfffff, type 0x1b
>                         = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags        = interrupt enabled, IOPL = 0
> current process             = 11 (idle: cpu1)
> trap number             = 30
>
> I cannot get a dump, and ddb shows that it is sitting in the
> acpi acpi_cpu_c1() function.  I saw a similar report a
> little while back
> (http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003141.html).
> Following John's suggestion later in the thread, I tried backing
> out r187880, and I can again unload drivers.
>
> FWIW, I'm fairly certain the unhandled IRQ is not coming from the NIC.
> The NIC will not generate interrupts when it is not ifconfig'ed up.
> Given that, and how I usually see kldunload finish before the panic
> happens, I wonder if it might be a clock interrupt that is triggering
> the trap.
>
>
> Drew
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>

Me too, happens when zaping Xorg:

db:0:kdb.enter.unknown>  run lockinfodb:1:lockinfo> show
locksdb:1:locks>  show alllocksProcess 13 (acpi_thermal) thread
0xc3d88d80 (100024)db:1:alllocks>  show lockedvnodsLocked
vnodesdb:0:kdb.enter.unknown>  show pcpucpuid        = 1curthread    =
0xc3d08d80: pid 10 "idle: cpu1"curpcb       = 0xc399ed90fpcurthread  =
noneidlethread   = 0xc3d08d80: pid 10 "idle: cpu1"APIC ID      =
1currentldt   = 0x50spin locks held:db:0:kdb.enter.unknown>  bt
Tracing pid 10 tid 100002 td
0xc3d08d80acpi_cpu_c1(1,c399ec88,c399ecd8,1,0,...) at
acpi_cpu_c1+0x5acpi_cpu_idle(c399ecb4,c05d1b75,1,c399ecf8,c04c1435,...)
at acpi_cpu_idle+0x186cpu_idle_acpi(1,c399ecf8,c04c1435,1,c399ecd8,...)
at cpu_idle_acpi+0x1bcpu_idle(1,c399ecd8,c060671c,a0b,c3d08d80,...) at
cpu_idle+0x1bsched_idletd(0,c399ed38,c0600bf0,32d,c3d06d34,...) at
sched_idletd+0x216fork_exit(c04c121f,0,c399ed38) at
fork_exit+0xb8fork_trampoline() at fork_trampoline+0x8


Fatal trap 30: reserved (unknown) fault while in kernel modecpuid = 1;
apic id = 01instruction pointer     = 0x20:0xc096d23cstack pointer
      = 0x28:0xc399ec70frame pointer           = 0x28:0xc399ec70code
segment            = base 0x0, limit 0xfffff, type 0x1b
        = DPL 0, pres 1, def32 1, gran 1processor eflags        =
interrupt enabled, IOPL = 0current process         = 10 (idle:
cpu1)exclusive sx ACPI embedded controller (ACPI embedded controller)
r = 0 (0xc097e130) locked _at_
/usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_ec.c:210


The only workaroud is to disable SMP.
-- 
Paul