Date: Sat, 14 Jun 2014 11:36:48 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@FreeBSD.org> To: David Wolfskill <david@catwhisker.org>, Adrian Chadd <adrian@freebsd.org>, Stefan Parvu <sparvu@systemdatarecorder.org>, freebsd-current <freebsd-current@freebsd.org> Subject: Re: iwn driver issue Message-ID: <20140614093648.GA1428@brick.home> In-Reply-To: <20140613195104.GB1180@albert.catwhisker.org> References: <20140613112624.bef131c3b84e5e4ad38ed84f@systemdatarecorder.org> <20140613163644.GA1291@brick.home> <20140613165216.GZ1180@albert.catwhisker.org> <CAJ-Vmo=ghNVCAPR7pHWJgoufp9ArOHpvD01GwP3H-PX5JQVQMg@mail.gmail.com> <20140613175819.GA1180@albert.catwhisker.org> <20140613193635.GC1607@brick.home> <20140613195104.GB1180@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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<enter>"). > > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140614093648.GA1428>