Florian Fainelli wrote:
netif_stop_queue(netdev);
> napi_disable(&adpt->rx_q.napi);
>
>I cannot call just napi_disable() in emac_change_mtu(), because when I
>then call emac_mac_down(), the first thing it does is call
>netif_stop_queue(), and that's when I timeout/hang.
Whatever emac_mac_down() does you can unroll it in the change_mtu
callback anyway, so if this a problematic sequence you can work around it.
I'm having difficulty coming up with an actual sequence that works. This
odd interaction between netif_stop_queue() and napi_disable() is giving
me inconsistent results.
The hang occurs with this loop in napi_disable():
while (test_and_set_bit(NAPI_STATE_SCHED, &n->state))
msleep(1);
This loop never exits. Can you give me a clue as to what could be the
reason?
>Unfortunately, I cannot even do this:
>
> netif_stop_queue(netdev);
> napi_disable(&adpt->rx_q.napi);
> netif_stop_queue(netdev);
> napi_disable(&adpt->rx_q.napi);
>
>Even though I've already called netif_stop_queue(), calling it again
>causes the timeout/hang.
Buf if this is really what you copy/pasted here, why do this twice anyway?
Sorry, what I meant was that I was hoping that *both* emac_change_mtu()
and emac_mac_down() could do
netif_stop_queue(netdev);
napi_disable(&adpt->rx_q.napi);
Which would have the effect of what I wrote above.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
