Re: Poking ieee80211_default_rc_algo causes kernel lockups

[Sitsofe Wheeler <sitsofe@yahoo.com>]

> From: Frederic Weisbecker <fweisbec@gmail.com>

> 
> On Sun, Feb 15, 2009 at 11:24:41AM -0800, Sitsofe Wheeler wrote:
> > > Could you please enable the CONFIG_DETECT_SOFTLOCKUP option in your kernel?
> > 
> > > It's on Kernel Hacking > Detect Soft Lockups.
> > > With some chances you will have a relevant stacktrace of the lockup, in case
> > > I couldn't reproduce it.
> > 
> > I'll try (the kernel I'm currently using is jam packed with with debug 
> options) but I'm unconvinced it will unfreeze enough for anything useful...
> 
> No need to actually, I guess we found it...

That's good news - the only way I could have reported the soft lockup stack trace would have been by taking a photo of the screen. The stack trace was pretty much what is seen inside <http://groups.google.com/group/fa.linux.kernel/browse_frm/thread/d4a6ce26360613fa/b362792a2debced6?#b362792a2debced6> anyway. The thing that I'm curious about is why did it show up as an oops last time and as a complete lockup this time?

My one thought is that this is actually a parameter that was not intended to be changed and shouldn't have accepted being written to. However one wonders how the syfs framework was supposed to work in other cases. It sounds like there is a very small window for making your own private copy of whatever sysfs passes to you and under the current system who throws away old strings (given that it looks like pointers are being swapped)? Are they refcounted or something?