Re: panic: apic_free_vector: Thread already bound.

From: Attilio Rao <attilio_at_freebsd.org>
Date: Mon, 31 Aug 2009 22:31:50 +0200
2009/8/31 Marc UBM <ubm_at_u-boot-man.de>:
> On Mon, 24 Aug 2009 16:31:05 -0400
> John Baldwin <jhb_at_freebsd.org> wrote:
>
>> On Saturday 22 August 2009 5:59:58 am Marc UBM wrote:
>> >
>> > Hiho! :-)
>> >
>> > I'm seeing above panic in the final stages of the shutdown process.
>> > Coredump is available, bt as follows, textdump attached.
>> >
>> >
>> > FreeBSD hamstor 8.0-BETA2 FreeBSD 8.0-BETA2 #14: Wed Aug 19 22:43:17
>> > CEST 2009     oni0_at_hamstor:/usr/obj/usr/src/sys/HAMSTOR  amd64
>> >
>> >
>> > (kgdb) bt
>> > #0  doadump () at pcpu.h:223
>> > #1  0xffffffff801b561c in db_fncall (dummy1=Variable "dummy1" is not
>> > #available.
>> > ) at /usr/src/sys/ddb/db_command.c:548
>> > #2  0xffffffff801b5951 in db_command (last_cmdp=0xffffffff808594a0,
>> > #cmd_table=Variable "cmd_table" is not available.
>> > ) at /usr/src/sys/ddb/db_command.c:445
>> > #3  0xffffffff801b5ba0 in db_command_loop ()
>> > #at /usr/src/sys/ddb/db_command.c:498 4  0xffffffff801b7b69 in
>> > #db_trap (type=Variable "type" is not available.
>> > ) at /usr/src/sys/ddb/db_main.c:229
>> > #5  0xffffffff8038d775 in kdb_trap (type=3, code=0,
>> > #tf=0xffffff8000017760) at /usr/src/sys/kern/subr_kdb.c:535 6
>> > #0xffffffff8060e170 in trap (frame=0xffffff8000017760)
>> > #at /usr/src/sys/amd64/amd64/trap.c:611 7  0xffffffff805f3b23 in
>> > #calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 8
>> > #0xffffffff8038d94d in kdb_enter (why=0xffffffff80681954 "panic",
>> > #msg=0xa <Address 0xa out of bounds>) at cpufunc.h:63 9
>> > #0xffffffff8035e04b in panic (fmt=Variable "fmt" is not available.
>> > ) at /usr/src/sys/kern/kern_shutdown.c:562
>> > #10 0xffffffff805fafbb in apic_free_vector (apic_id=Variable
>> > #"apic_id" is not available.
>> > ) at /usr/src/sys/amd64/amd64/local_apic.c:995
>> > #11 0xffffffff805f7560 in intr_remove_handler (cookie=Variable
>> > #"cookie" is not available.
>> > ) at /usr/src/sys/amd64/amd64/intr_machdep.c:203
>> > #12 0xffffffff806250d4 in hpt_shutdown_vbus
>> > #(vbus_ext=0xffffff8000254000, howto=Variable "howto" is not
>> > #available.
>> > ) at /usr/src/sys/dev/hptrr/hptrr_osm_bsd.c:361
>> > #13 0xffffffff8035da8b in boot (howto=16392)
>> > #at /usr/src/sys/kern/kern_shutdown.c:419 14 0xffffffff8035e126 in
>> > #reboot (td=Variable "td" is not available.
>> > ) at /usr/src/sys/kern/kern_shutdown.c:173
>> > #15 0xffffffff8060dbba in syscall (frame=0xffffff8000017c80)
>> > #at /usr/src/sys/amd64/amd64/trap.c:982 16 0xffffffff805f3e01 in
>> > #Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:373 17
>> > #0x000000000040892c in ?? ()
>> > Previous frame inner to this frame (corrupt stack?)
>> >
>> > frame #12 & #13 make me suspect the hptrr driver (again :-)), but
>> > I'm not sure.
>>
>> Ah, any driver shutting off its interrupt handler during shutdown
>> would actually trigger this.  The hptrr driver doesn't really need to
>> do this during shutdown, but I think we don't want to panic in this
>> case. Unfortunately we don't currently have a "in_shutdown" type of
>> global flag that we can check in apic_free_vector() to not worry
>> about the thread already being bound.
>
> Is there any chance this fix might make it into 8.0? It's not a real
> problem for me since I can just power-off by force, but I imagine it
> might be a real pita for people who only have remote access and want
> to reboot, etc.

Maybe we can ship 8 with a printf() instrad than a panic()?

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein
Received on Mon Aug 31 2009 - 18:31:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:54 UTC