[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |