On 8/1/08, Larry Finger <Larry.Finger@xxxxxxxxxxxx> wrote: > Some users of the RTL8187B have experienced difficulties since commit > 8f87dd7e540d455f8e7f11478133b85edc969c67 that introduced the power > management wext hooks. This difficulty has not made much sense until > it was realized that it was possible for mac80211 to make a call to the > config routine while that routine was already being executed. On this > device, it is necessary to loopback the TX when changing channels. Unless > this is properly restored, the device will lockup. A mutex now protects > the device state, and the private data in several places. > > The problem was found by Herton Ronaldo Krzesinski <herton@xxxxxxxxxxxxxxx>, > who also suggested this type of fix. Thanks for the work. I think we need a few more mutex locks. The one-line message/explanation is a bit mis-worded though. There isn't a "lockup" though. I would describe the problem as the driver's internal state getting garbbaged. It is probably a performance "feature" that routines in either the mac80211 layer or the usb layer returns before they are done. (i.e. actions are simply queued for near-future to act on). Maybe somebody else can explain this better? Hin-Tak -- 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
