Date: Fri, 04 May 2007 14:50:06 -0600 From: Scott Long <scottl@samsco.org> To: John Baldwin <jhb@freebsd.org> Cc: attilio@freebsd.org, freebsd-current@freebsd.org, Harald Schmalzbauer <h.schmalzbauer@omnisec.de> Subject: Re: PANIC: blockable slep lock (sx) msi @ ....msi.c:374 Message-ID: <463B9C7E.2080901@samsco.org> In-Reply-To: <200705041637.38955.jhb@freebsd.org> References: <463B7A1D.6020602@omnisec.de> <200705041546.50690.jhb@freebsd.org> <463C01B4.9050802@FreeBSD.org> <200705041637.38955.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote: > On Saturday 05 May 2007 12:01:56 am Attilio Rao wrote: >> John Baldwin wrote: >>> On Friday 04 May 2007 10:53:27 pm Attilio Rao wrote: >>>> Harald Schmalzbauer wrote: >>>>> Hello, >>>>> >>>>> recent changes (during the last 2 days,I guess tha acpi stuff) broke >>>>> -current for me: >>>>> >>>>> ad6: 476940MB <WDC WD5000KS-07MNB0 07.02E07> at ata3-master SATA300 >>>>> SMP: AP CPU #1 Launched! >>>>> panic: blockable sleep lock (sx) msi @ >>>>> /FlashBSD/src/sys/i386/i386/msi.c:374 >>>>> cpuid = 0 >>>>> KDB: enter: panic >>>>> [thread pid 0 tid 0 ] >>>>> Stopped at kdb_enter+0x30: leave >>>>> db> bt >>>>> Tracing pid 0 tid 0 td 0xc07c2d60 >>>>> kdb_enter(c07422df,0,c0746e47,c1420bdc,c07c2d60,...) at kdb_enter+0x30 >>>>> panic(c0746e47,c073180d,c0732bb2,c0764c8e,176,...) at panic+0x135 >>>>> witness_checkorder(c082f0fc,1,c0764c8e,176,c55c0980,...) at >>>>> witness_checkorder+0xd6 >>>>> _sx_slock(c082f0fc,c0764c8e,176,c1420c64,c06f7e65,...) at _sx_slock+0x5f >>>>> msi_map(100,c1420d08,c1420d04,c1420c94,c04b5cc5,...) at msi_map+0x22 >>>>> nexus_map_msi(c5552000,c55e4000,100,c1420d08,c1420d04,...) at >>>>> nexus_map_msi+0x1f >>>>> pcib_map_msi(c55d9080,c55e4000,100,c1420d08,c1420d04,...) at >>>>> pcib_map_msi+0x86 >>>>> pcib_map_msi(c55e4200,c55e4000,100,c1420d08,c1420d04,...) at >>>>> pcib_map_msi+0x86 >>>>> pci_remap_msi_irq(c55e4000,100,c06ecb73,c54fff78,100,...) at >>>>> pci_remap_msi_irq+0xeb >>>>> msi_assign_cpu(c55e6240,0,100,c079d170,c1420d70,...) at >>> msi_assign_cpu+0x68 >>>>> intr_assign_next_cpu(c55e6240,0,c07631d3,1c7,c54f3a44,...) at >>>>> intr_assign_next_cpu+0x23 >>>>> intr_shuffle_irqs(0,141e000,141ec00,141e000,0,...) at >>>>> intr_shuffle_irqs+0x5e >>>>> mi_startup() at mi_startup+0xa0 >>>>> begin() at begin+0x2c >>>> In this case the culprit is intr_table_lock spinlock I think. >>>> This can be fixed switching the msi lock to be a spinlock instead than a >>>> sx lock. >>> Actually, I think the real fix is I need to better handle the locking for >>> assigning interrupts to CPUs. >> I have a question. >> Why you currently use a sx lock? There are places where msi functions >> can sleep? > > malloc M_WAITOK, and considering how rarely this stuff is called (just during > attach routines for drivers during boot) I didn't consider it important > enough to do something more complicated. > Well, you were just using it as a hack around a WITNESS warning ;-) I think it's OK for memory allocations to fail in this kind of code, so long as the failure is propagated to the caller. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?463B9C7E.2080901>