Luca Coelho <[email protected]> writes: > From: Naftali Goldstein <[email protected]> > > Consider the following flow: > 1. Driver starts to sync the rx queues due to a delba. > mvm->queue_sync_cookie=1. > This rx-queues-sync is synchronous, so it doesn't increment the > cookie until all rx queues handle the notification from FW. > 2. During this time, driver starts to sync rx queues due to nssn sync > required. > The cookie's value is still 1, but it doesn't matter since this > rx-queue-sync is non-synchronous so in the notification handler the > cookie is ignored. > What _does_ matter is that this flow increments the cookie to 2 > immediately. > Remember though that the FW won't start servicing this command until > it's done with the previous one. > 3. FW is still handling the first command, so it sends a notification > with internal_notif->sync=1, and internal_notif->cookie=0, which > triggers a WARN_ONCE. > > The solution for this race is to only use the mvm->queue_sync_cookie in > case of a synchronous sync-rx-queues. This way in step 2 the cookie's > value won't change so we avoid the WARN. > > The commit in the "fixes" field is the first commit to introduce > non-synchronous sending of this command to FW.
But I don't see a Fixes field anywhere :) -- Kalle Valo
