On Mon, 2008-12-15 at 11:14 +0100, Johannes Berg wrote: > Sorry, heh, was reading mail in the wrong order I guess. > > > - the call to ieee80211_sta_tear_down_BA_sessions was locking up so > > I just dropped it for now in the interest of getting a stable base > > Probably due to transmitting again? We'll have to look and add it, but I > agree that we can work on that later. > > > I also tracked down the disappearing interface problem.. turns out this > > was just gnome-power-manager or HAL. (I do not have 'network_sleep' set > > in gconf, but I didn't bother pinning it down otherwise...) Using > > 'echo mem > /sys/power/state' to suspend keeps the interface up across > > suspend. > > Oh ok, that explains things. Could be udev event ordering? We do need to track this down, otherwise stuff simply won't work when we come back. The best thing to do here is run the udev monitoring tool (whatever that is, I forget) and see what events get emitted from the kernel, then run 'lshal --monitor' and see what HAL thinks is going on, which it gets from consuming udev events and inspecting sysfs. Stuff like this is sometimes caused by mis-ordered kernel events or drivers/subsystems that don't create their sysfs directories at the right times, leading to race conditions between the kernel and HAL. A possibility. Dan -- 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