[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] calling vif hotplug scripts more than once
> -----Original Message----- > From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel- > bounces@xxxxxxxxxxxxx] On Behalf Of Olaf Hering > Sent: 09 July 2014 08:36 > To: Ian Jackson > Cc: xen-devel@xxxxxxxxxxxxx; Ian Campbell; Roger Pau Monne > Subject: Re: [Xen-devel] calling vif hotplug scripts more than once > > On Tue, Jul 08, Ian Jackson wrote: > > > Olaf Hering writes ("Re: calling vif hotplug scripts more than once"): > > > On Tue, Jul 08, Ian Jackson wrote: > > > > Surely the problem is just that the backend isn't going back to the > > > > operational state. I don't see why this would need the hotplug script > > > > to run again. > > > > > > Something needs to reconnect the device to the bridge. There is also > > > that hotplug-status thing, which netback reads. I have to check what it > > > does with that. > > > > Why is the device removed from the bridge ? What does that ? > > Looks like netback does that, because the interface disappears. > Before "disable": > What vintage of netback are you running? This is precisely the problem I fixed with c/s 279f438e36c0a70b23b86d2090aeec50155034a9: ----- commit 279f438e36c0a70b23b86d2090aeec50155034a9 Author: Paul Durrant <Paul.Durrant@xxxxxxxxxx> Date: Tue Sep 17 17:46:08 2013 +0100 xen-netback: Don't destroy the netdev until the vif is shut down Without this patch, if a frontend cycles through states Closing and Closed (which Windows frontends need to do) then the netdev will be destroyed and requires re-invocation of hotplug scripts to restore state before the frontend can move to Connected. Thus when udev is not in use the backend gets stuck in InitWait. With this patch, the netdev is left alone whilst the backend is still online and is only de-registered and freed just prior to destroying the vif (which is also nicely symmetrical with the netdev allocation and registration being done during probe) so no re-invocation of hotplug scripts is required. Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx> Cc: David Vrabel <david.vrabel@xxxxxxxxxx> Cc: Wei Liu <wei.liu2@xxxxxxxxxx> Cc: Ian Campbell <ian.campbell@xxxxxxxxxx> Acked-by: Wei Liu <wei.liu2@xxxxxxxxxx> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx> ----- Paul > # brctl show > bridge name bridge id STP enabled interfaces > br0 8000.00265523e546 no eth0 > vif1.0 > vif1.0-emu > After "disable": > # brctl show > bridge name bridge id STP enabled interfaces > br0 8000.00265523e546 no eth0 > vif1.0-emu > > dmesg has: > [50367.178364] br0: port 2(vif1.0) entering forwarding state > [50367.178510] device vif1.0 left promiscuous mode > [50367.178516] br0: port 2(vif1.0) entering disabled state > [50367.227599] frontend_changed: backend/vif/1/0: prepare for reconnect > > The last message appears when the frontend is in XenbusStateInitialising and > the backend is in XenbusStateClosed, then the backend changes to > XenbusStateInitWait. > > It looks like the backend goes back into XenbusStateConnected when I write > /local/domain/0/backend/vif/1/0/hotplug-status connected, but nothing > puts > vif1.0 back into br0. > > > Olaf > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxx > http://lists.xen.org/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |