On 11/9/06, Eric Lemoine <[EMAIL PROTECTED]> wrote:
On 11/9/06, Michael Chan <[EMAIL PROTECTED]> wrote:
> Michael Chan wrote:
>
> > Eric Lemoine wrote:
> >
> > > Instead of tg3_netif_stop() tg3_close() uses netif_stop_queue()
> > > to stop xmit. This doesn't seem right to me. E.g. another CPU
> > > in tg3_tx()
> > > could do netif_wake_queue() just after tg3_close() did
> > > netif_stop_queue(). Isn't a bug?
> > >
> >
> > I think you're right. It is more correct to call tg3_netif_stop().
> >
>
> I take it back. Before ->stop() is called, netif_running is cleared,
> and it waits for __LINK_STATE_RX_SCHED to be cleared. This means
> that it will wait for the last ->poll() to finish.
Correct.
> So it is not possible for tg3_poll() -> tg3_tx() to run any more
> after tg3_close() is called.
But, while tg3_close() starts executing, an interrupt may come in and
schedule polling (set __LINK_STATE_RX_SCHED). So tg3_poll() ->
tg3_tx() may well occur.
Actually I don't understand the purpose of having dev_close() wait for
__LINK_STATE_RX_SCHED to be cleared. An interrupt may arrive at any
time after it's cleared, and reset __LINK_STATE_RX_SCHED. Can someone
explain please?
Thanks,
--
Eric
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
