iwn driver issue

[Edward Tomasz Napierała]

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.