ndis0 interrrupt storm

Tue May 12 10:22:49 UTC 2009

On 5/11/09, Chris Whitehouse <cwhiteh at onetel.com> wrote:
> 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?

Just typing bt on db prompt for now should be enough.
>
>>>
>>>
>>> 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 @
> /usr/sr
> c/sys/modules/if_ndis/../../dev/if_ndis/if_ndis.c:3432
> KDB: stack backtrace:
> db_trace_self_wrapper(c0c40c0b,d40e3ac0,c089d245,c3888072,d68,...) at
> db_trace_s
> elf_wrapper+0x26
> kdb_backtrace(c3888072,d68,ffffffff,c0eca774,d40e3af8,...) at
> kdb_backtrace+0x29
>
> _witness_debugger(c0c42f9c,d40e3b0c,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,c38a24d0,c0c37d7c,c389ea81,d40e3b3c,...) at
> witness_warn+0x1fd
> _cv_timedwait(d40e3b6c,c38a24d0,1389,ffffffff,c38cafc8,...) at
> _cv_timedwait+0xc
> 6
> KeWaitForSingleObject(c38cafc0,0,0,0,d40e3bbc,...) at
> KeWaitForSingleObject+0x1b
> 0
> ndis_set_info(c34fd000,d01011a,0,d40e3bf8,c37b2524,...) at
> ndis_set_info+0x1c8
> 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
> taskqueue_
> thread_loop+0x68
> 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

Thats is something.
>>> 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 :)

-- 
Paul