[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> On 14.02.13 at 13:33, "Jan Beulich" <JBeulich@xxxxxxxx> 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.
> 
> 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.

Or a "light" version of xenvif_down(), i.e. simply

        disable_irq(vif->irq);
        xen_netbk_deschedule_xenvif(vif);

If I'm not mistaken, doing this instead of xenvif_carrier_off()
could be all that's needed.

Jan


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.