Re: PANIC: blockable slep lock (sx) msi _at_ ....msi.c:374

On Friday 04 May 2007 04:50:06 pm Scott Long wrote:
> 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 _at_ 
> >>>>> /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.

Do you really expect bus_alloc_resource()-type things to fail to attach a 
driver instead of waiting for the system to free up some memory?  Most of 
that sort of thing is quite resilient right now, and I'm hesitant to make the 
system start breaking things instead of waiting when memory runs low.

-- 
John Baldwin