On Tuesday 03 July 2007 01:39, Michael Buesch wrote: > On Tuesday 03 July 2007 06:09:19 Michael Wu wrote: > > On Monday 02 July 2007 13:35, Michael Buesch wrote: > > > + netif_tx_lock_bh(mdev); > > > for (i = 0; i < hw->queues; i++) > > > ieee80211_stop_queue(hw, i); > > > + netif_tx_unlock_bh(mdev); > > > > Well, looks like this will break stopping all tx queues from the tx > > handler by deadlocking. It may be useless for bcm43xx to call > > ieee80211_stop_queue, but there are other drivers which rely on it. > > Nobody said that. Of course bcm43xx needs stop_queue, too. > I mean stop_queues, in the tx path, which this patch would break. > > I would prefer to guarantee that the stack will not allow any more frames > > to be queued before calling stop/remove_interface on the last virtual > > interface. That should be true right now since the master interface is > > taken down before calling stop and remove_interface, so > > ieee80211_stop_queues shouldn't be necessary on device down. If this > > isn't the case, it should be fixed. > > No, that is not enough. For example for switching bands we need to > reinitialize the board completely. Before I take the board down I must > ensure that no traffic is going on any longer. > Ok sure. However, ensuring that there is no attempt to TX while the channel is being changed is generally good so stopping the queues before every channel change in mac80211 would be preferred. > > Of course, the ieee80211_stop_queue deadlock should still get fixed > > eventually.. > > That's not needed, as it's only sane to call in the TX handler, where > it can't deadlock. By stop_queue, I mean stop_queues, which you do seem to want to call outside of the tx_handler. -Michael Wu
Attachment:
pgpukIjPWXbvD.pgp
Description: PGP signature
