ndis0 interrrupt storm

Chris Whitehouse cwhiteh at onetel.com
Mon May 11 21:37:15 UTC 2009

Paul B. Mahol wrote:
> On 5/8/09, Chris Whitehouse <cwhiteh at onetel.com> wrote:
>> Paul B. Mahol wrote:
>>> On 5/7/09, Chris Whitehouse <cwhiteh at onetel.com> wrote:
>>>> In the meantime I've tried the three possible drivers (XP, NT and an
>>>> unlabelled one). I've also installed a recent 8-current snapshot,
>>>> updated to latest source and built world, and tried the XP driver. Still
>>>> get interrupt storms everywhere, also a panic (I think) in 8-current.
>>>> Should I give up or are there other things to try?
>>> Panic should not happen. Please provide backtrace(or crashdump or
>>> textdump)
>> `fetch http://www.fishercroft.plus.com/vmcore.1.gz' should get a
>> crashdump from a non-debug kernel, see below. It's about 17mb
>> I built a driver with the XP driver using ndisgen and the same source as
>> my recent build world.
>> I kldload the driver module which also loads ndis.ko and if_ndis.ko.
>> I've got
>> wlans_ndis0="wlan0"
>> in rc.conf and I get ndis0 and wlan0 created when I plug in the card.
>> The interrupt storm starts when I do
>> # ifconfig wlan0 <ip addr>
>> The panic occurs maybe a minute or two after the ifconfig.
>> I got a panic but I couldn't get a crashdump with the GENERIC kernel
>> (nothing relevant to dumpon or savecore happened at all, no boot
>> messages, nothing in /var/crash).
>> I did get a bunch of stuff on ttyv0, I can post a photo somewhere if
>> required. Or is there a way to get the screen output in text format?
>> I built a kernel with the following changes
>> #cpu            I486_CPU
>> #cpu            I586_CPU
>> #makeoptions    DEBUG=-g                # Build kernel with gdb(1) debug
> Oh nooooo, crash dump is useless with that option commented in kernel.
> [You can alway just look at documentation installed in /usr/share/doc/,
> for example developers handbook]
>> symbols
>> #options        KDB                     # Enable kernel debugger support.
>> #options        DDB                     # Support DDB.
>> #options        GDB                     # Support remote GDB.
>> #options        INVARIANTS              # Enable calls of extra sanity
>> checking
>> #options        INVARIANT_SUPPORT       # Extra sanity checks of
>> internal structures, required by INVARIANTS
>> #options        WITNESS                 # Enable checks to detect
>> deadlocks and cycles
>> #options        WITNESS_SKIPSPIN        # Don't run witness on spinlocks
>> for speed
> Both KDB, DDB, GDB, WITNESS and INVARIANTS are usefull in debugging kernel.
> So please uncomment all that debugging support.
> After all you can build two kernels, and use boot loader command or nextboot(8)
I tried with GENERIC and with my no-debug kernel. The panic happened 
with both but there was no crashdump with the GENERIC. All other 
settings were the same, eg no change to rc.conf. My setup seems to be 
right according to the developers handbook section 10.1.

Is there something special I have to do with -CURRENT to get the crashdump?

>> I got on ttyv0:
>> interrupt storm detected on "irq11:"; throttling interrupt source
>> repeated about 20 times then
>> Sleeping thread (tid 100084, pid 0) owns a non-sleepable lock
> Heh, thats is bug, now only remains to find where it is caused.
I got this screendump (copied and pasted) from ttyv0 before the panic 
with GENERIC. It was repeated maybe 20 times then dropped to db> prompt.

interrupt storm detected on "irq11:"; throttling interrupt source
Waiting on "KeWFS" with the following non-sleepable locks held:
exclusive sleep mutex ndis0 (network driver) r = 0 (0xc34fd06c) locked @ 
KDB: stack backtrace:
db_trace_self_wrapper(c0c40c0b,d40e3ac0,c089d245,c3888072,d68,...) at 
kdb_backtrace(c3888072,d68,ffffffff,c0eca774,d40e3af8,...) at 

_witness_debugger(c0c42f9c,d40e3b0c,4,1,0,...) at _witness_debugger+0x25
witness_warn(5,c38a24d0,c0c37d7c,c389ea81,d40e3b3c,...) at 
_cv_timedwait(d40e3b6c,c38a24d0,1389,ffffffff,c38cafc8,...) at 
KeWaitForSingleObject(c38cafc0,0,0,0,d40e3bbc,...) at 
ndis_set_info(c34fd000,d01011a,0,d40e3bf8,c37b2524,...) at 
ndis_scan_start(c3a14000,0,c0c5286b,36e,80246,...) at ndis_scan_start+0xe8
scan_task(c3a04800,1,c0c42357,54,c38c485c,...) at scan_task+0x150
taskqueue_run(c38c4840,c38c485c,0,c0c33ff4,0,...) at taskqueue_run+0x10b
taskqueue_thread_loop(c3a14074,d40e3d38,c0c39438,333,c0d88ca0,...) at 
fork_exit(c08963e0,c3a14074,d40e3d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xd40e3d70, ebp = 0 ---
interrupt storm detected on "irq11:"; throttling interrupt source

>> panic: sleeping thread
>> cpuid = 0
>> Uptime:17m26s
>> Physical memory: 434 MB
>> Dumping 79 MB: 64 48 32 16
>> Dump complete
>> (The above typed by hand)
>> Let me know if there is more I can do but (caveat) I'm not a developer
>> and I only put CURRENT on the machine to test if the problem had been
>> fixed, ie please don't flame me if you ask me really difficult stuff and
>> I don't understand it :)
> You can always ask me off list for anything that you don't understand.
thanks :)

More information about the freebsd-questions mailing list