On Mon, 2011-12-12 at 10:22 +0100, Dmitry Tarnyagin wrote: > On Mon, Dec 12, 2011 at 10:02 AM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> wrote: > > On Mon, 2011-12-12 at 00:38 +0100, Dmitry Tarnyagin wrote: > >> Some WLAN hardware has > >> longer timeouts for non-interruptible configuration-related > >> operations, leading to the watchdog timeout while > >> ieee80211_scan_cancel is waiting on a mutex. > > > > Yuck, fix the device? > > > It's hardly possible. Some configuration changes really takes long time, > especially in presence of an active bluetooth session. > ... or abort suspend on the driver's level. It's perfectly ok for me. But then > driver needs to be at least notified that WLAN is suspending. What do you > think about early-suspend driver callback which to be called before any > possibly locking operations in mac80211 code? That's seems reasonable. > >> The patch checks if interface mutex is already held and rejects > >> suspend if there is a possibility of locking. > > > > That's really not a good plan. This will refuse suspend *all the time*. > > > All the time? I don't think so.. On normal Linux systems WLAN operations > should not interfere with suspend at all. On aggressive systems like Android > it's actually a good idea to reject suspend when the interface mutex is held, > otherwise system will be likely resumed almost immediately by WoW. Well whenever it would have to wait for the mutex, even if it just has to wait 1ms for it... That will *certainly* trigger *randomly* on normal laptops systems and cause a TON of bug reports from users saying "my system randomly refuses to suspend". johannes -- 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
