All of lore.kernel.org
 help / color / mirror / Atom feed
* [xen-unstable test] 11601: tolerable FAIL
@ 2012-01-26  6:16 xen.org
  2012-01-26  8:45 ` Ian Campbell
  2012-01-26  9:21 ` Ian Campbell
  0 siblings, 2 replies; 6+ messages in thread
From: xen.org @ 2012-01-26  6:16 UTC (permalink / raw)
  To: xen-devel; +Cc: ian.jackson

flight 11601 xen-unstable real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/11601/

Failures :-/ but no regressions.

Regressions which are regarded as allowable (not blocking):
 test-i386-i386-win           14 guest-start.2                fail   like 11600

Tests which did not succeed, but are not blocking:
 test-amd64-amd64-xl-pcipt-intel  9 guest-start                 fail never pass
 test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
 test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass
 test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
 test-amd64-i386-xend-winxpsp3 16 leak-check/check             fail  never pass
 test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
 test-i386-i386-xl-win        13 guest-stop                   fail   never pass
 test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
 test-amd64-i386-win-vcpus1   16 leak-check/check             fail   never pass
 test-amd64-i386-win          16 leak-check/check             fail   never pass
 test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
 test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
 test-amd64-amd64-win         16 leak-check/check             fail   never pass
 test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
 test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

version targeted for testing:
 xen                  4271634e4c86
baseline version:
 xen                  4271634e4c86

jobs:
 build-amd64                                                  pass    
 build-i386                                                   pass    
 build-amd64-oldkern                                          pass    
 build-i386-oldkern                                           pass    
 build-amd64-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-xl                                          pass    
 test-amd64-i386-xl                                           pass    
 test-i386-i386-xl                                            pass    
 test-amd64-i386-rhel6hvm-amd                                 fail    
 test-amd64-amd64-xl-win7-amd64                               fail    
 test-amd64-i386-xl-win7-amd64                                fail    
 test-amd64-i386-xl-credit2                                   pass    
 test-amd64-amd64-xl-pcipt-intel                              fail    
 test-amd64-i386-rhel6hvm-intel                               fail    
 test-amd64-i386-xl-multivcpu                                 pass    
 test-amd64-amd64-pair                                        pass    
 test-amd64-i386-pair                                         pass    
 test-i386-i386-pair                                          pass    
 test-amd64-amd64-xl-sedf-pin                                 pass    
 test-amd64-amd64-pv                                          pass    
 test-amd64-i386-pv                                           pass    
 test-i386-i386-pv                                            pass    
 test-amd64-amd64-xl-sedf                                     pass    
 test-amd64-i386-win-vcpus1                                   fail    
 test-amd64-i386-xl-win-vcpus1                                fail    
 test-amd64-i386-xl-winxpsp3-vcpus1                           fail    
 test-amd64-amd64-win                                         fail    
 test-amd64-i386-win                                          fail    
 test-i386-i386-win                                           fail    
 test-amd64-amd64-xl-win                                      fail    
 test-i386-i386-xl-win                                        fail    
 test-amd64-i386-xend-winxpsp3                                fail    
 test-amd64-amd64-xl-winxpsp3                                 fail    
 test-i386-i386-xl-winxpsp3                                   fail    


------------------------------------------------------------
sg-report-flight on woking.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Published tested tree is already up to date.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [xen-unstable test] 11601: tolerable FAIL
  2012-01-26  6:16 [xen-unstable test] 11601: tolerable FAIL xen.org
@ 2012-01-26  8:45 ` Ian Campbell
  2012-01-26 14:48   ` Ian Jackson
  2012-01-26  9:21 ` Ian Campbell
  1 sibling, 1 reply; 6+ messages in thread
From: Ian Campbell @ 2012-01-26  8:45 UTC (permalink / raw)
  To: xen.org; +Cc: xen-devel

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  test-amd64-i386-rhel6hvm-intel  9 guest-start.2                fail never pass
>  test-amd64-i386-rhel6hvm-amd  9 guest-start.2                fail   never pass

Both of these are failing with:
        2012-01-26 05:08:15 Z toolstack xl
        Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
        2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
        Config file not specified and none in save file
        2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
        	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
        	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
        	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
        
Which is presumably a harness failure.

I'm not sure I 100% follow things but it seems that
"toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
"cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

Ian.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [xen-unstable test] 11601: tolerable FAIL
  2012-01-26  6:16 [xen-unstable test] 11601: tolerable FAIL xen.org
  2012-01-26  8:45 ` Ian Campbell
@ 2012-01-26  9:21 ` Ian Campbell
  2012-01-31 14:44   ` Ian Jackson
  1 sibling, 1 reply; 6+ messages in thread
From: Ian Campbell @ 2012-01-26  9:21 UTC (permalink / raw)
  To: xen.org; +Cc: xen-devel

On Thu, 2012-01-26 at 06:16 +0000, xen.org wrote:
[...]
> Tests which did not succeed, but are not blocking:
>  test-amd64-amd64-xl-win7-amd64 13 guest-stop                   fail never pass
>  test-amd64-amd64-xl-win      13 guest-stop                   fail   never pass
>  test-i386-i386-xl-win        13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-win-vcpus1 13 guest-stop                   fail  never pass
>  test-amd64-i386-xl-win7-amd64 13 guest-stop                   fail  never pass
>  test-i386-i386-xl-winxpsp3   13 guest-stop                   fail   never pass
>  test-amd64-amd64-xl-winxpsp3 13 guest-stop                   fail   never pass
>  test-amd64-i386-xl-winxpsp3-vcpus1 13 guest-stop               fail never pass

These are all:
        2012-01-26 03:35:19 Z executing ssh ... root@10.80.249.148 xl shutdown -w win.guest.osstest
        PV control interface not available: external graceful shutdown not possible.
        Use "xl button-press <dom> power" or "xl destroy <dom>".
        shutdown failed (rc=-10)

If you are not amenable to having the harness fallback to xl
button-press/trigger power automatically how about something like the
following patch with the proviso that it is up to the harness to ensure
that a guest is configured appropriately such that ACPI power and reset
events map to shutdown and reboot respectively?

(patch applies on top of my updated"libxl: remove libxl_button_press in
favour of libxl_send_trigger" patch from earlier in the week)

Ian.

8<-------------------------------------------------------------------------------

# HG changeset patch
# User Ian Campbell <ian.campbell@citrix.com>
# Date 1327569659 0
# Node ID c1aeef6cd4c832ddb97a7160be7ab6cb1037d3b8
# Parent  a7776e38447d4e633a45b926295f7923c046fbc9
xl: allow enable automatic fallback to ACPI events if PV control not available.

Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
reset event to be sent to the guest in the event that the guest does not
support the PV control interface.

This is not the default because the response to these triggers is an
guest-internal configuration.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

diff -r a7776e38447d -r c1aeef6cd4c8 docs/man/xl.pod.1
--- a/docs/man/xl.pod.1	Wed Jan 25 16:55:08 2012 +0000
+++ b/docs/man/xl.pod.1	Thu Jan 26 09:20:59 2012 +0000
@@ -365,13 +365,28 @@ domain actually reboots.
 
 For HVM domains this requires PV drivers to be installed in your guest
 OS. If PV drivers are not present but you have configured the guest OS
-to behave appropriately you may be able to use the I<button-press>
-subcommand to trigger a power button press.
+to behave appropriately you may be able to use the I<-F> option
+trigger a reset button press.
 
 The behavior of what happens to a domain when it reboots is set by the
 B<on_reboot> parameter of the domain configuration file when the
 domain was created.
 
+B<OPTIONS>
+
+=over 4
+
+=item B<-F>
+
+If the guest does not support PV reboot control then fallback to
+sending an ACPI power event (equivalent to the I<reset> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
+=back
+
 =item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
 
 Build a domain from an B<xl save> state file.  See B<save> for more info.
@@ -422,8 +437,8 @@ services must be shutdown in the domain.
 
 For HVM domains this requires PV drivers to be installed in your guest
 OS. If PV drivers are not present but you have configured the guest OS
-to behave appropriately you may be able to use the I<button-press>
-subcommand to trigger a power button press.
+to behave appropriately you may be able to use the I<-F> option
+trigger a power button press.
 
 The command returns immediately after signally the domain unless that
 B<-w> flag is used.
@@ -440,6 +455,15 @@ B<OPTIONS>
 
 Wait for the domain to complete shutdown before returning.
 
+=item B<-F>
+
+If the guest does not support PV shutdown control then fallback to
+sending an ACPI power event (equivalent to the I<power> option to
+I<trigger>.
+
+You should ensure that the guest is configured to behave as expected
+in response to this event.
+
 =back
 
 =item B<sysrq> I<domain-id> I<letter>
diff -r a7776e38447d -r c1aeef6cd4c8 tools/libxl/xl_cmdimpl.c
--- a/tools/libxl/xl_cmdimpl.c	Wed Jan 25 16:55:08 2012 +0000
+++ b/tools/libxl/xl_cmdimpl.c	Thu Jan 26 09:20:59 2012 +0000
@@ -2259,19 +2259,24 @@ static void destroy_domain(const char *p
     if (rc) { fprintf(stderr,"destroy failed (rc=%d)\n",rc); exit(-1); }
 }
 
-static void shutdown_domain(const char *p, int wait)
+static void shutdown_domain(const char *p, int wait, int fallback_trigger)
 {
     int rc;
 
     find_domain(p);
     rc=libxl_domain_shutdown(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI power button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_POWER, 0);
+        } else {
             fprintf(stderr, "PV control interface not available:"
                     " external graceful shutdown not possible.\n");
-            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
-                    " \"xl destroy <dom>\".\n");
+            fprintf(stderr, "Use \"-F\" to fallback to ACPI power event.\n");
         }
+    }
+    if (rc) {
         fprintf(stderr,"shutdown failed (rc=%d)\n",rc);exit(-1);
     }
 
@@ -2310,19 +2315,25 @@ static void shutdown_domain(const char *
     }
 }
 
-static void reboot_domain(const char *p)
+static void reboot_domain(const char *p, int fallback_trigger)
 {
     int rc;
     find_domain(p);
     rc=libxl_domain_reboot(ctx, domid);
-    if (rc) {
-        if (rc == ERROR_NOPARAVIRT) {
+    if (rc == ERROR_NOPARAVIRT) {
+        if (fallback_trigger) {
+            fprintf(stderr, "PV control interface not available:"
+                    " sending ACPI reset button event.\n");
+            rc = libxl_send_trigger(ctx, domid, LIBXL_TRIGGER_RESET, 0);
+        } else {
             fprintf(stderr, "PV control interface not available:"
                     " external graceful reboot not possible.\n");
-            fprintf(stderr, "Use \"xl button-press <dom> power\" or"
-                    " \"xl destroy <dom>\".\n");
+            fprintf(stderr, "Use \"-F\" to fallback to ACPI reset event.\n");
         }
-        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1); }
+    }
+    if (rc) {
+        fprintf(stderr,"reboot failed (rc=%d)\n",rc);exit(-1);
+    }
 }
 
 static void list_domains_details(const libxl_dominfo *info, int nb_domain)
@@ -3106,29 +3117,41 @@ int main_shutdown(int argc, char **argv)
 {
     int opt;
     int wait = 0;
-
-    while ((opt = def_getopt(argc, argv, "w", "shutdown", 1)) != -1) {
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "wF", "shutdown", 1)) != -1) {
         switch (opt) {
         case 0: case 2:
             return opt;
         case 'w':
             wait = 1;
             break;
+        case 'F':
+            fallback_trigger = 1;
+            break;
         }
     }
 
-    shutdown_domain(argv[optind], wait);
+    shutdown_domain(argv[optind], wait, fallback_trigger);
     return 0;
 }
 
 int main_reboot(int argc, char **argv)
 {
     int opt;
-
-    if ((opt = def_getopt(argc, argv, "", "reboot", 1)) != -1)
-        return opt;
-
-    reboot_domain(argv[optind]);
+    int fallback_trigger = 0;
+
+    while ((opt = def_getopt(argc, argv, "F", "reboot", 1)) != -1) {
+        switch (opt) {
+        case 0: case 2:
+            return opt;
+        case 'F':
+            fallback_trigger = 1;
+            break;
+        }
+    }
+
+    reboot_domain(argv[optind], fallback_trigger);
     return 0;
 }

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [xen-unstable test] 11601: tolerable FAIL
  2012-01-26  8:45 ` Ian Campbell
@ 2012-01-26 14:48   ` Ian Jackson
  0 siblings, 0 replies; 6+ messages in thread
From: Ian Jackson @ 2012-01-26 14:48 UTC (permalink / raw)
  To: Ian Campbell; +Cc: xen-devel

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> Both of these are failing with:
>         2012-01-26 05:08:15 Z toolstack xl
>         Use of uninitialized value in concatenation (.) or string at ./ts-guest-start line 13.
>         2012-01-26 05:08:15 Z executing ssh ... root@10.80.249.57 xl create 
>         Config file not specified and none in save file
>         2012-01-26 05:08:15 Z command nonzero waitstatus 1536: ssh -o StrictHostKeyChecking=no \
>         	-o BatchMode=yes -o ConnectTimeout=100 -o ServerAliveInterval=100 \
>         	-o PasswordAuthentication=no -o ChallengeResponseAuthentication=no \
>         	-o UserKnownHostsFile=tmp/t.known_hosts_11601.test-amd64-i386-rhel6hvm-amd root@10.80.249.57 xl create 
>         
> Which is presumably a harness failure.

Yes.

> I'm not sure I 100% follow things but it seems that
> "toolstack()->{CfgPathVar}" is going to be "xlpath" rather than
> "cfgpath" but that Osstest.pm:selectguest is only setting up cfgpath.

This is an obsolete feature from when libxl didn't support the same
config files as xend.  I have switched this to using the .cfg file
rather than expecting a different file.

This may break 4.0 I guess, but if so I'll deal with that then.  4.0's
xl is pretty ropey anyway.

Ian.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [xen-unstable test] 11601: tolerable FAIL
  2012-01-26  9:21 ` Ian Campbell
@ 2012-01-31 14:44   ` Ian Jackson
  2012-01-31 15:12     ` Stefano Stabellini
  0 siblings, 1 reply; 6+ messages in thread
From: Ian Jackson @ 2012-01-31 14:44 UTC (permalink / raw)
  To: Ian Campbell; +Cc: xen-devel, Stefano Stabellini

Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> If you are not amenable to having the harness fallback to xl
> button-press/trigger power automatically how about something like the
> following patch with the proviso that it is up to the harness to ensure
> that a guest is configured appropriately such that ACPI power and reset
> events map to shutdown and reboot respectively?
> 
> (patch applies on top of my updated"libxl: remove libxl_button_press in
> favour of libxl_send_trigger" patch from earlier in the week)
...
> xl: allow enable automatic fallback to ACPI events if PV control not available.
> 
> Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> reset event to be sent to the guest in the event that the guest does not
> support the PV control interface.
> 
> This is not the default because the response to these triggers is an
> guest-internal configuration.

I'm happy with this, but then I would have been happy with this being
the default.

Certainly I think this is a good start, so:

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Ian.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [xen-unstable test] 11601: tolerable FAIL
  2012-01-31 14:44   ` Ian Jackson
@ 2012-01-31 15:12     ` Stefano Stabellini
  0 siblings, 0 replies; 6+ messages in thread
From: Stefano Stabellini @ 2012-01-31 15:12 UTC (permalink / raw)
  To: Ian Jackson; +Cc: xen-devel, Ian Campbell, Stefano Stabellini

On Tue, 31 Jan 2012, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 11601: tolerable FAIL"):
> > If you are not amenable to having the harness fallback to xl
> > button-press/trigger power automatically how about something like the
> > following patch with the proviso that it is up to the harness to ensure
> > that a guest is configured appropriately such that ACPI power and reset
> > events map to shutdown and reboot respectively?
> > 
> > (patch applies on top of my updated"libxl: remove libxl_button_press in
> > favour of libxl_send_trigger" patch from earlier in the week)
> ...
> > xl: allow enable automatic fallback to ACPI events if PV control not available.
> > 
> > Add a -F (fallbacks) option to xl destroy|reboot to cause an ACPI shutdown or
> > reset event to be sent to the guest in the event that the guest does not
> > support the PV control interface.
> > 
> > This is not the default because the response to these triggers is an
> > guest-internal configuration.
> 
> I'm happy with this, but then I would have been happy with this being
> the default.
> 
> Certainly I think this is a good start, so:
> 

I think it is a good compromise.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2012-01-31 15:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-26  6:16 [xen-unstable test] 11601: tolerable FAIL xen.org
2012-01-26  8:45 ` Ian Campbell
2012-01-26 14:48   ` Ian Jackson
2012-01-26  9:21 ` Ian Campbell
2012-01-31 14:44   ` Ian Jackson
2012-01-31 15:12     ` Stefano Stabellini

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.