From owner-freebsd-questions@FreeBSD.ORG Tue May 12 10:22:48 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8237106564A for ; Tue, 12 May 2009 10:22:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 511058FC12 for ; Tue, 12 May 2009 10:22:47 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by bwz9 with SMTP id 9so3228482bwz.43 for ; Tue, 12 May 2009 03:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=cNdd8D7DY22Tp8KLgIe+6T9u0Pp9Ky0HUmMUHiW/9Lo=; b=DkH6ciasv/YOX5M6733KB6LTlP2MQOYXcS258e4UU5rRcv8AJ5g7sY0C4uJVGKzxB1 zfpHF3bQBD9JndlgzdD/0JDQBPIUzNTUl/bQb3g94LPxtmnqzEgShVi5UK2QWzIlTyd2 q9NOUslO4HSJ2VPddYa44wsm7vFcp+3Akfm1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sM+bq0tuSvXWchDRHL6aPF0kMYQ8JG3hQ/z5wNQ/2SQuRWIkly5xObGJPNfL6uCJYJ YIiew3tNEPx3G01ZMMqKULNwvToHPwx83KEhD5FXtwdtuY3tsfM1xfCsO5aV+ROqmzjJ /uQI0i6ynshpfos9tgoN02uz3u31Bh7v4P6SY= MIME-Version: 1.0 Received: by 10.239.137.84 with SMTP id k20mr584484hbk.21.1242123766533; Tue, 12 May 2009 03:22:46 -0700 (PDT) In-Reply-To: <4A089A87.8040800@onetel.com> References: <49F78DD0.70007@onetel.com> <3a142e750904290530p7189e3d2y40328186dd4141f7@mail.gmail.com> <49FB6C6A.8020308@onetel.com> <3a142e750905011711pc9c77f7p67e883e96fac7170@mail.gmail.com> <4A03528F.7070405@onetel.com> <3a142e750905080326q2c21e669xc08aaafbf0fbf36@mail.gmail.com> <4A04968E.5060203@onetel.com> <3a142e750905090742i4bf80d45n323a81d3e18223a@mail.gmail.com> <4A089A87.8040800@onetel.com> Date: Tue, 12 May 2009 12:22:46 +0200 Message-ID: <3a142e750905120322h2eb984a6q786ad99287ae2cbb@mail.gmail.com> From: "Paul B. Mahol" To: Chris Whitehouse Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: User Questions Subject: Re: ndis0 interrrupt storm X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2009 10:22:49 -0000 On 5/11/09, Chris Whitehouse wrote: > Paul B. Mahol wrote: >> On 5/8/09, Chris Whitehouse wrote: >>> Paul B. Mahol wrote: >>>> On 5/7/09, Chris Whitehouse 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 >>> >>> 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