Date: Wed, 18 Feb 2009 11:56:52 +0100 From: "Paul B. Mahol" <onemda@gmail.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: current@freebsd.org Subject: Re: r187880 causes fatal trap 30 when unloading drivers Message-ID: <3a142e750902180256p68ef8fc0nbda773d41d42a7a0@mail.gmail.com> In-Reply-To: <20090217142615.A77950@grasshopper.cs.duke.edu> References: <20090217142615.A77950@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/17/09, Andrew Gallatin <gallatin@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@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 @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_ec.c:210 The only workaroud is to disable SMP. -- Paul
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a142e750902180256p68ef8fc0nbda773d41d42a7a0>