* xl dev-detach hangs with missing frontends
@ 2016-02-11 10:37 Olaf Hering
2016-02-12 14:07 ` Wei Liu
0 siblings, 1 reply; 4+ messages in thread
From: Olaf Hering @ 2016-02-11 10:37 UTC (permalink / raw)
To: xen-devel
How should libxl__initiate_device_generic_remove deal with devices which
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.
# xl -vvvv network-detach $domU $mac
2016-02-11 11:33:19 CET [20318] libxl: debug: libxl.c:4614:libxl_device_nic_remove: ao 0x19b3870: create: how=(nil) callback=(nil) poller=0x19b0200
2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: register slotnum=3
2016-02-11 11:33:19 CET [20318] libxl: debug: libxl.c:4614:libxl_device_nic_remove: ao 0x19b3870: inprogress: poller=0x19b0200, flags=i
2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: event epath=/local/domain/0/backend/vif/10/1/state
2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:878:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 still waiting state 5
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /local/domain/0/backend/vif/10/1/state (hoping for state change to 6): xswait timeout (path=/local/domain/0/backend/vif/10/1/state)
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: deregister slotnum=3
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:862:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 timed out
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:939:device_backend_callback: calling device_backend_cleanup
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:945:device_backend_callback: Timeout reached, initiating forced remove
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: register slotnum=3
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: event epath=/local/domain/0/backend/vif/10/1/state
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:874:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 ok
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: deregister slotnum=3
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:939:device_backend_callback: calling device_backend_cleanup
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:1036:device_hotplug: calling hotplug script: /opt/xen/staging-wip/etc/xen/scripts/vif-bridge offline
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /opt/xen/staging-wip/etc/xen/scripts/vif-bridge offline
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:542:watchfd_callback: watch epath=/local/domain/0/backend/vif/10/1/state token=3/1: empty slot
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2d40: deregister unregistered
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:1023:device_hotplug: No hotplug script to execute
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2d40: deregister unregistered
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x19b3870: complete, rc=0
2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x19b3870: destroy
2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: total allocations:22 total releases:22
2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: current allocations:0 maximum allocations:2
2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: cache current size:2
2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: cache hits:14 misses:2 toobig:6
# echo $?
0
At least ${dev}-detach reports no error in this case.
Olaf
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xl dev-detach hangs with missing frontends
2016-02-11 10:37 xl dev-detach hangs with missing frontends Olaf Hering
@ 2016-02-12 14:07 ` Wei Liu
2016-02-12 14:53 ` Olaf Hering
0 siblings, 1 reply; 4+ messages in thread
From: Wei Liu @ 2016-02-12 14:07 UTC (permalink / raw)
To: Olaf Hering; +Cc: Ian Jackson, wei.liu2, Ian Campbell, xen-devel
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.
> 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.
Do you think the timeout is too long?
Wei.
>
> # xl -vvvv network-detach $domU $mac
> 2016-02-11 11:33:19 CET [20318] libxl: debug: libxl.c:4614:libxl_device_nic_remove: ao 0x19b3870: create: how=(nil) callback=(nil) poller=0x19b0200
> 2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: register slotnum=3
> 2016-02-11 11:33:19 CET [20318] libxl: debug: libxl.c:4614:libxl_device_nic_remove: ao 0x19b3870: inprogress: poller=0x19b0200, flags=i
> 2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: event epath=/local/domain/0/backend/vif/10/1/state
> 2016-02-11 11:33:19 CET [20318] libxl: debug: libxl_event.c:878:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 still waiting state 5
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_aoutils.c:88:xswait_timeout_callback: backend /local/domain/0/backend/vif/10/1/state (hoping for state change to 6): xswait timeout (path=/local/domain/0/backend/vif/10/1/state)
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/0: deregister slotnum=3
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:862:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 timed out
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:939:device_backend_callback: calling device_backend_cleanup
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:945:device_backend_callback: Timeout reached, initiating forced remove
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:636:libxl__ev_xswatch_register: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: register slotnum=3
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:573:watchfd_callback: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: event epath=/local/domain/0/backend/vif/10/1/state
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:874:devstate_callback: backend /local/domain/0/backend/vif/10/1/state wanted state 6 ok
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:673:libxl__ev_xswatch_deregister: watch w=0x19b2c40 wpath=/local/domain/0/backend/vif/10/1/state token=3/1: deregister slotnum=3
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:939:device_backend_callback: calling device_backend_cleanup
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2c40: deregister unregistered
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:1036:device_hotplug: calling hotplug script: /opt/xen/staging-wip/etc/xen/scripts/vif-bridge offline
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_aoutils.c:593:libxl__async_exec_start: forking to execute: /opt/xen/staging-wip/etc/xen/scripts/vif-bridge offline
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:542:watchfd_callback: watch epath=/local/domain/0/backend/vif/10/1/state token=3/1: empty slot
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2d40: deregister unregistered
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_device.c:1023:device_hotplug: No hotplug script to execute
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:686:libxl__ev_xswatch_deregister: watch w=0x19b2d40: deregister unregistered
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:1869:libxl__ao_complete: ao 0x19b3870: complete, rc=0
> 2016-02-11 11:33:29 CET [20318] libxl: debug: libxl_event.c:1838:libxl__ao__destroy: ao 0x19b3870: destroy
> 2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: total allocations:22 total releases:22
> 2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: current allocations:0 maximum allocations:2
> 2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: cache current size:2
> 2016-02-11 11:33:29 CET [20318] xencall:buffer: debug: cache hits:14 misses:2 toobig:6
> # echo $?
> 0
>
> At least ${dev}-detach reports no error in this case.
>
> Olaf
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xl dev-detach hangs with missing frontends
2016-02-12 14:07 ` Wei Liu
@ 2016-02-12 14:53 ` Olaf Hering
2016-02-12 16:56 ` Wei Liu
0 siblings, 1 reply; 4+ messages in thread
From: Olaf Hering @ 2016-02-12 14:53 UTC (permalink / raw)
To: Wei Liu; +Cc: Ian Jackson, Ian Campbell, xen-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: xl dev-detach hangs with missing frontends
2016-02-12 14:53 ` Olaf Hering
@ 2016-02-12 16:56 ` Wei Liu
0 siblings, 0 replies; 4+ messages in thread
From: Wei Liu @ 2016-02-12 16:56 UTC (permalink / raw)
To: Olaf Hering; +Cc: Ian Jackson, Wei Liu, Ian Campbell, xen-devel
On Fri, Feb 12, 2016 at 03:53:06PM +0100, Olaf Hering wrote:
> 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.
>
I see. That function is renamed in PVUSB series.
> > > 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.
Right. The state is reliable for telling whether frontend is connected
or not.
Wei.
>
> Olaf
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-02-12 16:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-02-11 10:37 xl dev-detach hangs with missing frontends Olaf Hering
2016-02-12 14:07 ` Wei Liu
2016-02-12 14:53 ` Olaf Hering
2016-02-12 16:56 ` Wei Liu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).