Re: [Xen-devel] netback Oops then xenwatch stuck in D state

[Wei Liu <wei.liu2@xxxxxxxxxx>]

On Thu, 2013-02-14 at 12:33 +0000, Jan Beulich wrote:
> >>> On 14.02.13 at 13:13, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
> > On Thu, 2013-02-14 at 11:48 +0000, Jan Beulich wrote:
> >> I don't think this patch will fix his problems, which - as described
> >> yesterday - I'm relatively certain result from the harsh action
> >> netbk_fatal_tx_err() does.
> > 
> > Yes, having this one only is not enough. It will need to either disable
> > the vif timer or check vif->netbk != NULL inside timer callback.
> 
> I continue to be unclear what timer you refer to.
> 

Oh, it is the tx credit timer callback, which will try to schedule vif
regardless of whether it is linked to netbk or not. See
tx_credit_callback.

It is also the root cause of Christopher's latest oops report last
night, when he `ifconfig vifX.X down` in Dom0.

> If we keep the carrier-off in fatal_tx_err, then _all_
> asynchronously callable interfaces need to check whether the
> vif -> netbk association went away. But, especially in the
> context of using tasklets instead of kthreads, I meanwhile
> think that simply setting a flag (along with turning off the IRQ)
> would be better (and keep the turning off of the carrier the way
> it had been done before. The flag would basically need checking
> anywhere we look at the shared ring (which ought to be very
> few places), and perhaps should also cause xenvif_schedulable()
> to return false.
> 

Is this equivalent to checking vif->netbk? Well, at least in practice.


Wei.

> Jan
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel