From owner-freebsd-current@FreeBSD.ORG Sat Jun 14 09:36:55 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E816FF7B; Sat, 14 Jun 2014 09:36:54 +0000 (UTC) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52A132F8D; Sat, 14 Jun 2014 09:36:54 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id cc10so3288184wib.3 for ; Sat, 14 Jun 2014 02:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=BR1TzHCc9lMwDGUv3/QVzoR10WfnEtTq/dvslEMD0cw=; b=p+YvTU/TvAbNIUrwbRdqDo1ZcAf082u+3Zg19rpXx3zHVoAcdrc/5HvQQsb/G94yfk kFF2zj/Tzw8yoKp/U/whWfaZxbcKPuCo6ukYMU1bztzSaBrqi1i3QlWhBMF2WTcZg9O9 kQiu4LMuCPW6xaGKek+xe0f8XoNAcdvINYxWSR7vzIb83ZsI4Xv6bTv65BzX3Bl9tnzu KqaWKZCoGsY2g3jbqnLU1pYGQVS1YpJv5Cu5EDf/DmHqXlSxg+K/pvyC38IYWXbuCXkC JPOpqx+3cHPbA1BbWYIRLHoQYK3Jn57M/43yKhnqGg5jzvJmEuFyvT9ahgI7zQm9G/qL YCGg== X-Received: by 10.194.189.137 with SMTP id gi9mr5586760wjc.31.1402738611532; Sat, 14 Jun 2014 02:36:51 -0700 (PDT) Received: from brick.home (abwp17.neoplus.adsl.tpnet.pl. [83.8.239.17]) by mx.google.com with ESMTPSA id g9sm4107803eew.9.2014.06.14.02.36.50 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jun 2014 02:36:50 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 14 Jun 2014 11:36:48 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: David Wolfskill , Adrian Chadd , Stefan Parvu , freebsd-current Subject: Re: iwn driver issue Message-ID: <20140614093648.GA1428@brick.home> Mail-Followup-To: David Wolfskill , Adrian Chadd , Stefan Parvu , freebsd-current References: <20140613112624.bef131c3b84e5e4ad38ed84f@systemdatarecorder.org> <20140613163644.GA1291@brick.home> <20140613165216.GZ1180@albert.catwhisker.org> <20140613175819.GA1180@albert.catwhisker.org> <20140613193635.GC1607@brick.home> <20140613195104.GB1180@albert.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140613195104.GB1180@albert.catwhisker.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jun 2014 09:36:55 -0000 On 0613T1251, David Wolfskill wrote: > On Fri, Jun 13, 2014 at 09:36:35PM +0200, Edward Tomasz Napiera??a wrote: > > ... > > > I normally don't spend a huge amount of time in head -- enough to build > > > it & do a quick smoke-test. So it's certainly possible that it merits > > > further exploration. And I'm willing experiment, but I cannot test it > > > while I'm at work (as I don't use the wireless NIC at work -- I use it > > > almost exclusively while I'm at home (and other places), though). > > > > It would be great if you could help me with this. Basically you need > > to enable crashdumps, as described below, and obtain a backtrace. > > > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html > > I have had crash dumps on panics running head (slice 4 of the boot > device, in my case) in the past, so that process works. I just didn't > get a dump this morning. :-( > > d130(9.3)[1] grep dump /S4/etc/rc.conf > dumpdev="AUTO" > d130(9.3)[2] Hm. Well, if it fails the second time then I guess I'll just add a sysctl to disable the fix. But let's try to get a crashdump anyway :-) > > Just for the record, the easiest way to make iwn firmware panic > > is to enter ddb (ctrl-alt-esc), wait five seconds and exit it > > ("c"). > > Does that process yield useful information? (That is, is that process > sufficiently similar to a sequence of events that occurs in the real > world that the resulting information may be used to figure out how to > make the code avoid misbehavior?) Well, it triggers the iwn firmware panic, which in turn triggers the code I've attached, which apparently causes kernel panic. But I cannot guarantee that it _will_ trigger the problem. > If so, I can try that soonish (e.g., en route home today, once I've > boarded the train -- vs. while I'm still on my bike :-}). Thanks. Even just replying to emails whilst on bike is impressive, especially with mutt.