From mboxrd@z Thu Jan 1 00:00:00 1970 From: Olaf Hering Subject: Re: xl dev-detach hangs with missing frontends Date: Fri, 12 Feb 2016 15:53:06 +0100 Message-ID: <20160212145306.GA14753@aepfle.de> References: <20160211103749.GA26883@aepfle.de> <20160212140752.GA5427@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20160212140752.GA5427@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Wei Liu Cc: Ian Jackson , Ian Campbell , xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Fri, Feb 12, Wei Liu wrote: > CC'ing other tools maintainer. > > On Thu, Feb 11, 2016 at 11:37:49AM +0100, Olaf Hering wrote: > > How should libxl__initiate_device_generic_remove deal with devices which > > I think you meant libxl__initiate_device_remove. There is no function > called libxl__initiate_device_generic _remove. Not yet. > > have no frontend driver? Right now it moves "state" from either > > XenbusStateInitialising or XenbusStateInitWait to XenbusStateClosing. > > Then it expects the backend to move "state" to XenbusStateClosed. This > > will never happen, at least for netback and scsiback. The result is a 10 > > second delay. > > > > I don't think there is a way to tell whether there is no frontend driver > or the frontend driver is just too slow. To handle this the code should check the current value of "state". If its XenbusStateInitialising or XenbusStateInitWait nothing should be done. Olaf