On Tue, Oct 07, 2008 at 12:09:36AM +0200, Johannes Berg wrote: > On Mon, 2008-10-06 at 08:30 -0500, Robin Holt wrote: > > > I didn't really need to do much for the printk's in > > ieee80211_sta_debugfs_add(). My printk's in sta_info_debugfs_add_work() > > already told me that sta->local->debugfs.stations is NULL. > > Well yes, but I wanted to know why ieee80211_sta_debugfs_add() doesn't > set debugfs.stations to non-NULL. > > > Again, this > > is iwl3945 only after a suspend of a few minutes followed by a resume. > > It happens about 1/3 of the time. > > Ok, I have a new suspicion: there seems to be a race condition between > destroying a station (sta_info_destroy) which removes it from debugfs, > and creating a new one with the same MAC address which will ask the > workqueue to add it to debugfs. It clearly is actually possible to run > sta_info_insert(sta2) and consequently sta_info_debugfs_add_work before > sta_info_destroy(sta1), but when they both have the same MAC address > then ieee80211_sta_debugfs_add has to fail. > > I don't see much we can do against this, the patch I posted is > definitely needed just in case debugfs gets a new failure mode any time > in the future so I'll post it for inclusion, and the race condition I > described just means that the sta2 won't be in debugfs at all... That race seems more plausible. On a seperate note, I got a panic with your earlier patch applied at: IP: [<f8c669df>] :mac80211:netdev_notify+0x5f/0x90 Not sure if that is just exposed by the hangs being out of the way. I hand wrote that part. Nothing else got captured in the logs :( Thanks, Robin -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
