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.Received on Sat Jun 14 2014 - 07:36:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:50 UTC