From xen-users-bounces@lists.xen.org Wed Jul 01 08:43:39 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 08:43:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZADb7-0001Sd-BV; Wed, 01 Jul 2015 08:42:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZADb6-0001SY-0X for xen-users@lists.xen.org; Wed, 01 Jul 2015 08:42:24 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 26/90-02969-FE7A3955; Wed, 01 Jul 2015 08:42:23 +0000 X-Env-Sender: prvs=617539202=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435740141!21529883!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15015 invoked from network); 1 Jul 2015 08:42:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 08:42:22 -0000 X-IronPort-AV: E=Sophos;i="5.15,384,1432598400"; d="scan'208";a="277278691" Message-ID: <1435740138.21469.230.camel@citrix.com> From: Ian Campbell To: Jintack Lim Date: Wed, 1 Jul 2015 09:42:18 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Setting total number of cpus in the system X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote: > Hi, > > > Is there any way to set the total number of cpus in the system? > I know how to set the number of cpus for Dom0 and DomU, > however I was not able to find one for the whole system. > (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus) > > > The only way I can think of is to modify the device tree. > Is there more convenient way to do this? According to http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html it should be maxcpus=N, however this doesn't look to be wired up on ARM (which I'm inferring is what you are interested in). Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of integer_param("maxcpus"...) as inspiration shouldn't be too tricky, patches welcome! Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 08:43:39 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 08:43:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZADb7-0001Sd-BV; Wed, 01 Jul 2015 08:42:25 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZADb6-0001SY-0X for xen-users@lists.xen.org; Wed, 01 Jul 2015 08:42:24 +0000 Received: from [85.158.137.68] by server-14.bemta-3.messagelabs.com id 26/90-02969-FE7A3955; Wed, 01 Jul 2015 08:42:23 +0000 X-Env-Sender: prvs=617539202=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435740141!21529883!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15015 invoked from network); 1 Jul 2015 08:42:22 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 08:42:22 -0000 X-IronPort-AV: E=Sophos;i="5.15,384,1432598400"; d="scan'208";a="277278691" Message-ID: <1435740138.21469.230.camel@citrix.com> From: Ian Campbell To: Jintack Lim Date: Wed, 1 Jul 2015 09:42:18 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Setting total number of cpus in the system X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote: > Hi, > > > Is there any way to set the total number of cpus in the system? > I know how to set the number of cpus for Dom0 and DomU, > however I was not able to find one for the whole system. > (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus) > > > The only way I can think of is to modify the device tree. > Is there more convenient way to do this? According to http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html it should be maxcpus=N, however this doesn't look to be wired up on ARM (which I'm inferring is what you are interested in). Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of integer_param("maxcpus"...) as inspiration shouldn't be too tricky, patches welcome! Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 09:30:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 09:30:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAEKV-0003VQ-Un; Wed, 01 Jul 2015 09:29:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAEKU-0003VL-BE for xen-users@lists.xen.org; Wed, 01 Jul 2015 09:29:18 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id EE/7B-21325-DE2B3955; Wed, 01 Jul 2015 09:29:17 +0000 X-Env-Sender: Nils.Hildebrand@bva.bund.de X-Msg-Ref: server-11.tower-206.messagelabs.com!1435742956!14005564!1 X-Originating-IP: [77.87.228.76] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzcuODcuMjI4Ljc2ID0+IDIxMzQ0\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15348 invoked from network); 1 Jul 2015 09:29:17 -0000 Received: from m4-bn.bund.de (HELO m4-bn.bund.de) (77.87.228.76) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 09:29:17 -0000 Received: from m4.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m4-bn.bund.de (8.14.5/8.14.5) with ESMTP id t619TDT7026677; Wed, 1 Jul 2015 11:29:13 +0200 (CEST) Received: (from localhost) by m4.mfw.bn.ivbb.bund.de (MSCAN) id 8/m4.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Jul 1 11:29:13 2015 X-P350-Id: 2c9d97422057bc2a From: "Hildebrand, Nils (BIT II 9)" To: =?iso-8859-1?Q?=27Roger_Pau_Monn=E9=27?= Thread-Topic: [Xen-users] xl stack problems on CentOS6 XEN4 Thread-Index: AQHQjM5xiW1ekp39uk2WYeDukJxXpp2BbdYAgAT22rD///exgIBARBzw Date: Wed, 1 Jul 2015 09:29:10 +0000 Message-ID: References: <1431421630.8263.94.camel@citrix.com> <1431435304.8263.155.camel@citrix.com> <1431439609.8263.157.camel@citrix.com> <55522590.2070006@citrix.com> <5559BD4E.50308@citrix.com> <555DE067.9060407@citrix.com> In-Reply-To: <555DE067.9060407@citrix.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.7.87] MIME-Version: 1.0 X-TM-AS-GCONF: 00 Cc: "'xen-users@lists.xen.org'" , Ian Campbell Subject: Re: [Xen-users] xl stack problems on CentOS6 XEN4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Roger, we now had the chance to test the patch against 4.4.2-4 (which came in in t= he meantime). It seems to work! What I tested so far: xl create without switching drbd to primary - works now. reboot within the DomU - works now xl reboot - works now. Should I do some further testing, or can you give the green light to roll o= ut the patch in the mainline CentOS 6 XEN 4 project? The official 4.4.2-4 still fails at xl create if I do not switch drbd to pr= imary and go to /dev/drbd/by-res/ before issuing xl create). Kind regards Nils = -----Urspr=FCngliche Nachricht----- Von: Roger Pau Monn=E9 [mailto:roger.pau@citrix.com] = Gesendet: Donnerstag, 21. Mai 2015 15:41 An: Hildebrand, Nils (BIT II 9) Cc: 'xen-users@lists.xen.org'; Ian Campbell Betreff: Re: [Xen-users] xl stack problems on CentOS6 XEN4 El 21/05/15 a les 14.12, Hildebrand, Nils (BIT II 9) ha escrit: > Hi Roger, > = > your patch does not seem to fit my sources: > http://vault.centos.org/6.6/xen4/Source/SPackages/ > I am currently on XEN 4.4.2-2 (=3DCentOS 6 XEN 4)- your patch is for 4.5? > = > Can you please backport your patch to 4.4.2-2? Please don't top post. Patch applied cleanly against stable-4.4 branch. Below is the patch = against the stable-4.4 branch. Roger. --- diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 59e3292..ed30ee2 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2630,9 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl_= _egc *egc, = switch (disk->backend) { case LIBXL_DISK_BACKEND_PHY: - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk = %s", - disk->pdev_path); - dev =3D disk->pdev_path; + if (disk->script =3D=3D NULL) { + LOG(DEBUG, "locally attaching PHY disk %s", disk->pdev_pat= h); + dev =3D disk->pdev_path; + } else { + libxl__prepare_ao_device(ao, &dls->aodev); + dls->aodev.callback =3D local_device_attach_cb; + device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk, &dls->ao= dev, + libxl__alloc_vdev, (void *) blkdev_start); + return; + } break; case LIBXL_DISK_BACKEND_TAP: switch (disk->format) { @@ -2709,7 +2716,7 @@ static void local_device_attach_cb(libxl__egc *egc, l= ibxl__ao_device *aodev) } = dev =3D GCSPRINTF("/dev/%s", disk->vdev); - LOG(DEBUG, "locally attaching qdisk %s", dev); + LOG(DEBUG, "locally attaching disk %s", dev); = rc =3D libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &devic= e); if (rc < 0) @@ -2750,6 +2757,7 @@ void libxl__device_disk_local_initiate_detach(libxl__= egc *egc, = switch (disk->backend) { case LIBXL_DISK_BACKEND_QDISK: + case LIBXL_DISK_BACKEND_PHY: if (disk->vdev !=3D NULL) { GCNEW(device); rc =3D libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, @@ -2766,7 +2774,6 @@ void libxl__device_disk_local_initiate_detach(libxl__= egc *egc, /* disk->vdev =3D=3D NULL; fall through */ default: /* - * Nothing to do for PHYSTYPE_PHY. * For other device types assume that the blktap2 process is * needed by the soon to be started domain and do nothing. */ _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 09:30:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 09:30:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAEKV-0003VQ-Un; Wed, 01 Jul 2015 09:29:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAEKU-0003VL-BE for xen-users@lists.xen.org; Wed, 01 Jul 2015 09:29:18 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id EE/7B-21325-DE2B3955; Wed, 01 Jul 2015 09:29:17 +0000 X-Env-Sender: Nils.Hildebrand@bva.bund.de X-Msg-Ref: server-11.tower-206.messagelabs.com!1435742956!14005564!1 X-Originating-IP: [77.87.228.76] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNzcuODcuMjI4Ljc2ID0+IDIxMzQ0\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15348 invoked from network); 1 Jul 2015 09:29:17 -0000 Received: from m4-bn.bund.de (HELO m4-bn.bund.de) (77.87.228.76) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 09:29:17 -0000 Received: from m4.mfw.bn.ivbb.bund.de (localhost.mfw.bn.ivbb.bund.de [127.0.0.1]) by m4-bn.bund.de (8.14.5/8.14.5) with ESMTP id t619TDT7026677; Wed, 1 Jul 2015 11:29:13 +0200 (CEST) Received: (from localhost) by m4.mfw.bn.ivbb.bund.de (MSCAN) id 8/m4.mfw.bn.ivbb.bund.de/smtp-gw/mscan; Wed Jul 1 11:29:13 2015 X-P350-Id: 2c9d97422057bc2a From: "Hildebrand, Nils (BIT II 9)" To: =?iso-8859-1?Q?=27Roger_Pau_Monn=E9=27?= Thread-Topic: [Xen-users] xl stack problems on CentOS6 XEN4 Thread-Index: AQHQjM5xiW1ekp39uk2WYeDukJxXpp2BbdYAgAT22rD///exgIBARBzw Date: Wed, 1 Jul 2015 09:29:10 +0000 Message-ID: References: <1431421630.8263.94.camel@citrix.com> <1431435304.8263.155.camel@citrix.com> <1431439609.8263.157.camel@citrix.com> <55522590.2070006@citrix.com> <5559BD4E.50308@citrix.com> <555DE067.9060407@citrix.com> In-Reply-To: <555DE067.9060407@citrix.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.195.7.87] MIME-Version: 1.0 X-TM-AS-GCONF: 00 Cc: "'xen-users@lists.xen.org'" , Ian Campbell Subject: Re: [Xen-users] xl stack problems on CentOS6 XEN4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Roger, we now had the chance to test the patch against 4.4.2-4 (which came in in t= he meantime). It seems to work! What I tested so far: xl create without switching drbd to primary - works now. reboot within the DomU - works now xl reboot - works now. Should I do some further testing, or can you give the green light to roll o= ut the patch in the mainline CentOS 6 XEN 4 project? The official 4.4.2-4 still fails at xl create if I do not switch drbd to pr= imary and go to /dev/drbd/by-res/ before issuing xl create). Kind regards Nils = -----Urspr=FCngliche Nachricht----- Von: Roger Pau Monn=E9 [mailto:roger.pau@citrix.com] = Gesendet: Donnerstag, 21. Mai 2015 15:41 An: Hildebrand, Nils (BIT II 9) Cc: 'xen-users@lists.xen.org'; Ian Campbell Betreff: Re: [Xen-users] xl stack problems on CentOS6 XEN4 El 21/05/15 a les 14.12, Hildebrand, Nils (BIT II 9) ha escrit: > Hi Roger, > = > your patch does not seem to fit my sources: > http://vault.centos.org/6.6/xen4/Source/SPackages/ > I am currently on XEN 4.4.2-2 (=3DCentOS 6 XEN 4)- your patch is for 4.5? > = > Can you please backport your patch to 4.4.2-2? Please don't top post. Patch applied cleanly against stable-4.4 branch. Below is the patch = against the stable-4.4 branch. Roger. --- diff --git a/tools/libxl/libxl.c b/tools/libxl/libxl.c index 59e3292..ed30ee2 100644 --- a/tools/libxl/libxl.c +++ b/tools/libxl/libxl.c @@ -2630,9 +2630,16 @@ void libxl__device_disk_local_initiate_attach(libxl_= _egc *egc, = switch (disk->backend) { case LIBXL_DISK_BACKEND_PHY: - LIBXL__LOG(ctx, LIBXL__LOG_DEBUG, "locally attaching PHY disk = %s", - disk->pdev_path); - dev =3D disk->pdev_path; + if (disk->script =3D=3D NULL) { + LOG(DEBUG, "locally attaching PHY disk %s", disk->pdev_pat= h); + dev =3D disk->pdev_path; + } else { + libxl__prepare_ao_device(ao, &dls->aodev); + dls->aodev.callback =3D local_device_attach_cb; + device_disk_add(egc, LIBXL_TOOLSTACK_DOMID, disk, &dls->ao= dev, + libxl__alloc_vdev, (void *) blkdev_start); + return; + } break; case LIBXL_DISK_BACKEND_TAP: switch (disk->format) { @@ -2709,7 +2716,7 @@ static void local_device_attach_cb(libxl__egc *egc, l= ibxl__ao_device *aodev) } = dev =3D GCSPRINTF("/dev/%s", disk->vdev); - LOG(DEBUG, "locally attaching qdisk %s", dev); + LOG(DEBUG, "locally attaching disk %s", dev); = rc =3D libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, disk, &devic= e); if (rc < 0) @@ -2750,6 +2757,7 @@ void libxl__device_disk_local_initiate_detach(libxl__= egc *egc, = switch (disk->backend) { case LIBXL_DISK_BACKEND_QDISK: + case LIBXL_DISK_BACKEND_PHY: if (disk->vdev !=3D NULL) { GCNEW(device); rc =3D libxl__device_from_disk(gc, LIBXL_TOOLSTACK_DOMID, @@ -2766,7 +2774,6 @@ void libxl__device_disk_local_initiate_detach(libxl__= egc *egc, /* disk->vdev =3D=3D NULL; fall through */ default: /* - * Nothing to do for PHYSTYPE_PHY. * For other device types assume that the blktap2 process is * needed by the soon to be started domain and do nothing. */ _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 11:49:01 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 11:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAGUd-00051V-Kz; Wed, 01 Jul 2015 11:47:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAGUc-00051M-0s for xen-users@lists.xen.org; Wed, 01 Jul 2015 11:47:54 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 7A/06-21300-963D3955; Wed, 01 Jul 2015 11:47:53 +0000 X-Env-Sender: jl4312@columbia.edu X-Msg-Ref: server-2.tower-27.messagelabs.com!1435751271!28301612!1 X-Originating-IP: [128.59.72.250] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18069 invoked from network); 1 Jul 2015 11:47:52 -0000 Received: from millet.cc.columbia.edu (HELO millet.cc.columbia.edu) (128.59.72.250) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 11:47:52 -0000 Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t61BlJ0a029752 for ; Wed, 1 Jul 2015 07:47:51 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id EDB5A7E for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id D81917E for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t61BlokY029110 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: by ieqy10 with SMTP id y10so32733658ieq.0 for ; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PZfV5auK5aGh0PgNfL4Ai3WnC4CZOpe/XGWS5fdNUHc=; b=SDDnfgw61YXmuBfIK6uFWm2jGnpbcxLyjOqFST2LmSXuoLNg795VepeHGjseqIlZyQ Xvst6esUnRep+kBHSnvRUc8aF5z+HNAbMF+TtPvxyO76F+0zhzKuSRYTL4EJ0iI9JVu0 GFo3RfXCPMbmBGpEj23vxXD0/yGfi/ZsmtEFNv8EroLpg/ec5ZLWFOY+gL2igK30OugV pngaKIjF0NTl2h/Jy2JckquCCwg+DxOqUwNs6ezT5EWF7GHLE4+Cr2mCAZQM+AOhg3mf fwgr6P6kV7fyPalIrkdCyk5Vbcxdrnv5v7HDrrjR++IcnMctsAh+ovT5imCY+syK1D9z NBpA== X-Gm-Message-State: ALoCoQn8LDHwURcN97gBnNfmmxkYgnn+6EcebJ1QduHGklGz/fBw53d94PFOv6z3kOa/FtAZv+pmfZH4RvVcXEjl1S2Juf1uqJhpg5tUKN0F1KJZr/Bc5SrANw129fLeuIHK9whWx+ZB X-Received: by 10.107.135.22 with SMTP id j22mr36725663iod.20.1435751270221; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) X-Received: by 10.107.135.22 with SMTP id j22mr36725652iod.20.1435751270092; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id a139sm1157140ioa.14.2015.07.01.04.47.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 04:47:47 -0700 (PDT) Received: by igcur8 with SMTP id ur8so88855649igc.0 for ; Wed, 01 Jul 2015 04:47:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.167.73 with SMTP id q70mr37417065ioe.82.1435751266365; Wed, 01 Jul 2015 04:47:46 -0700 (PDT) Received: by 10.36.42.5 with HTTP; Wed, 1 Jul 2015 04:47:46 -0700 (PDT) In-Reply-To: <1435740138.21469.230.camel@citrix.com> References: <1435740138.21469.230.camel@citrix.com> Date: Wed, 1 Jul 2015 07:47:46 -0400 Message-ID: From: Jintack Lim To: Ian Campbell X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Setting total number of cpus in the system X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6988375544521247627==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6988375544521247627== Content-Type: multipart/alternative; boundary=001a1142a48037e6c40519cee46d --001a1142a48037e6c40519cee46d Content-Type: text/plain; charset=UTF-8 Hi Ian, On Wed, Jul 1, 2015 at 4:42 AM, Ian Campbell wrote: > On Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote: > > Hi, > > > > > > Is there any way to set the total number of cpus in the system? > > I know how to set the number of cpus for Dom0 and DomU, > > however I was not able to find one for the whole system. > > (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus) > > > > > > The only way I can think of is to modify the device tree. > > Is there more convenient way to do this? > > According to > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html > it should be maxcpus=N, however this doesn't look to be wired up on ARM > (which I'm inferring is what you are interested in). > Yes, I'm working on ARM :) > > Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of > integer_param("maxcpus"...) as inspiration shouldn't be too tricky, > patches welcome! > I quickly hard-coded the number of cpus in xen/arch/arm/setup.c, It worked! thanks! I'll try to make a patch to use the command line option. > Ian. > > > > > --001a1142a48037e6c40519cee46d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ian,

On Wed, Jul 1, 2015 at 4:42 AM, Ian Campbell <<= a href=3D"mailto:ian.campbell@citrix.com" target=3D"_blank" onclick=3D"wind= ow.open('https://mail.google.com/mail/?view=3Dcm&tf=3D1&to=3Dia= n.campbell@citrix.com&cc=3D&bcc=3D&su=3D&body=3D','= _blank');return false;">ian.campbell@citrix.com> wrote:
On= Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote:
> Hi,
>
>
> Is there any way to set the total number of cpus in the system?
> I know how to set the number of cpus for Dom0 and DomU,
> however I was not able to find one for the whole system.
> (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus)
>
>
> The only way I can think of is to modify the device tree.
> Is there more convenient way to do this?

According to
http://xenbits.xen.org/docs/unstable/= misc/xen-command-line.html
it should be maxcpus=3DN, however this doesn't look to be wired up on A= RM
(which I'm inferring is what you are interested in).
=C2=A0
Yes, I'm working on ARM :)
=C2=A0

Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of=
integer_param("maxcpus"...) as inspiration shouldn't be too t= ricky,
patches welcome!

I quickly hard-coded t= he number of cpus in xen/arch/arm/setup.c,
It worked! thanks!

I'll try to make a patch to use the command line = option.=C2=A0


Ian.





--001a1142a48037e6c40519cee46d-- --===============6988375544521247627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6988375544521247627==-- From xen-users-bounces@lists.xen.org Wed Jul 01 11:49:01 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 11:49:01 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAGUd-00051V-Kz; Wed, 01 Jul 2015 11:47:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAGUc-00051M-0s for xen-users@lists.xen.org; Wed, 01 Jul 2015 11:47:54 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 7A/06-21300-963D3955; Wed, 01 Jul 2015 11:47:53 +0000 X-Env-Sender: jl4312@columbia.edu X-Msg-Ref: server-2.tower-27.messagelabs.com!1435751271!28301612!1 X-Originating-IP: [128.59.72.250] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18069 invoked from network); 1 Jul 2015 11:47:52 -0000 Received: from millet.cc.columbia.edu (HELO millet.cc.columbia.edu) (128.59.72.250) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 11:47:52 -0000 Received: from hazelnut (hazelnut.cc.columbia.edu [128.59.213.250]) by millet.cc.columbia.edu (8.13.8/8.13.8) with ESMTP id t61BlJ0a029752 for ; Wed, 1 Jul 2015 07:47:51 -0400 Received: from hazelnut (localhost.localdomain [127.0.0.1]) by hazelnut (Postfix) with ESMTP id EDB5A7E for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by hazelnut (Postfix) with ESMTP id D81917E for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id t61BlokY029110 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 1 Jul 2015 07:47:50 -0400 (EDT) Received: by ieqy10 with SMTP id y10so32733658ieq.0 for ; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=PZfV5auK5aGh0PgNfL4Ai3WnC4CZOpe/XGWS5fdNUHc=; b=SDDnfgw61YXmuBfIK6uFWm2jGnpbcxLyjOqFST2LmSXuoLNg795VepeHGjseqIlZyQ Xvst6esUnRep+kBHSnvRUc8aF5z+HNAbMF+TtPvxyO76F+0zhzKuSRYTL4EJ0iI9JVu0 GFo3RfXCPMbmBGpEj23vxXD0/yGfi/ZsmtEFNv8EroLpg/ec5ZLWFOY+gL2igK30OugV pngaKIjF0NTl2h/Jy2JckquCCwg+DxOqUwNs6ezT5EWF7GHLE4+Cr2mCAZQM+AOhg3mf fwgr6P6kV7fyPalIrkdCyk5Vbcxdrnv5v7HDrrjR++IcnMctsAh+ovT5imCY+syK1D9z NBpA== X-Gm-Message-State: ALoCoQn8LDHwURcN97gBnNfmmxkYgnn+6EcebJ1QduHGklGz/fBw53d94PFOv6z3kOa/FtAZv+pmfZH4RvVcXEjl1S2Juf1uqJhpg5tUKN0F1KJZr/Bc5SrANw129fLeuIHK9whWx+ZB X-Received: by 10.107.135.22 with SMTP id j22mr36725663iod.20.1435751270221; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) X-Received: by 10.107.135.22 with SMTP id j22mr36725652iod.20.1435751270092; Wed, 01 Jul 2015 04:47:50 -0700 (PDT) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com. [209.85.213.171]) by mx.google.com with ESMTPSA id a139sm1157140ioa.14.2015.07.01.04.47.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2015 04:47:47 -0700 (PDT) Received: by igcur8 with SMTP id ur8so88855649igc.0 for ; Wed, 01 Jul 2015 04:47:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.167.73 with SMTP id q70mr37417065ioe.82.1435751266365; Wed, 01 Jul 2015 04:47:46 -0700 (PDT) Received: by 10.36.42.5 with HTTP; Wed, 1 Jul 2015 04:47:46 -0700 (PDT) In-Reply-To: <1435740138.21469.230.camel@citrix.com> References: <1435740138.21469.230.camel@citrix.com> Date: Wed, 1 Jul 2015 07:47:46 -0400 Message-ID: From: Jintack Lim To: Ian Campbell X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Setting total number of cpus in the system X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6988375544521247627==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6988375544521247627== Content-Type: multipart/alternative; boundary=001a1142a48037e6c40519cee46d --001a1142a48037e6c40519cee46d Content-Type: text/plain; charset=UTF-8 Hi Ian, On Wed, Jul 1, 2015 at 4:42 AM, Ian Campbell wrote: > On Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote: > > Hi, > > > > > > Is there any way to set the total number of cpus in the system? > > I know how to set the number of cpus for Dom0 and DomU, > > however I was not able to find one for the whole system. > > (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus) > > > > > > The only way I can think of is to modify the device tree. > > Is there more convenient way to do this? > > According to > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html > it should be maxcpus=N, however this doesn't look to be wired up on ARM > (which I'm inferring is what you are interested in). > Yes, I'm working on ARM :) > > Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of > integer_param("maxcpus"...) as inspiration shouldn't be too tricky, > patches welcome! > I quickly hard-coded the number of cpus in xen/arch/arm/setup.c, It worked! thanks! I'll try to make a patch to use the command line option. > Ian. > > > > > --001a1142a48037e6c40519cee46d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ian,

On Wed, Jul 1, 2015 at 4:42 AM, Ian Campbell <<= a href=3D"mailto:ian.campbell@citrix.com" target=3D"_blank" onclick=3D"wind= ow.open('https://mail.google.com/mail/?view=3Dcm&tf=3D1&to=3Dia= n.campbell@citrix.com&cc=3D&bcc=3D&su=3D&body=3D','= _blank');return false;">ian.campbell@citrix.com> wrote:
On= Tue, 2015-06-30 at 15:24 -0400, Jintack Lim wrote:
> Hi,
>
>
> Is there any way to set the total number of cpus in the system?
> I know how to set the number of cpus for Dom0 and DomU,
> however I was not able to find one for the whole system.
> (e.g. I have 8 cpus but I want Xen to recognize only 4 cpus)
>
>
> The only way I can think of is to modify the device tree.
> Is there more convenient way to do this?

According to
http://xenbits.xen.org/docs/unstable/= misc/xen-command-line.html
it should be maxcpus=3DN, however this doesn't look to be wired up on A= RM
(which I'm inferring is what you are interested in).
=C2=A0
Yes, I'm working on ARM :)
=C2=A0

Modifying xen/arch/arm/setup.c using xen/arch/x86/setup.c's handling of=
integer_param("maxcpus"...) as inspiration shouldn't be too t= ricky,
patches welcome!

I quickly hard-coded t= he number of cpus in xen/arch/arm/setup.c,
It worked! thanks!

I'll try to make a patch to use the command line = option.=C2=A0


Ian.





--001a1142a48037e6c40519cee46d-- --===============6988375544521247627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6988375544521247627==-- From xen-users-bounces@lists.xen.org Wed Jul 01 13:15:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 13:15:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAHqE-0002Tg-6r; Wed, 01 Jul 2015 13:14:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAHqC-0002Ta-3u for xen-users@lists.xen.org; Wed, 01 Jul 2015 13:14:16 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 31/EB-31304-7A7E3955; Wed, 01 Jul 2015 13:14:15 +0000 X-Env-Sender: alan@madrooster.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1435756454!18204047!1 X-Originating-IP: [209.188.15.170] X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100, HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7439 invoked from network); 1 Jul 2015 13:14:14 -0000 Received: from phoenix.hosted-servers.net (HELO phoenix.hosted-servers.net) (209.188.15.170) by server-6.tower-206.messagelabs.com with SMTP; 1 Jul 2015 13:14:14 -0000 Received: from phoenix.hosted-servers.net (phoenix.hosted-servers.net [209.188.15.170]) by phoenix.hosted-servers.net (Postfix) with ESMTP id A20E08E071D for ; Wed, 1 Jul 2015 06:14:12 -0700 (MST) From: =?windows-1252?Q?Alan_Lam?= To: =?windows-1252?Q?xen-users=40lists=2Exen=2Eorg?= Date: Wed, 1 Jul 2015 06:14:12 -0700 Mime-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.12-49411 Thread-Index: AdCz/5R4VfM53QEIRuiEFtomHO93uA== Message-Id: Subject: [Xen-users] GPLPV Drivers on Windows X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7793208895592717812==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --===============7793208895592717812== Content-Type: multipart/alternative; boundary="=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX" This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0A=A0=0D=0ADoes anyone know if the GPLPV drivers for Win= dows include PV drivers for interrupts/timers=3F=0D=0A=0D=0A=A0=0D=0AWhat= about the drivers from the Windows PV Driver subproject=3F=0D=0A=0D=0A=A0= =0D=0AAlan=0D=0A=0D=0A --=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =
<= p class=3DMsoNormal>Hi All,

 = ;

Does anyone know if the GPLPV drivers for= Windows include PV drivers for interrupts/timers=3F

 

What about the d= rivers from the Windows PV Driver subproject=3F

 

Alan

--=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX-- --===============7793208895592717812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7793208895592717812==-- From xen-users-bounces@lists.xen.org Wed Jul 01 13:15:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 13:15:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAHqE-0002Tg-6r; Wed, 01 Jul 2015 13:14:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAHqC-0002Ta-3u for xen-users@lists.xen.org; Wed, 01 Jul 2015 13:14:16 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 31/EB-31304-7A7E3955; Wed, 01 Jul 2015 13:14:15 +0000 X-Env-Sender: alan@madrooster.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1435756454!18204047!1 X-Originating-IP: [209.188.15.170] X-SpamReason: No, hits=0.6 required=7.0 tests=FROM_EXCESS_QP,HTML_90_100, HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7439 invoked from network); 1 Jul 2015 13:14:14 -0000 Received: from phoenix.hosted-servers.net (HELO phoenix.hosted-servers.net) (209.188.15.170) by server-6.tower-206.messagelabs.com with SMTP; 1 Jul 2015 13:14:14 -0000 Received: from phoenix.hosted-servers.net (phoenix.hosted-servers.net [209.188.15.170]) by phoenix.hosted-servers.net (Postfix) with ESMTP id A20E08E071D for ; Wed, 1 Jul 2015 06:14:12 -0700 (MST) From: =?windows-1252?Q?Alan_Lam?= To: =?windows-1252?Q?xen-users=40lists=2Exen=2Eorg?= Date: Wed, 1 Jul 2015 06:14:12 -0700 Mime-Version: 1.0 X-Priority: 3 (Normal) X-Mailer: Zarafa 7.1.12-49411 Thread-Index: AdCz/5R4VfM53QEIRuiEFtomHO93uA== Message-Id: Subject: [Xen-users] GPLPV Drivers on Windows X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7793208895592717812==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --===============7793208895592717812== Content-Type: multipart/alternative; boundary="=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX" This is a multi-part message in MIME format. Your mail reader does not understand MIME message format. --=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All,=0D=0A=0D=0A=A0=0D=0ADoes anyone know if the GPLPV drivers for Win= dows include PV drivers for interrupts/timers=3F=0D=0A=0D=0A=A0=0D=0AWhat= about the drivers from the Windows PV Driver subproject=3F=0D=0A=0D=0A=A0= =0D=0AAlan=0D=0A=0D=0A --=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable =
<= p class=3DMsoNormal>Hi All,

 = ;

Does anyone know if the GPLPV drivers for= Windows include PV drivers for interrupts/timers=3F

 

What about the d= rivers from the Windows PV Driver subproject=3F

 

Alan

--=_Au-AY+bjBB3QAn1qZKitclEyk2kdciH8kdRuc+WClEDcQyfX-- --===============7793208895592717812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7793208895592717812==-- From xen-users-bounces@lists.xen.org Wed Jul 01 14:21:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:21:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAIs5-0000Tb-Oe; Wed, 01 Jul 2015 14:20:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAIs4-0000TW-PE for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:20:16 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id C4/31-29123-027F3955; Wed, 01 Jul 2015 14:20:16 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1435760414!28359057!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31346 invoked from network); 1 Jul 2015 14:20:15 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:20:15 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 4E87CC306 for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 2AE3FC2FE for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id 137649E03E for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Message-ID: <5593F71D.3020107@epiontis.com> Date: Wed, 01 Jul 2015 16:20:13 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Length: 2278 X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SGVsbG8sCgpJJ20gbmV3IHRvIFhFTiBsaXZlIG1pZ3JhdGlvbi4gSSBoYXZlIGEgcXVlc3Rpb24g cmVnYXJkaW5nIFhFTiBtZW1vcnkgCm1hbmFnZW1lbnQgd2hpbGUgZG9pbmcgYSB2bSBsaXZlIG1p Z3JhdGlvbi4gSSBvYnNlcnZlZCB0aGF0IG1pZ3JhdGluZyBhIAp2bSBvbiBYRU4gNC41LjEgYW5k IExpbnV4IEtlcm5lbCA0LjEuMCByZXF1aXJlcyB0aGUgZG9tMCBvbiB0aGUgdGFyZ2V0IAptYWNo aW5lIHRvIGhhdmUgbWVtb3J5IGF2YWlsYWJsZSB0aGF0IGlzIHRoZSBzaXplIG9mIHRoZSBtZW1v cnkgCmFsbG9jYXRlZCB0byB0aGUgdm0gKDJHKS4gU2luY2UgSSBmb2xsb3cgIlhFTiBiZXN0IHBy YWN0aWNlcyIgYW5kIHNldCAKZG9tMF9tZW0gdG8gNTEyTSB0aGUgdGFyZ2V0IG1hY2hpbmUgYmVn aW5zIHN3YXBwaW5nIG91dCAyRyB0byBkaXNrIHdoaWNoIAptYWtlcyBldmVyeXRoaW5nIG5lYXJs eSB1bnJlc3BvbnNpdmUuIElzIHRoaXMgcmVxdWlyZW1lbnQgZm9yIHRoZSBkb20wIAptZW1vcnkg c2l6ZSBpbnRlbmRlZCBvciBtaWdodCB0aGVyZSBiZSBhbiBpc3N1ZSB3aXRoIG15IHNldHVwPwoK VGhhbmtzLgoKUmVnYXJkcywKQWxleGFuZGVyCgotLSAKQWxleGFuZGVyIEjDpG1tZXJsZQoKRXBp b250aXMgR21iSApSdWRvd2VyIENoYXVzc2VlIDI5CjEyNDg5IEJlcmxpbgpHZXJtYW55CgpQaG9u ZTogKzQ5IDMwIDYzOTIzNDc4CkZheDogICArNDkgMzAgNjM5MjM0NzYKZU1haWw6IEFsZXhhbmRl ci5IYWVtbWVybGVAZXBpb250aXMuY29tCldXVzogICB3d3cuZXBpb250aXMuY29tCgpHZXNjaMOk ZnRzZsO8aHJlcjoKRHIuIFVscmljaCBIb2ZmbcO8bGxlcgpTdmVuIE9sZWssIFBoRApIZWxnZSBS aWVtZXIKCkFtdHNnZXJpY2h0IENoYXJsb3R0ZW5idXJnCkhSQiA4ODg1OAoKRGllc2UgRS1NYWls IGvDtm5udGUgIHZlcnRyYXVsaWNoZSB1bmQvb2RlciByZWNodGxpY2ggZ2VzY2jDvHR6dGUKSW5m b3JtYXRpb25lbiBlbnRoYWx0ZW4uIEZhbGxzIFNpZSBuaWNodCBkZXIgcmljaHRpZ2UgQWRyZXNz YXQgc2luZCBvZGVyCmRpZXNlIEUtTWFpbCBpcnJ0w7xtbGljaCBlcmhhbHRlbiBoYWJlbiwgaW5m b3JtaWVyZW4gU2llIGJpdHRlIHNvZm9ydCBkZW4KQWJzZW5kZXIgdW5kIHZlcm5pY2h0ZW4gU2ll IGRpZXNlIE1haWwuIERhcyB1bmVybGF1YnRlIEtvcGllcmVuIHNvd2llCmRpZSB1bmJlZnVndGUg V2VpdGVyZ2FiZSBkaWVzZXIgTWFpbCBzaW5kIG5pY2h0IGVybGF1YnQuCgpUaGlzIGUtbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElm CnlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGhhdmUgcmVjZWl2ZWQgdGhp cyBlLW1haWwgaW4KZXJyb3IpIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZGVzdHJveSB0aGlzIGUtbWFpbC4gQW55CnVuYXV0aG9yaXNlZCBjb3B5aW5nLCBkaXNjbG9z dXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgbWF0ZXJpYWwgaW4gdGhpcwplLW1haWwgaXMgc3Ry aWN0bHkgZm9yYmlkZGVuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0cy54ZW4ub3Jn Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Wed Jul 01 14:21:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:21:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAIs5-0000Tb-Oe; Wed, 01 Jul 2015 14:20:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAIs4-0000TW-PE for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:20:16 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id C4/31-29123-027F3955; Wed, 01 Jul 2015 14:20:16 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1435760414!28359057!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31346 invoked from network); 1 Jul 2015 14:20:15 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:20:15 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 4E87CC306 for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 2AE3FC2FE for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id 137649E03E for ; Wed, 1 Jul 2015 16:20:14 +0200 (CEST) Message-ID: <5593F71D.3020107@epiontis.com> Date: Wed, 01 Jul 2015 16:20:13 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Length: 2278 X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SGVsbG8sCgpJJ20gbmV3IHRvIFhFTiBsaXZlIG1pZ3JhdGlvbi4gSSBoYXZlIGEgcXVlc3Rpb24g cmVnYXJkaW5nIFhFTiBtZW1vcnkgCm1hbmFnZW1lbnQgd2hpbGUgZG9pbmcgYSB2bSBsaXZlIG1p Z3JhdGlvbi4gSSBvYnNlcnZlZCB0aGF0IG1pZ3JhdGluZyBhIAp2bSBvbiBYRU4gNC41LjEgYW5k IExpbnV4IEtlcm5lbCA0LjEuMCByZXF1aXJlcyB0aGUgZG9tMCBvbiB0aGUgdGFyZ2V0IAptYWNo aW5lIHRvIGhhdmUgbWVtb3J5IGF2YWlsYWJsZSB0aGF0IGlzIHRoZSBzaXplIG9mIHRoZSBtZW1v cnkgCmFsbG9jYXRlZCB0byB0aGUgdm0gKDJHKS4gU2luY2UgSSBmb2xsb3cgIlhFTiBiZXN0IHBy YWN0aWNlcyIgYW5kIHNldCAKZG9tMF9tZW0gdG8gNTEyTSB0aGUgdGFyZ2V0IG1hY2hpbmUgYmVn aW5zIHN3YXBwaW5nIG91dCAyRyB0byBkaXNrIHdoaWNoIAptYWtlcyBldmVyeXRoaW5nIG5lYXJs eSB1bnJlc3BvbnNpdmUuIElzIHRoaXMgcmVxdWlyZW1lbnQgZm9yIHRoZSBkb20wIAptZW1vcnkg c2l6ZSBpbnRlbmRlZCBvciBtaWdodCB0aGVyZSBiZSBhbiBpc3N1ZSB3aXRoIG15IHNldHVwPwoK VGhhbmtzLgoKUmVnYXJkcywKQWxleGFuZGVyCgotLSAKQWxleGFuZGVyIEjDpG1tZXJsZQoKRXBp b250aXMgR21iSApSdWRvd2VyIENoYXVzc2VlIDI5CjEyNDg5IEJlcmxpbgpHZXJtYW55CgpQaG9u ZTogKzQ5IDMwIDYzOTIzNDc4CkZheDogICArNDkgMzAgNjM5MjM0NzYKZU1haWw6IEFsZXhhbmRl ci5IYWVtbWVybGVAZXBpb250aXMuY29tCldXVzogICB3d3cuZXBpb250aXMuY29tCgpHZXNjaMOk ZnRzZsO8aHJlcjoKRHIuIFVscmljaCBIb2ZmbcO8bGxlcgpTdmVuIE9sZWssIFBoRApIZWxnZSBS aWVtZXIKCkFtdHNnZXJpY2h0IENoYXJsb3R0ZW5idXJnCkhSQiA4ODg1OAoKRGllc2UgRS1NYWls IGvDtm5udGUgIHZlcnRyYXVsaWNoZSB1bmQvb2RlciByZWNodGxpY2ggZ2VzY2jDvHR6dGUKSW5m b3JtYXRpb25lbiBlbnRoYWx0ZW4uIEZhbGxzIFNpZSBuaWNodCBkZXIgcmljaHRpZ2UgQWRyZXNz YXQgc2luZCBvZGVyCmRpZXNlIEUtTWFpbCBpcnJ0w7xtbGljaCBlcmhhbHRlbiBoYWJlbiwgaW5m b3JtaWVyZW4gU2llIGJpdHRlIHNvZm9ydCBkZW4KQWJzZW5kZXIgdW5kIHZlcm5pY2h0ZW4gU2ll IGRpZXNlIE1haWwuIERhcyB1bmVybGF1YnRlIEtvcGllcmVuIHNvd2llCmRpZSB1bmJlZnVndGUg V2VpdGVyZ2FiZSBkaWVzZXIgTWFpbCBzaW5kIG5pY2h0IGVybGF1YnQuCgpUaGlzIGUtbWFpbCBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kL29yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24uIElm CnlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGhhdmUgcmVjZWl2ZWQgdGhp cyBlLW1haWwgaW4KZXJyb3IpIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBh bmQgZGVzdHJveSB0aGlzIGUtbWFpbC4gQW55CnVuYXV0aG9yaXNlZCBjb3B5aW5nLCBkaXNjbG9z dXJlIG9yIGRpc3RyaWJ1dGlvbiBvZiB0aGUgbWF0ZXJpYWwgaW4gdGhpcwplLW1haWwgaXMgc3Ry aWN0bHkgZm9yYmlkZGVuLgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0cy54ZW4ub3Jn Cmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Wed Jul 01 14:30:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:30:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJ2B-0001PB-19; Wed, 01 Jul 2015 14:30:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJ29-0001P0-JM for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:30:41 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 52/42-32733-099F3955; Wed, 01 Jul 2015 14:30:40 +0000 X-Env-Sender: prvs=617539202=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1435761038!28363896!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4748 invoked from network); 1 Jul 2015 14:30:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 14:30:39 -0000 X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="277380433" Message-ID: <1435761032.21469.292.camel@citrix.com> From: Ian Campbell To: Epiontis IT Date: Wed, 1 Jul 2015 15:30:32 +0100 In-Reply-To: <5593F71D.3020107@epiontis.com> References: <5593F71D.3020107@epiontis.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: > Hello, > > I'm new to XEN live migration. I have a question regarding XEN memory > management while doing a vm live migration. I observed that migrating a > vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target > machine to have memory available that is the size of the memory > allocated to the vm (2G). Since I follow "XEN best practices" and set > dom0_mem to 512M the target machine begins swapping out 2G to disk which > makes everything nearly unresponsive. Is this requirement for the dom0 > memory size intended or might there be an issue with my setup? I don't think you should need 2G dom0 memory, you should need 2G of free host memory. Perhaps something on your destination host is thinking it wants to balloon dom0 down in order to make that free host memory available? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 14:30:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:30:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJ2B-0001PB-19; Wed, 01 Jul 2015 14:30:43 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJ29-0001P0-JM for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:30:41 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 52/42-32733-099F3955; Wed, 01 Jul 2015 14:30:40 +0000 X-Env-Sender: prvs=617539202=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1435761038!28363896!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4748 invoked from network); 1 Jul 2015 14:30:39 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 14:30:39 -0000 X-IronPort-AV: E=Sophos;i="5.15,386,1432598400"; d="scan'208";a="277380433" Message-ID: <1435761032.21469.292.camel@citrix.com> From: Ian Campbell To: Epiontis IT Date: Wed, 1 Jul 2015 15:30:32 +0100 In-Reply-To: <5593F71D.3020107@epiontis.com> References: <5593F71D.3020107@epiontis.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: > Hello, > > I'm new to XEN live migration. I have a question regarding XEN memory > management while doing a vm live migration. I observed that migrating a > vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target > machine to have memory available that is the size of the memory > allocated to the vm (2G). Since I follow "XEN best practices" and set > dom0_mem to 512M the target machine begins swapping out 2G to disk which > makes everything nearly unresponsive. Is this requirement for the dom0 > memory size intended or might there be an issue with my setup? I don't think you should need 2G dom0 memory, you should need 2G of free host memory. Perhaps something on your destination host is thinking it wants to balloon dom0 down in order to make that free host memory available? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 14:55:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:55:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJQ5-0005DU-PG; Wed, 01 Jul 2015 14:55:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJQ3-0005D9-FD for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:55:23 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 7B/E3-08467-A5FF3955; Wed, 01 Jul 2015 14:55:22 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1435762521!18209501!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5844 invoked from network); 1 Jul 2015 14:55:22 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:55:22 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 40CA6C306 for ; Wed, 1 Jul 2015 16:55:21 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 01695C2FE for ; Wed, 1 Jul 2015 16:55:21 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id DDDAE9E033 for ; Wed, 1 Jul 2015 16:55:20 +0200 (CEST) Message-ID: <5593FF58.5040405@epiontis.com> Date: Wed, 01 Jul 2015 16:55:20 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> Content-Length: 3575 X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I started out with only one vm running on the sending host, none on the = destination host. Both hosts have dom_0=3D512M and 32GB free memory for = the vms, autoballooning=3D0 is set in xl.conf. As soon as I do a "xl = migrate" the destination host begins swapping out 2GB to disk. In an = earlier setup I had XEN 4.4.1 and Linux 3.18 running and never observed = any swapping as far as I could tell. So from your comment I conclude = that there is some problem with my setup and dom0 doesn't need the vm = memory size available for doing the migration. Thanks, Alexander -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 14:55:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:55:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJQ5-0005DU-PG; Wed, 01 Jul 2015 14:55:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJQ3-0005D9-FD for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:55:23 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 7B/E3-08467-A5FF3955; Wed, 01 Jul 2015 14:55:22 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1435762521!18209501!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5844 invoked from network); 1 Jul 2015 14:55:22 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:55:22 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 40CA6C306 for ; Wed, 1 Jul 2015 16:55:21 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 01695C2FE for ; Wed, 1 Jul 2015 16:55:21 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id DDDAE9E033 for ; Wed, 1 Jul 2015 16:55:20 +0200 (CEST) Message-ID: <5593FF58.5040405@epiontis.com> Date: Wed, 01 Jul 2015 16:55:20 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> Content-Length: 3575 X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I started out with only one vm running on the sending host, none on the = destination host. Both hosts have dom_0=3D512M and 32GB free memory for = the vms, autoballooning=3D0 is set in xl.conf. As soon as I do a "xl = migrate" the destination host begins swapping out 2GB to disk. In an = earlier setup I had XEN 4.4.1 and Linux 3.18 running and never observed = any swapping as far as I could tell. So from your comment I conclude = that there is some problem with my setup and dom0 doesn't need the vm = memory size available for doing the migration. Thanks, Alexander -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 14:56:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:56:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJRA-0005JW-Bv; Wed, 01 Jul 2015 14:56:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJR9-0005JB-Al for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:56:31 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id FB/63-11201-E9FF3955; Wed, 01 Jul 2015 14:56:30 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-2.tower-206.messagelabs.com!1435762587!18228043!1 X-Originating-IP: [209.85.192.177] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29868 invoked from network); 1 Jul 2015 14:56:28 -0000 Received: from mail-pd0-f177.google.com (HELO mail-pd0-f177.google.com) (209.85.192.177) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 14:56:28 -0000 Received: by pdjd13 with SMTP id d13so27207019pdj.0 for ; Wed, 01 Jul 2015 07:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=HLeFMUcbl3NislwAoZgD0ql6iPp8OTvq/CLk6MxAlKE=; b=YCbqUgRp5nHT2AuDzezM3mmpk03h1UMQ+yFhxjJ2dXYkrPRlssQ3IoYqpdFC3JWVyc sihTwbyPZHc5eduqXMyCQCUFUC8fpTYLldy4FvsqzhpGxFPaUBs0NKCe3TbIxczeTK4P LUBsH1H8Cf7xyVqXjuB9Op6/NG8lpAYGr7CaNNywLJVrb0Vp+SftT/QENuMPXMe/abXz TYc775Es8VTJyDymQl26PcxKCszsHjMjOFHOYRtbHfkwY10O7X/hgWhRcL7UoJTQsxLA QXL+gwK2G8nfDiRPWthlygVMAxqxZrhsgyKH3O9t2Agv3viIL66Z3tGUTq+bM7cM1WfS AlqQ== X-Gm-Message-State: ALoCoQltVOa1qgzP01nNvm/fH1zS0Nj0a3BzSnk82dpCLJ6BbMoEBv1cwuPzsf8OhQRE/2j0+RJT X-Received: by 10.66.236.39 with SMTP id ur7mr55828144pac.123.1435762587107; Wed, 01 Jul 2015 07:56:27 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by mx.google.com with ESMTPSA id je4sm2583919pbb.17.2015.07.01.07.56.24 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jul 2015 07:56:25 -0700 (PDT) From: "Brandon" To: Date: Wed, 1 Jul 2015 07:56:23 -0700 Message-ID: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC0DhQ9Wd8I96f9TRK9D7AVhKCWfA== Content-Language: en-us X-Antivirus: avast! (VPS 150701-0, 07/01/2015), Outbound message X-Antivirus-Status: Clean Subject: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6982561637796724113==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multipart message in MIME format. --===============6982561637796724113== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A6_01D0B3D3.6DE54E00" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_01A6_01D0B3D3.6DE54E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Xen User List, I have a recurring bug shown below which is causing me serious problems. It's so serious my company is considering abandoning XEN for KVM but, we have many XEN servers and VMs so this is not an easy decision. My CentOS6 Xen servers are built using SolusVM install script and run Windows 2008 R2 / 2012 R1 guests. They run great except for this recurring bug. The servers are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack and we've been encountering this showstopper bug for the last 6 months or so randomly on different servers. When this BUG is encountered my VM guests will no longer be able to boot if they are restarted. I am forced to reboot the entire server interrupting all VM guests. I've had about 6-7 encounters with this bug. One time it hard crashed the server while I was migrating a VM to another server. The other times I have made it to the weekend so I can do a graceful reboot. Does anyone know of this issue? Is there any paid Xen support that can debug and solve this? I'm using CentOS6 so this is not a RHEL box under support contract but, we'd probably be willing to pay in a per incident type scenario if the cost was reasonable. Any advice is much appreciated. Jul 1 12:45:23 london-host15 kernel: xen-blkback:backend/vbd/86/768: prepare for reconnect Jul 1 12:45:23 london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled state Jul 1 12:45:23 london-host15 kernel: BUG: unable to handle kernel paging request at ffffc90011a041e8 Jul 1 12:45:23 london-host15 kernel: IP: [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: PGD 38cee067 PUD 38cef067 PMD 25e89067 PTE 0 Jul 1 12:45:23 london-host15 kernel: Oops: 0000 [#1] SMP Jul 1 12:45:23 london-host15 kernel: Modules linked in: dm_snapshot ebt_arp ebt_ip ebtable_filter ebtables tun xen_pciback xen_gntalloc bridge stp llc xt_REDIRECT xt_owner nf_nat_ftp nf_conntrack_ftp xt_length xt_hl xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_LOG xt_DSCP xt_dscp ipt_REJECT iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_acpi_processor blktap xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd gpio_ich iTCO_wdt iTCO_vendor_support joydev coretemp freq_table mperf crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd microcode pcspkr sg i2c_i801 lpc_ich igb ptp pps_core shpchp ipmi_devintf ipmi_si ipmi_msghandler ioatdma dca acpi_power_meter hwmon ext4 jbd2 mbcache sd_mod crc_t10dif xhci_hcd ahci libahci wmi ttm drm_kms_helper dm_mirror dm_region_hash dm_log dm_mod Jul 1 12:45:23 london-host15 kernel: CPU: 2 PID: 940 Comm: netback/2 Not tainted 3.10.68-11.el6.centos.alt.x86_64 #1 Jul 1 12:45:23 london-host15 kernel: Hardware name: Supermicro X10DRL-i/X10DRL-i, BIOS 1.0b 08/28/2014 Jul 1 12:45:23 london-host15 kernel: task: ffff88003535ecb0 ti: ffff88003526a000 task.ti: ffff88003526a000 Jul 1 12:45:23 london-host15 kernel: RIP: e030:[] [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: RSP: e02b:ffff88003526bcd8 EFLAGS: 00010202 Jul 1 12:45:23 london-host15 kernel: RAX: ffffc900105aa040 RBX: ffff880034ce9280 RCX: ffffc90011a04000 Jul 1 12:45:23 london-host15 kernel: RDX: 000000000000003d RSI: 0000000000000000 RDI: ffff8800059e5000 Jul 1 12:45:23 london-host15 kernel: RBP: ffff88003526bd48 R08: 0000000000000000 R09: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: R13: 0000000000000000 R14: ffff88003526bd98 R15: ffff880009e1f800 Jul 1 12:45:23 london-host15 kernel: FS: 0000000000000000(0000) GS:ffff88003f880000(0000) knlGS:0000000000000000 Jul 1 12:45:23 london-host15 kernel: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 1 12:45:23 london-host15 kernel: CR2: ffffc90011a041e8 CR3: 000000000486f000 CR4: 0000000000042660 Jul 1 12:45:23 london-host15 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 1 12:45:23 london-host15 kernel: Stack: Jul 1 12:45:23 london-host15 kernel: 0000000000000000 0000000000000002 000000003526bd08 ffffffff8100392e Jul 1 12:45:23 london-host15 kernel: 0000000000000000 000000003535ecb0 ffff88003526bd78 00000001815f9bd7 Jul 1 12:45:23 london-host15 kernel: ffff88003526bd48 ffff880034ce9280 0000000000000000 0000000000000000 Jul 1 12:45:23 london-host15 kernel: Call Trace: Jul 1 12:45:23 london-host15 kernel: [] ? xen_end_context_switch+0x1e/0x30 Jul 1 12:45:23 london-host15 kernel: [] xen_netbk_rx_action+0xe5/0x600 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] ? _raw_spin_unlock_irqrestore+0x17/0x20 Jul 1 12:45:23 london-host15 kernel: [] xen_netbk_kthread+0x80/0x1b0 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] ? wake_up_bit+0x40/0x40 Jul 1 12:45:23 london-host15 kernel: [] ? xen_netbk_tx_build_gops+0x8b0/0x8b0 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] kthread+0xce/0xe0 Jul 1 12:45:23 london-host15 kernel: [] ? kthread_freezable_should_stop+0x70/0x70 Jul 1 12:45:23 london-host15 kernel: [] ret_from_fork+0x7c/0xb0 Jul 1 12:45:23 london-host15 kernel: [] ? kthread_freezable_should_stop+0x70/0x70 Jul 1 12:45:23 london-host15 kernel: Code: 47 60 04 0f 85 89 01 00 00 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 02 89 70 08 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 89 30 41 c7 46 20 00 00 00 00 8b 44 d1 04 41 89 46 Jul 1 12:45:23 london-host15 kernel: RIP [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: RSP Jul 1 12:45:23 london-host15 kernel: CR2: ffffc90011a041e8 Jul 1 12:45:23 london-host15 kernel: ---[ end trace 0926a1200e28f127 ]--- Jul 1 12:45:23 london-host15 kernel: device vifvm2696.0 left promiscuous mode Jul 1 12:45:23 london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled state -------------- [root@london-host15 ~]# xl info host : london-host15.domain.net release : 3.10.68-11.el6.centos.alt.x86_64 version : #1 SMP Fri Feb 6 10:40:16 CST 2015 machine : x86_64 nr_cpus : 6 max_cpu_id : 5 nr_nodes : 1 cores_per_socket : 6 threads_per_core : 1 cpu_mhz : 2400 hw_caps : bfebfbff:2c100800:00000000:00007f00:75fefbff:00000000:00000021:000037ab virt_caps : hvm hvm_directio total_memory : 32661 free_memory : 15374 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .2-2.el6 xen_version : 4.4.2-2.el6 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Thu Apr 23 15:06:13 2015 +0100 git:82363f6-dirty xen_commandline : dom0_mem=1024M,max:1536M loglvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date : Wed May 13 12:28:01 UTC 2015 xend_config_format : 4 [root@london-host15 ~]# ------=_NextPart_000_01A6_01D0B3D3.6DE54E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xen = User List,

 

I have a recurring bug shown below which is causing me = serious problems.   It’s so serious my company is = considering abandoning XEN for KVM but, we have many XEN servers and VMs = so this is not an easy decision.   My CentOS6 Xen servers are = built using SolusVM install script and run Windows 2008 R2 / 2012 R1 = guests.   They run great except for this recurring = bug.   

 

The servers = are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack = and we’ve been encountering this showstopper bug for the last 6 = months or so randomly on different servers.   When this BUG is = encountered my VM guests will no longer be able to boot if they are = restarted.   I am forced to reboot the entire server = interrupting all VM guests.   I’ve had about 6-7 = encounters with this bug.   One time it hard crashed the = server while I was migrating a VM to another server.   The = other times I have made it to the weekend so I can do a graceful = reboot.

 

Does anyone know of this issue?

 

Is there any = paid Xen support that can debug and solve this?   I’m = using CentOS6 so this is not a RHEL box under support contract but, = we’d probably be willing to pay in a per incident type scenario if = the cost was reasonable.

 

Any advice = is much appreciated.

 

Jul  1 = 12:45:23 london-host15 kernel: xen-blkback:backend/vbd/86/768: prepare = for reconnect

Jul  1 12:45:23 = london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled = state

Jul  1 12:45:23 = london-host15 kernel: BUG: unable to handle kernel paging request at = ffffc90011a041e8

Jul  1 12:45:23 = london-host15 kernel: IP: [<ffffffffa026e899>] = netbk_gop_skb+0xb9/0x290 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: PGD = 38cee067 PUD 38cef067 PMD 25e89067 PTE 0

Jul  1 12:45:23 london-host15 kernel: Oops: 0000 = [#1] SMP

Jul  1 12:45:23 = london-host15 kernel: Modules linked in: dm_snapshot ebt_arp ebt_ip = ebtable_filter ebtables tun xen_pciback xen_gntalloc bridge stp llc = xt_REDIRECT xt_owner nf_nat_ftp nf_conntrack_ftp xt_length xt_hl = xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_LOG xt_DSCP xt_dscp = ipt_REJECT iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 = nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ip6t_REJECT = nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter = ip6_tables ipv6 xen_acpi_processor blktap xen_netback xen_blkback = xen_gntdev xen_evtchn xenfs xen_privcmd gpio_ich iTCO_wdt = iTCO_vendor_support joydev coretemp freq_table mperf crc32_pclmul = crc32c_intel ghash_clmulni_intel cryptd microcode pcspkr sg i2c_i801 = lpc_ich igb ptp pps_core shpchp ipmi_devintf ipmi_si ipmi_msghandler = ioatdma dca acpi_power_meter hwmon ext4 jbd2 mbcache sd_mod crc_t10dif = xhci_hcd ahci libahci wmi ttm drm_kms_helper dm_mirror dm_region_hash = dm_log dm_mod

Jul  1 12:45:23 = london-host15 kernel: CPU: 2 PID: 940 Comm: netback/2 Not tainted = 3.10.68-11.el6.centos.alt.x86_64 #1

Jul  1 12:45:23 london-host15 kernel: Hardware = name: Supermicro X10DRL-i/X10DRL-i, BIOS 1.0b = 08/28/2014

Jul  1 12:45:23 = london-host15 kernel: task: ffff88003535ecb0 ti: ffff88003526a000 = task.ti: ffff88003526a000

Jul  1 = 12:45:23 london-host15 kernel: RIP: = e030:[<ffffffffa026e899>]  [<ffffffffa026e899>] = netbk_gop_skb+0xb9/0x290 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: RSP: = e02b:ffff88003526bcd8  EFLAGS: 00010202

Jul  1 12:45:23 london-host15 kernel: RAX: = ffffc900105aa040 RBX: ffff880034ce9280 RCX: = ffffc90011a04000

Jul  1 12:45:23 = london-host15 kernel: RDX: 000000000000003d RSI: 0000000000000000 RDI: = ffff8800059e5000

Jul  1 12:45:23 = london-host15 kernel: RBP: ffff88003526bd48 R08: 0000000000000000 R09: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: R10: 0000000000007ff0 R11: 0000000000000002 R12: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: R13: 0000000000000000 R14: ffff88003526bd98 R15: = ffff880009e1f800

Jul  1 12:45:23 = london-host15 kernel: FS:  0000000000000000(0000) = GS:ffff88003f880000(0000) knlGS:0000000000000000

Jul  1 12:45:23 london-host15 kernel: CS:  = e033 DS: 0000 ES: 0000 CR0: 0000000080050033

Jul  1 12:45:23 london-host15 kernel: CR2: = ffffc90011a041e8 CR3: 000000000486f000 CR4: = 0000000000042660

Jul  1 12:45:23 = london-host15 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: = 0000000000000400

Jul  1 12:45:23 = london-host15 kernel: Stack:

Jul  1 12:45:23 london-host15 kernel: = 0000000000000000 0000000000000002 000000003526bd08 = ffffffff8100392e

Jul  1 12:45:23 = london-host15 kernel: 0000000000000000 000000003535ecb0 ffff88003526bd78 = 00000001815f9bd7

Jul  1 12:45:23 = london-host15 kernel: ffff88003526bd48 ffff880034ce9280 0000000000000000 = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: Call Trace:

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff8100392e>] ? = xen_end_context_switch+0x1e/0x30

Jul  1 12:45:23 london-host15 kernel: = [<ffffffffa026eb55>] xen_netbk_rx_action+0xe5/0x600 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: [<ffffffff815f9bd7>] ? = _raw_spin_unlock_irqrestore+0x17/0x20

Jul  1 12:45:23 london-host15 kernel: = [<ffffffffa0270df0>] xen_netbk_kthread+0x80/0x1b0 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: [<ffffffff810828d0>] ? = wake_up_bit+0x40/0x40

Jul  1 = 12:45:23 london-host15 kernel: [<ffffffffa0270d70>] ? = xen_netbk_tx_build_gops+0x8b0/0x8b0 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff810820be>] kthread+0xce/0xe0

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81081ff0>] ? = kthread_freezable_should_stop+0x70/0x70

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81602cec>] ret_from_fork+0x7c/0xb0

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81081ff0>] ? = kthread_freezable_should_stop+0x70/0x70

Jul  1 12:45:23 london-host15 kernel: Code: 47 60 = 04 0f 85 89 01 00 00 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 = 02 89 70 08 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 = 89 30 41 c7 46 20 00 00 00 00 8b 44 d1 04 41 89 46

Jul  1 12:45:23 london-host15 kernel: RIP  = [<ffffffffa026e899>] netbk_gop_skb+0xb9/0x290 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: RSP <ffff88003526bcd8>

Jul  1 12:45:23 london-host15 kernel: CR2: = ffffc90011a041e8

Jul  1 12:45:23 = london-host15 kernel: ---[ end trace 0926a1200e28f127 = ]---

Jul  1 12:45:23 = london-host15 kernel: device vifvm2696.0 left promiscuous = mode

Jul  1 12:45:23 = london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled = state

 

--------------

 

[root@london-host15 ~]# xl info

host        &nb= sp;          : = london-host15.domain.net

release    =             := 3.10.68-11.el6.centos.alt.x86_64

version        =         : #1 SMP Fri Feb 6 10:40:16 = CST 2015

machine        =         : x86_64

nr_cpus        =         : 6

max_cpu_id       &nb= sp;     : 5

nr_nodes        = ;       : 1

cores_per_socket       : = 6

threads_per_core       : = 1

cpu_mhz        =         : 2400

hw_caps        =         : = bfebfbff:2c100800:00000000:00007f00:75fefbff:00000000:00000021:000037ab

virt_caps       &nbs= p;      : hvm hvm_directio

total_memory       &= nbsp;   : 32661

free_memory       &n= bsp;    : 15374

sharing_freed_memory   : 0

sharing_used_memory    : = 0

outstanding_claims     : = 0

free_cpus       &nbs= p;      : 0

xen_major       &nbs= p;      : 4

xen_minor       &nbs= p;      : 4

xen_extra       &nbs= p;      : .2-2.el6

xen_version       &n= bsp;    : 4.4.2-2.el6

xen_caps        = ;       : xen-3.0-x86_64 xen-3.0-x86_32p = hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

xen_scheduler       =    : credit

xen_pagesize       &= nbsp;   : 4096

platform_params      &nbs= p; : virt_start=3D0xffff800000000000

xen_changeset       =    : Thu Apr 23 15:06:13 2015 +0100 = git:82363f6-dirty

xen_commandline      &nbs= p; : dom0_mem=3D1024M,max:1536M loglvl=3Dall = guest_loglvl=3Dall

cc_compiler       &n= bsp;    : gcc (GCC) 4.4.7 20120313 (Red Hat = 4.4.7-11)

cc_compile_by       =    : mockbuild

cc_compile_domain      : = centos.org

cc_compile_date      &nbs= p; : Wed May 13 12:28:01 UTC 2015

xend_config_format     : = 4

[root@london-host15 = ~]#

------=_NextPart_000_01A6_01D0B3D3.6DE54E00-- --===============6982561637796724113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6982561637796724113==-- From xen-users-bounces@lists.xen.org Wed Jul 01 14:56:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 14:56:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJRA-0005JW-Bv; Wed, 01 Jul 2015 14:56:32 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJR9-0005JB-Al for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:56:31 +0000 Received: from [85.158.139.211] by server-10.bemta-5.messagelabs.com id FB/63-11201-E9FF3955; Wed, 01 Jul 2015 14:56:30 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-2.tower-206.messagelabs.com!1435762587!18228043!1 X-Originating-IP: [209.85.192.177] X-SpamReason: No, hits=1.1 required=7.0 tests=BODY_RANDOM_LONG, HTML_40_50,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29868 invoked from network); 1 Jul 2015 14:56:28 -0000 Received: from mail-pd0-f177.google.com (HELO mail-pd0-f177.google.com) (209.85.192.177) by server-2.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 14:56:28 -0000 Received: by pdjd13 with SMTP id d13so27207019pdj.0 for ; Wed, 01 Jul 2015 07:56:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=HLeFMUcbl3NislwAoZgD0ql6iPp8OTvq/CLk6MxAlKE=; b=YCbqUgRp5nHT2AuDzezM3mmpk03h1UMQ+yFhxjJ2dXYkrPRlssQ3IoYqpdFC3JWVyc sihTwbyPZHc5eduqXMyCQCUFUC8fpTYLldy4FvsqzhpGxFPaUBs0NKCe3TbIxczeTK4P LUBsH1H8Cf7xyVqXjuB9Op6/NG8lpAYGr7CaNNywLJVrb0Vp+SftT/QENuMPXMe/abXz TYc775Es8VTJyDymQl26PcxKCszsHjMjOFHOYRtbHfkwY10O7X/hgWhRcL7UoJTQsxLA QXL+gwK2G8nfDiRPWthlygVMAxqxZrhsgyKH3O9t2Agv3viIL66Z3tGUTq+bM7cM1WfS AlqQ== X-Gm-Message-State: ALoCoQltVOa1qgzP01nNvm/fH1zS0Nj0a3BzSnk82dpCLJ6BbMoEBv1cwuPzsf8OhQRE/2j0+RJT X-Received: by 10.66.236.39 with SMTP id ur7mr55828144pac.123.1435762587107; Wed, 01 Jul 2015 07:56:27 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by mx.google.com with ESMTPSA id je4sm2583919pbb.17.2015.07.01.07.56.24 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jul 2015 07:56:25 -0700 (PDT) From: "Brandon" To: Date: Wed, 1 Jul 2015 07:56:23 -0700 Message-ID: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC0DhQ9Wd8I96f9TRK9D7AVhKCWfA== Content-Language: en-us X-Antivirus: avast! (VPS 150701-0, 07/01/2015), Outbound message X-Antivirus-Status: Clean Subject: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6982561637796724113==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multipart message in MIME format. --===============6982561637796724113== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A6_01D0B3D3.6DE54E00" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_01A6_01D0B3D3.6DE54E00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Xen User List, I have a recurring bug shown below which is causing me serious problems. It's so serious my company is considering abandoning XEN for KVM but, we have many XEN servers and VMs so this is not an easy decision. My CentOS6 Xen servers are built using SolusVM install script and run Windows 2008 R2 / 2012 R1 guests. They run great except for this recurring bug. The servers are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack and we've been encountering this showstopper bug for the last 6 months or so randomly on different servers. When this BUG is encountered my VM guests will no longer be able to boot if they are restarted. I am forced to reboot the entire server interrupting all VM guests. I've had about 6-7 encounters with this bug. One time it hard crashed the server while I was migrating a VM to another server. The other times I have made it to the weekend so I can do a graceful reboot. Does anyone know of this issue? Is there any paid Xen support that can debug and solve this? I'm using CentOS6 so this is not a RHEL box under support contract but, we'd probably be willing to pay in a per incident type scenario if the cost was reasonable. Any advice is much appreciated. Jul 1 12:45:23 london-host15 kernel: xen-blkback:backend/vbd/86/768: prepare for reconnect Jul 1 12:45:23 london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled state Jul 1 12:45:23 london-host15 kernel: BUG: unable to handle kernel paging request at ffffc90011a041e8 Jul 1 12:45:23 london-host15 kernel: IP: [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: PGD 38cee067 PUD 38cef067 PMD 25e89067 PTE 0 Jul 1 12:45:23 london-host15 kernel: Oops: 0000 [#1] SMP Jul 1 12:45:23 london-host15 kernel: Modules linked in: dm_snapshot ebt_arp ebt_ip ebtable_filter ebtables tun xen_pciback xen_gntalloc bridge stp llc xt_REDIRECT xt_owner nf_nat_ftp nf_conntrack_ftp xt_length xt_hl xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_LOG xt_DSCP xt_dscp ipt_REJECT iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 xen_acpi_processor blktap xen_netback xen_blkback xen_gntdev xen_evtchn xenfs xen_privcmd gpio_ich iTCO_wdt iTCO_vendor_support joydev coretemp freq_table mperf crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd microcode pcspkr sg i2c_i801 lpc_ich igb ptp pps_core shpchp ipmi_devintf ipmi_si ipmi_msghandler ioatdma dca acpi_power_meter hwmon ext4 jbd2 mbcache sd_mod crc_t10dif xhci_hcd ahci libahci wmi ttm drm_kms_helper dm_mirror dm_region_hash dm_log dm_mod Jul 1 12:45:23 london-host15 kernel: CPU: 2 PID: 940 Comm: netback/2 Not tainted 3.10.68-11.el6.centos.alt.x86_64 #1 Jul 1 12:45:23 london-host15 kernel: Hardware name: Supermicro X10DRL-i/X10DRL-i, BIOS 1.0b 08/28/2014 Jul 1 12:45:23 london-host15 kernel: task: ffff88003535ecb0 ti: ffff88003526a000 task.ti: ffff88003526a000 Jul 1 12:45:23 london-host15 kernel: RIP: e030:[] [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: RSP: e02b:ffff88003526bcd8 EFLAGS: 00010202 Jul 1 12:45:23 london-host15 kernel: RAX: ffffc900105aa040 RBX: ffff880034ce9280 RCX: ffffc90011a04000 Jul 1 12:45:23 london-host15 kernel: RDX: 000000000000003d RSI: 0000000000000000 RDI: ffff8800059e5000 Jul 1 12:45:23 london-host15 kernel: RBP: ffff88003526bd48 R08: 0000000000000000 R09: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: R10: 0000000000007ff0 R11: 0000000000000002 R12: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: R13: 0000000000000000 R14: ffff88003526bd98 R15: ffff880009e1f800 Jul 1 12:45:23 london-host15 kernel: FS: 0000000000000000(0000) GS:ffff88003f880000(0000) knlGS:0000000000000000 Jul 1 12:45:23 london-host15 kernel: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 1 12:45:23 london-host15 kernel: CR2: ffffc90011a041e8 CR3: 000000000486f000 CR4: 0000000000042660 Jul 1 12:45:23 london-host15 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Jul 1 12:45:23 london-host15 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Jul 1 12:45:23 london-host15 kernel: Stack: Jul 1 12:45:23 london-host15 kernel: 0000000000000000 0000000000000002 000000003526bd08 ffffffff8100392e Jul 1 12:45:23 london-host15 kernel: 0000000000000000 000000003535ecb0 ffff88003526bd78 00000001815f9bd7 Jul 1 12:45:23 london-host15 kernel: ffff88003526bd48 ffff880034ce9280 0000000000000000 0000000000000000 Jul 1 12:45:23 london-host15 kernel: Call Trace: Jul 1 12:45:23 london-host15 kernel: [] ? xen_end_context_switch+0x1e/0x30 Jul 1 12:45:23 london-host15 kernel: [] xen_netbk_rx_action+0xe5/0x600 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] ? _raw_spin_unlock_irqrestore+0x17/0x20 Jul 1 12:45:23 london-host15 kernel: [] xen_netbk_kthread+0x80/0x1b0 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] ? wake_up_bit+0x40/0x40 Jul 1 12:45:23 london-host15 kernel: [] ? xen_netbk_tx_build_gops+0x8b0/0x8b0 [xen_netback] Jul 1 12:45:23 london-host15 kernel: [] kthread+0xce/0xe0 Jul 1 12:45:23 london-host15 kernel: [] ? kthread_freezable_should_stop+0x70/0x70 Jul 1 12:45:23 london-host15 kernel: [] ret_from_fork+0x7c/0xb0 Jul 1 12:45:23 london-host15 kernel: [] ? kthread_freezable_should_stop+0x70/0x70 Jul 1 12:45:23 london-host15 kernel: Code: 47 60 04 0f 85 89 01 00 00 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 02 89 70 08 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 89 30 41 c7 46 20 00 00 00 00 8b 44 d1 04 41 89 46 Jul 1 12:45:23 london-host15 kernel: RIP [] netbk_gop_skb+0xb9/0x290 [xen_netback] Jul 1 12:45:23 london-host15 kernel: RSP Jul 1 12:45:23 london-host15 kernel: CR2: ffffc90011a041e8 Jul 1 12:45:23 london-host15 kernel: ---[ end trace 0926a1200e28f127 ]--- Jul 1 12:45:23 london-host15 kernel: device vifvm2696.0 left promiscuous mode Jul 1 12:45:23 london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled state -------------- [root@london-host15 ~]# xl info host : london-host15.domain.net release : 3.10.68-11.el6.centos.alt.x86_64 version : #1 SMP Fri Feb 6 10:40:16 CST 2015 machine : x86_64 nr_cpus : 6 max_cpu_id : 5 nr_nodes : 1 cores_per_socket : 6 threads_per_core : 1 cpu_mhz : 2400 hw_caps : bfebfbff:2c100800:00000000:00007f00:75fefbff:00000000:00000021:000037ab virt_caps : hvm hvm_directio total_memory : 32661 free_memory : 15374 sharing_freed_memory : 0 sharing_used_memory : 0 outstanding_claims : 0 free_cpus : 0 xen_major : 4 xen_minor : 4 xen_extra : .2-2.el6 xen_version : 4.4.2-2.el6 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params : virt_start=0xffff800000000000 xen_changeset : Thu Apr 23 15:06:13 2015 +0100 git:82363f6-dirty xen_commandline : dom0_mem=1024M,max:1536M loglvl=all guest_loglvl=all cc_compiler : gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11) cc_compile_by : mockbuild cc_compile_domain : centos.org cc_compile_date : Wed May 13 12:28:01 UTC 2015 xend_config_format : 4 [root@london-host15 ~]# ------=_NextPart_000_01A6_01D0B3D3.6DE54E00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Xen = User List,

 

I have a recurring bug shown below which is causing me = serious problems.   It’s so serious my company is = considering abandoning XEN for KVM but, we have many XEN servers and VMs = so this is not an easy decision.   My CentOS6 Xen servers are = built using SolusVM install script and run Windows 2008 R2 / 2012 R1 = guests.   They run great except for this recurring = bug.   

 

The servers = are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack = and we’ve been encountering this showstopper bug for the last 6 = months or so randomly on different servers.   When this BUG is = encountered my VM guests will no longer be able to boot if they are = restarted.   I am forced to reboot the entire server = interrupting all VM guests.   I’ve had about 6-7 = encounters with this bug.   One time it hard crashed the = server while I was migrating a VM to another server.   The = other times I have made it to the weekend so I can do a graceful = reboot.

 

Does anyone know of this issue?

 

Is there any = paid Xen support that can debug and solve this?   I’m = using CentOS6 so this is not a RHEL box under support contract but, = we’d probably be willing to pay in a per incident type scenario if = the cost was reasonable.

 

Any advice = is much appreciated.

 

Jul  1 = 12:45:23 london-host15 kernel: xen-blkback:backend/vbd/86/768: prepare = for reconnect

Jul  1 12:45:23 = london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled = state

Jul  1 12:45:23 = london-host15 kernel: BUG: unable to handle kernel paging request at = ffffc90011a041e8

Jul  1 12:45:23 = london-host15 kernel: IP: [<ffffffffa026e899>] = netbk_gop_skb+0xb9/0x290 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: PGD = 38cee067 PUD 38cef067 PMD 25e89067 PTE 0

Jul  1 12:45:23 london-host15 kernel: Oops: 0000 = [#1] SMP

Jul  1 12:45:23 = london-host15 kernel: Modules linked in: dm_snapshot ebt_arp ebt_ip = ebtable_filter ebtables tun xen_pciback xen_gntalloc bridge stp llc = xt_REDIRECT xt_owner nf_nat_ftp nf_conntrack_ftp xt_length xt_hl = xt_tcpmss xt_TCPMSS xt_multiport xt_limit xt_LOG xt_DSCP xt_dscp = ipt_REJECT iptable_filter iptable_mangle iptable_nat nf_conntrack_ipv4 = nf_defrag_ipv4 nf_nat_ipv4 nf_nat ip_tables ip6t_REJECT = nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter = ip6_tables ipv6 xen_acpi_processor blktap xen_netback xen_blkback = xen_gntdev xen_evtchn xenfs xen_privcmd gpio_ich iTCO_wdt = iTCO_vendor_support joydev coretemp freq_table mperf crc32_pclmul = crc32c_intel ghash_clmulni_intel cryptd microcode pcspkr sg i2c_i801 = lpc_ich igb ptp pps_core shpchp ipmi_devintf ipmi_si ipmi_msghandler = ioatdma dca acpi_power_meter hwmon ext4 jbd2 mbcache sd_mod crc_t10dif = xhci_hcd ahci libahci wmi ttm drm_kms_helper dm_mirror dm_region_hash = dm_log dm_mod

Jul  1 12:45:23 = london-host15 kernel: CPU: 2 PID: 940 Comm: netback/2 Not tainted = 3.10.68-11.el6.centos.alt.x86_64 #1

Jul  1 12:45:23 london-host15 kernel: Hardware = name: Supermicro X10DRL-i/X10DRL-i, BIOS 1.0b = 08/28/2014

Jul  1 12:45:23 = london-host15 kernel: task: ffff88003535ecb0 ti: ffff88003526a000 = task.ti: ffff88003526a000

Jul  1 = 12:45:23 london-host15 kernel: RIP: = e030:[<ffffffffa026e899>]  [<ffffffffa026e899>] = netbk_gop_skb+0xb9/0x290 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: RSP: = e02b:ffff88003526bcd8  EFLAGS: 00010202

Jul  1 12:45:23 london-host15 kernel: RAX: = ffffc900105aa040 RBX: ffff880034ce9280 RCX: = ffffc90011a04000

Jul  1 12:45:23 = london-host15 kernel: RDX: 000000000000003d RSI: 0000000000000000 RDI: = ffff8800059e5000

Jul  1 12:45:23 = london-host15 kernel: RBP: ffff88003526bd48 R08: 0000000000000000 R09: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: R10: 0000000000007ff0 R11: 0000000000000002 R12: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: R13: 0000000000000000 R14: ffff88003526bd98 R15: = ffff880009e1f800

Jul  1 12:45:23 = london-host15 kernel: FS:  0000000000000000(0000) = GS:ffff88003f880000(0000) knlGS:0000000000000000

Jul  1 12:45:23 london-host15 kernel: CS:  = e033 DS: 0000 ES: 0000 CR0: 0000000080050033

Jul  1 12:45:23 london-host15 kernel: CR2: = ffffc90011a041e8 CR3: 000000000486f000 CR4: = 0000000000042660

Jul  1 12:45:23 = london-host15 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: = 0000000000000400

Jul  1 12:45:23 = london-host15 kernel: Stack:

Jul  1 12:45:23 london-host15 kernel: = 0000000000000000 0000000000000002 000000003526bd08 = ffffffff8100392e

Jul  1 12:45:23 = london-host15 kernel: 0000000000000000 000000003535ecb0 ffff88003526bd78 = 00000001815f9bd7

Jul  1 12:45:23 = london-host15 kernel: ffff88003526bd48 ffff880034ce9280 0000000000000000 = 0000000000000000

Jul  1 12:45:23 = london-host15 kernel: Call Trace:

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff8100392e>] ? = xen_end_context_switch+0x1e/0x30

Jul  1 12:45:23 london-host15 kernel: = [<ffffffffa026eb55>] xen_netbk_rx_action+0xe5/0x600 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: [<ffffffff815f9bd7>] ? = _raw_spin_unlock_irqrestore+0x17/0x20

Jul  1 12:45:23 london-host15 kernel: = [<ffffffffa0270df0>] xen_netbk_kthread+0x80/0x1b0 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: [<ffffffff810828d0>] ? = wake_up_bit+0x40/0x40

Jul  1 = 12:45:23 london-host15 kernel: [<ffffffffa0270d70>] ? = xen_netbk_tx_build_gops+0x8b0/0x8b0 [xen_netback]

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff810820be>] kthread+0xce/0xe0

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81081ff0>] ? = kthread_freezable_should_stop+0x70/0x70

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81602cec>] ret_from_fork+0x7c/0xb0

Jul  1 12:45:23 london-host15 kernel: = [<ffffffff81081ff0>] ? = kthread_freezable_should_stop+0x70/0x70

Jul  1 12:45:23 london-host15 kernel: Code: 47 60 = 04 0f 85 89 01 00 00 8b b3 d0 00 00 00 48 8b bb d8 00 00 00 0f b7 74 37 = 02 89 70 08 89 d2 c7 40 04 00 00 00 00 48 83 c2 08 <0f> b7 34 d1 = 89 30 41 c7 46 20 00 00 00 00 8b 44 d1 04 41 89 46

Jul  1 12:45:23 london-host15 kernel: RIP  = [<ffffffffa026e899>] netbk_gop_skb+0xb9/0x290 = [xen_netback]

Jul  1 12:45:23 = london-host15 kernel: RSP <ffff88003526bcd8>

Jul  1 12:45:23 london-host15 kernel: CR2: = ffffc90011a041e8

Jul  1 12:45:23 = london-host15 kernel: ---[ end trace 0926a1200e28f127 = ]---

Jul  1 12:45:23 = london-host15 kernel: device vifvm2696.0 left promiscuous = mode

Jul  1 12:45:23 = london-host15 kernel: br0: port 8(vifvm2696.0) entered disabled = state

 

--------------

 

[root@london-host15 ~]# xl info

host        &nb= sp;          : = london-host15.domain.net

release    =             := 3.10.68-11.el6.centos.alt.x86_64

version        =         : #1 SMP Fri Feb 6 10:40:16 = CST 2015

machine        =         : x86_64

nr_cpus        =         : 6

max_cpu_id       &nb= sp;     : 5

nr_nodes        = ;       : 1

cores_per_socket       : = 6

threads_per_core       : = 1

cpu_mhz        =         : 2400

hw_caps        =         : = bfebfbff:2c100800:00000000:00007f00:75fefbff:00000000:00000021:000037ab

virt_caps       &nbs= p;      : hvm hvm_directio

total_memory       &= nbsp;   : 32661

free_memory       &n= bsp;    : 15374

sharing_freed_memory   : 0

sharing_used_memory    : = 0

outstanding_claims     : = 0

free_cpus       &nbs= p;      : 0

xen_major       &nbs= p;      : 4

xen_minor       &nbs= p;      : 4

xen_extra       &nbs= p;      : .2-2.el6

xen_version       &n= bsp;    : 4.4.2-2.el6

xen_caps        = ;       : xen-3.0-x86_64 xen-3.0-x86_32p = hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64

xen_scheduler       =    : credit

xen_pagesize       &= nbsp;   : 4096

platform_params      &nbs= p; : virt_start=3D0xffff800000000000

xen_changeset       =    : Thu Apr 23 15:06:13 2015 +0100 = git:82363f6-dirty

xen_commandline      &nbs= p; : dom0_mem=3D1024M,max:1536M loglvl=3Dall = guest_loglvl=3Dall

cc_compiler       &n= bsp;    : gcc (GCC) 4.4.7 20120313 (Red Hat = 4.4.7-11)

cc_compile_by       =    : mockbuild

cc_compile_domain      : = centos.org

cc_compile_date      &nbs= p; : Wed May 13 12:28:01 UTC 2015

xend_config_format     : = 4

[root@london-host15 = ~]#

------=_NextPart_000_01A6_01D0B3D3.6DE54E00-- --===============6982561637796724113== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6982561637796724113==-- From xen-users-bounces@lists.xen.org Wed Jul 01 15:56:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 15:56:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKMB-0003e1-BJ; Wed, 01 Jul 2015 15:55:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKMA-0003du-Nl for xen-users@lists.xen.org; Wed, 01 Jul 2015 15:55:26 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 14/0C-31650-D6D04955; Wed, 01 Jul 2015 15:55:25 +0000 X-Env-Sender: srn@prgmr.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1435766124!28348847!1 X-Originating-IP: [71.19.149.6] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10777 invoked from network); 1 Jul 2015 15:55:24 -0000 Received: from mail.prgmr.com (HELO mail.prgmr.com) (71.19.149.6) by server-10.tower-27.messagelabs.com with SMTP; 1 Jul 2015 15:55:24 -0000 Received: from [192.168.1.3] (173-228-60-9.dsl.dynamic.fusionbroadband.com [173.228.60.9]) (Authenticated sender: srn) by mail.prgmr.com (Postfix) with ESMTPSA id 8001128C001; Wed, 1 Jul 2015 12:00:45 -0400 (EDT) Message-ID: <55940D6A.2050304@prgmr.com> Date: Wed, 01 Jul 2015 08:55:22 -0700 From: Sarah Newman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon , xen-users@lists.xen.org References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> In-Reply-To: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> Content-Length: 1846 Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 07:56 AM, Brandon wrote: > Hi Xen User List, > = > = > = > I have a recurring bug shown below which is causing me serious problems. = It=92s so serious my company is considering abandoning XEN for KVM but, we > have many XEN servers and VMs so this is not an easy decision. My CentO= S6 Xen servers are built using SolusVM install script and run Windows 2008 = R2 > / 2012 R1 guests. They run great except for this recurring bug. = > = > = > = > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL T= oolstack and we=92ve been encountering this showstopper bug for the last 6 > months or so randomly on different servers. When this BUG is encountere= d my VM guests will no longer be able to boot if they are restarted. I am > forced to reboot the entire server interrupting all VM guests. I=92ve h= ad about 6-7 encounters with this bug. One time it hard crashed the server > while I was migrating a VM to another server. The other times I have ma= de it to the weekend so I can do a graceful reboot. > = > = > = > Does anyone know of this issue? > = > = > = > Is there any paid Xen support that can debug and solve this? I=92m usin= g CentOS6 so this is not a RHEL box under support contract but, we=92d prob= ably > be willing to pay in a per incident type scenario if the cost was reasona= ble. > = > = > = > Any advice is much appreciated. > = Looks like it might be http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oop= s-in-xen-netbk-rx-action-xenvif-gop-skb According to Wei Liu the bug is gone in version 3.12 or later, though I hav= e not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days ago. Regards, Sarah _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 15:56:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 15:56:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKMB-0003e1-BJ; Wed, 01 Jul 2015 15:55:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKMA-0003du-Nl for xen-users@lists.xen.org; Wed, 01 Jul 2015 15:55:26 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 14/0C-31650-D6D04955; Wed, 01 Jul 2015 15:55:25 +0000 X-Env-Sender: srn@prgmr.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1435766124!28348847!1 X-Originating-IP: [71.19.149.6] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10777 invoked from network); 1 Jul 2015 15:55:24 -0000 Received: from mail.prgmr.com (HELO mail.prgmr.com) (71.19.149.6) by server-10.tower-27.messagelabs.com with SMTP; 1 Jul 2015 15:55:24 -0000 Received: from [192.168.1.3] (173-228-60-9.dsl.dynamic.fusionbroadband.com [173.228.60.9]) (Authenticated sender: srn) by mail.prgmr.com (Postfix) with ESMTPSA id 8001128C001; Wed, 1 Jul 2015 12:00:45 -0400 (EDT) Message-ID: <55940D6A.2050304@prgmr.com> Date: Wed, 01 Jul 2015 08:55:22 -0700 From: Sarah Newman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon , xen-users@lists.xen.org References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> In-Reply-To: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> Content-Length: 1846 Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 07:56 AM, Brandon wrote: > Hi Xen User List, > = > = > = > I have a recurring bug shown below which is causing me serious problems. = It=92s so serious my company is considering abandoning XEN for KVM but, we > have many XEN servers and VMs so this is not an easy decision. My CentO= S6 Xen servers are built using SolusVM install script and run Windows 2008 = R2 > / 2012 R1 guests. They run great except for this recurring bug. = > = > = > = > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL T= oolstack and we=92ve been encountering this showstopper bug for the last 6 > months or so randomly on different servers. When this BUG is encountere= d my VM guests will no longer be able to boot if they are restarted. I am > forced to reboot the entire server interrupting all VM guests. I=92ve h= ad about 6-7 encounters with this bug. One time it hard crashed the server > while I was migrating a VM to another server. The other times I have ma= de it to the weekend so I can do a graceful reboot. > = > = > = > Does anyone know of this issue? > = > = > = > Is there any paid Xen support that can debug and solve this? I=92m usin= g CentOS6 so this is not a RHEL box under support contract but, we=92d prob= ably > be willing to pay in a per incident type scenario if the cost was reasona= ble. > = > = > = > Any advice is much appreciated. > = Looks like it might be http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oop= s-in-xen-netbk-rx-action-xenvif-gop-skb According to Wei Liu the bug is gone in version 3.12 or later, though I hav= e not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days ago. Regards, Sarah _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 16:09:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 16:09:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKZ4-0005Dp-IW; Wed, 01 Jul 2015 16:08:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKZ4-0005Dk-2z for xen-users@lists.xen.org; Wed, 01 Jul 2015 16:08:46 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 7B/22-31650-D8014955; Wed, 01 Jul 2015 16:08:45 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-15.tower-27.messagelabs.com!1435766922!28415782!1 X-Originating-IP: [209.85.192.170] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10131 invoked from network); 1 Jul 2015 16:08:44 -0000 Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 16:08:44 -0000 Received: by pdcu2 with SMTP id u2so28564570pdc.3 for ; Wed, 01 Jul 2015 09:08:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=wPLFUqWUQVMVY/Ffg4oJz0z9hsaRHHBZyk8uTbDSkzo=; b=leyNXOLDvM5/USCPiun9lzJEYcED1FqYpRYx551uTgoqekX/IIU5t843oz04rS1ULC vJ3uJ3WAlMmw/U5IuGoN3Mq+gH1x6RoKx3f6t7evY1x+hVmzU4OSzs0JFvxtJ7YIjJLt ciLZ/Z+zEQtm5SEVjMyBNhwkxI683DgVtmj3r85JyXvvWxAEc5r6eELeXzWiNItvlBgN ZN+lJJnvFU/c0ROIgdy+QGhWGTMLfZ3o8beaeqh/hhPtGeLwV02f5K7weTtN7OTBjLNT afWaz1qVys22oWmcxjPDHHNLlBfCWGp8z4wSyEORx/ILQc6OG1ECZk4dByBKhCtBbOse ELqA== X-Gm-Message-State: ALoCoQndJPbnmEGk6nUM/jRVER0jfmeTctHziXfy3E6yJGX8dMenUoNQSXSzqXKqvxNkhYWcGbf8 X-Received: by 10.67.30.102 with SMTP id kd6mr56288331pad.132.1435766922539; Wed, 01 Jul 2015 09:08:42 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by mx.google.com with ESMTPSA id ml10sm2751115pab.47.2015.07.01.09.08.40 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jul 2015 09:08:41 -0700 (PDT) From: "Brandon" To: "'Sarah Newman'" , References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> <55940D6A.2050304@prgmr.com> In-Reply-To: <55940D6A.2050304@prgmr.com> Date: Wed, 1 Jul 2015 09:08:39 -0700 Message-ID: <022401d0b418$327975e0$976c61a0$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFMmuQ6aUtN5tNaLbU+/ImnvMYPDgKQcptjnrp2a4A= Content-Language: en-us X-Antivirus: avast! (VPS 150701-0, 07/01/2015), Outbound message X-Antivirus-Status: Clean Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Sarah and List, Thanks so much for the reply and info. I am running 3.10.68-11.el6.centos.alt.x86_64 most everywhere so I will upgrade asap. -----Original Message----- From: Sarah Newman [mailto:srn@prgmr.com] Sent: Wednesday, July 01, 2015 8:55 AM To: Brandon; xen-users@lists.xen.org Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 On 07/01/2015 07:56 AM, Brandon wrote: > Hi Xen User List, > > > > I have a recurring bug shown below which is causing me serious problems. It's so serious my company is considering abandoning XEN for KVM but, we > have many XEN servers and VMs so this is not an easy decision. My CentOS6 Xen servers are built using SolusVM install script and run Windows 2008 R2 > / 2012 R1 guests. They run great except for this recurring bug. > > > > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack and we've been encountering this showstopper bug for the last 6 > months or so randomly on different servers. When this BUG is encountered my VM guests will no longer be able to boot if they are restarted. I am > forced to reboot the entire server interrupting all VM guests. I've had about 6-7 encounters with this bug. One time it hard crashed the server > while I was migrating a VM to another server. The other times I have made it to the weekend so I can do a graceful reboot. > > > > Does anyone know of this issue? > > > > Is there any paid Xen support that can debug and solve this? I'm using CentOS6 so this is not a RHEL box under support contract but, we'd probably > be willing to pay in a per incident type scenario if the cost was reasonable. > > > > Any advice is much appreciated. > Looks like it might be http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oops-in-xen-netbk-rx-action -xenvif-gop-skb According to Wei Liu the bug is gone in version 3.12 or later, though I have not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days ago. Regards, Sarah _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 16:09:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 16:09:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKZ4-0005Dp-IW; Wed, 01 Jul 2015 16:08:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAKZ4-0005Dk-2z for xen-users@lists.xen.org; Wed, 01 Jul 2015 16:08:46 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 7B/22-31650-D8014955; Wed, 01 Jul 2015 16:08:45 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-15.tower-27.messagelabs.com!1435766922!28415782!1 X-Originating-IP: [209.85.192.170] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10131 invoked from network); 1 Jul 2015 16:08:44 -0000 Received: from mail-pd0-f170.google.com (HELO mail-pd0-f170.google.com) (209.85.192.170) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 1 Jul 2015 16:08:44 -0000 Received: by pdcu2 with SMTP id u2so28564570pdc.3 for ; Wed, 01 Jul 2015 09:08:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=wPLFUqWUQVMVY/Ffg4oJz0z9hsaRHHBZyk8uTbDSkzo=; b=leyNXOLDvM5/USCPiun9lzJEYcED1FqYpRYx551uTgoqekX/IIU5t843oz04rS1ULC vJ3uJ3WAlMmw/U5IuGoN3Mq+gH1x6RoKx3f6t7evY1x+hVmzU4OSzs0JFvxtJ7YIjJLt ciLZ/Z+zEQtm5SEVjMyBNhwkxI683DgVtmj3r85JyXvvWxAEc5r6eELeXzWiNItvlBgN ZN+lJJnvFU/c0ROIgdy+QGhWGTMLfZ3o8beaeqh/hhPtGeLwV02f5K7weTtN7OTBjLNT afWaz1qVys22oWmcxjPDHHNLlBfCWGp8z4wSyEORx/ILQc6OG1ECZk4dByBKhCtBbOse ELqA== X-Gm-Message-State: ALoCoQndJPbnmEGk6nUM/jRVER0jfmeTctHziXfy3E6yJGX8dMenUoNQSXSzqXKqvxNkhYWcGbf8 X-Received: by 10.67.30.102 with SMTP id kd6mr56288331pad.132.1435766922539; Wed, 01 Jul 2015 09:08:42 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by mx.google.com with ESMTPSA id ml10sm2751115pab.47.2015.07.01.09.08.40 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 01 Jul 2015 09:08:41 -0700 (PDT) From: "Brandon" To: "'Sarah Newman'" , References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> <55940D6A.2050304@prgmr.com> In-Reply-To: <55940D6A.2050304@prgmr.com> Date: Wed, 1 Jul 2015 09:08:39 -0700 Message-ID: <022401d0b418$327975e0$976c61a0$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFMmuQ6aUtN5tNaLbU+/ImnvMYPDgKQcptjnrp2a4A= Content-Language: en-us X-Antivirus: avast! (VPS 150701-0, 07/01/2015), Outbound message X-Antivirus-Status: Clean Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Sarah and List, Thanks so much for the reply and info. I am running 3.10.68-11.el6.centos.alt.x86_64 most everywhere so I will upgrade asap. -----Original Message----- From: Sarah Newman [mailto:srn@prgmr.com] Sent: Wednesday, July 01, 2015 8:55 AM To: Brandon; xen-users@lists.xen.org Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 On 07/01/2015 07:56 AM, Brandon wrote: > Hi Xen User List, > > > > I have a recurring bug shown below which is causing me serious problems. It's so serious my company is considering abandoning XEN for KVM but, we > have many XEN servers and VMs so this is not an easy decision. My CentOS6 Xen servers are built using SolusVM install script and run Windows 2008 R2 > / 2012 R1 guests. They run great except for this recurring bug. > > > > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL Toolstack and we've been encountering this showstopper bug for the last 6 > months or so randomly on different servers. When this BUG is encountered my VM guests will no longer be able to boot if they are restarted. I am > forced to reboot the entire server interrupting all VM guests. I've had about 6-7 encounters with this bug. One time it hard crashed the server > while I was migrating a VM to another server. The other times I have made it to the weekend so I can do a graceful reboot. > > > > Does anyone know of this issue? > > > > Is there any paid Xen support that can debug and solve this? I'm using CentOS6 so this is not a RHEL box under support contract but, we'd probably > be willing to pay in a per incident type scenario if the cost was reasonable. > > > > Any advice is much appreciated. > Looks like it might be http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oops-in-xen-netbk-rx-action -xenvif-gop-skb According to Wei Liu the bug is gone in version 3.12 or later, though I have not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days ago. Regards, Sarah _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 18:41:59 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 18:41:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAMwh-0000p8-Lv; Wed, 01 Jul 2015 18:41:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJO3-00053N-JY for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:53:19 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 04/52-25925-EDEF3955; Wed, 01 Jul 2015 14:53:18 +0000 X-Env-Sender: Alexander.Haemmerle@epiontis.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1435762398!12826715!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15544 invoked from network); 1 Jul 2015 14:53:18 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:53:18 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 98BCAC306 for ; Wed, 1 Jul 2015 16:53:17 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 667A6C2FE for ; Wed, 1 Jul 2015 16:53:17 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id CCD889E033 for ; Wed, 1 Jul 2015 16:53:16 +0200 (CEST) Message-ID: <5593FEDC.2090907@epiontis.com> Date: Wed, 01 Jul 2015 16:53:16 +0200 From: =?windows-1252?Q?Alexander_H=E4mmerle?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> Content-Length: 2607 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 01 Jul 2015 18:41:18 +0000 Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I started out with only one vm running on the sending host, none on the = destination host. Both hosts have dom_0=3D512M and 32GB free memory for = the vms, autoballooning=3D0 is set in xl.conf. As soon as I do a "xl = migrate" the destination host begins swapping out 2GB to disk. In an = earlier setup I had XEN 4.4.1 and Linux 3.18 running and never observed = any swapping as far as I could tell. So from your comment I conclude = that there is some problem with my setup and dom0 doesn't need the vm = memory size available for doing the migration. Thanks, Alexander -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 01 18:41:59 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 01 Jul 2015 18:41:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAMwh-0000p8-Lv; Wed, 01 Jul 2015 18:41:19 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAJO3-00053N-JY for xen-users@lists.xen.org; Wed, 01 Jul 2015 14:53:19 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 04/52-25925-EDEF3955; Wed, 01 Jul 2015 14:53:18 +0000 X-Env-Sender: Alexander.Haemmerle@epiontis.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1435762398!12826715!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15544 invoked from network); 1 Jul 2015 14:53:18 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 1 Jul 2015 14:53:18 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 98BCAC306 for ; Wed, 1 Jul 2015 16:53:17 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 667A6C2FE for ; Wed, 1 Jul 2015 16:53:17 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id CCD889E033 for ; Wed, 1 Jul 2015 16:53:16 +0200 (CEST) Message-ID: <5593FEDC.2090907@epiontis.com> Date: Wed, 01 Jul 2015 16:53:16 +0200 From: =?windows-1252?Q?Alexander_H=E4mmerle?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> Content-Length: 2607 X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Wed, 01 Jul 2015 18:41:18 +0000 Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I started out with only one vm running on the sending host, none on the = destination host. Both hosts have dom_0=3D512M and 32GB free memory for = the vms, autoballooning=3D0 is set in xl.conf. As soon as I do a "xl = migrate" the destination host begins swapping out 2GB to disk. In an = earlier setup I had XEN 4.4.1 and Linux 3.18 running and never observed = any swapping as far as I could tell. So from your comment I conclude = that there is some problem with my setup and dom0 doesn't need the vm = memory size available for doing the migration. Thanks, Alexander -- = Alexander H=E4mmerle Epiontis GmbH Rudower Chaussee 29 12489 Berlin Germany Phone: +49 30 63923478 Fax: +49 30 63923476 eMail: Alexander.Haemmerle@epiontis.com WWW: www.epiontis.com Gesch=E4ftsf=FChrer: Dr. Ulrich Hoffm=FCller Sven Olek, PhD Helge Riemer Amtsgericht Charlottenburg HRB 88858 Diese E-Mail k=F6nnte vertrauliche und/oder rechtlich gesch=FCtzte Informationen enthalten. Falls Sie nicht der richtige Adressat sind oder diese E-Mail irrt=FCmlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht erlaubt. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 00:27:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 00:27:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZASL1-0002lt-K9; Thu, 02 Jul 2015 00:26:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZASKz-0002lV-S7 for xen-users@lists.xen.org; Thu, 02 Jul 2015 00:26:46 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 13/47-00727-54584955; Thu, 02 Jul 2015 00:26:45 +0000 X-Env-Sender: josh.drenan@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1435796803!21800367!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_10_20,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2577 invoked from network); 2 Jul 2015 00:26:44 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 00:26:44 -0000 Received: by iebmu5 with SMTP id mu5so45976207ieb.1 for ; Wed, 01 Jul 2015 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=EjPAoXhPtiAwfu4A9dWE/ienbADoMHNyv+s5K2m/tTg=; b=zv1ZPOruPEuq//g7G9llndrRgRwx3gn01ov18bMVW78jrLXJrvdQMmpBO7sxKkwMlZ vKYSgy4s35sfl1DqxjrNEXsmfaKSXSNcZlPF0qVCaNaqoxrLWypAcuv105AxWOL5Jlqx LYA7cGyHKeh5ZvuMxue0HttBAdfzX8gbFiTczcXa5oCzUa/g+MCNR9xOvA3GSf6x69C2 gi074iWM7rK9/lGCAkqNxTSgkfgzVLqvjkAccP1VZvMRmtcKjUSSnTHFppkrL2lOgudA IdqecbDFoOAUx1ivL9MmnqcvBxIa70aY4iUkK093ihRNc7ejf6Fcez/bm8H5SWFS+WTw Dqmw== X-Received: by 10.107.138.201 with SMTP id c70mr42993394ioj.24.1435796803128; Wed, 01 Jul 2015 17:26:43 -0700 (PDT) MIME-Version: 1.0 From: Josh Drenan Date: Thu, 02 Jul 2015 00:26:32 +0000 Message-ID: To: "xen-users@lists.xen.org" Content-Type: multipart/mixed; boundary=001a113e8e6a6cb0960519d97e41 Subject: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --001a113e8e6a6cb0960519d97e41 Content-Type: multipart/alternative; boundary=001a113e8e6a6cb0900519d97e3f --001a113e8e6a6cb0900519d97e3f Content-Type: text/plain; charset=UTF-8 Greetings all I have an error where dom0 freezes during boot and was wondering if anyone could help. I have tried using most of the acpi command line options to no avail. I am trying to boot xen as a virtual machine inside of ESXI, it works if the total number of cores is less than or equal to 8 but no more for some reason. I have included the log from the boot. --001a113e8e6a6cb0900519d97e3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings all I have an error where dom0 =C2=A0freezes dur= ing boot and was wondering if anyone could help. I have tried using most of= the acpi command line options to no avail.

I am trying = to boot xen as a virtual machine inside of ESXI, it works if the total numb= er of cores is less than or equal to 8 but no more for some reason.

I have included the log from the boot.
--001a113e8e6a6cb0900519d97e3f-- --001a113e8e6a6cb0960519d97e41 Content-Type: application/octet-stream; name="Xen_console2.log" Content-Disposition: attachment; filename="Xen_console2.log" Content-Transfer-Encoding: base64 X-Attachment-Id: 14e4c2786e2b3be390f1 IFhlbiA0LjQuMA0KKFhFTikgWGVuIHZlcnNpb24gNC40LjAgKGJ1aWxkQCkgKGdjYyAoR0NDKSA0 LjQuNyAyMDEyMDMxMyAoUmVkIEhhdCA0LjQuNy00KSkgZGVidWc9biBUdWUgSnVuIDMwIDA2OjEy OjI4IFBEVCAyMDE1DQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0Og0KKFhFTikgQ29uc29sZSBvdXRw dXQgaXMgc3luY2hyb25vdXMuDQooWEVOKSBCb290bG9hZGVyOiBHTlUgR1JVQiAwLjk3DQooWEVO KSBDb21tYW5kIGxpbmU6IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBkb20wX21lbT04NzA0 TSBib290c2NydWI9ZmFsc2UgZG9tMF9tYXhfdmNwdXM9OCBkb20wX3ZjcHVzX3Bpbj10cnVlIG5t aT1kb20wIHdhdGNoZG9nPXRydWUgY29tMT0xMTUyMDAgY29uc29sZT1jb20xLHZnYSBzeW5jX2Nv bnNvbGU9dHJ1ZQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQg bW9kZSA4MHgyNSwgZm9udCA4eDE2DQooWEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZv dW5kIDEgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1 Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAg LSAwMDAwMDAwMDAwMDlmNDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5ZjQwMCAtIDAw MDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwY2EwMDAgLSAwMDAw MDAwMDAwMGNjMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGRjMDAwIC0gMDAwMDAw MDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAw YmZlZTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGJmZWUwMDAwIC0gMDAwMDAwMDBiZmVm ZjAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYmZlZmYwMDAgLSAwMDAwMDAwMGJmZjAw MDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGJmZjAwMDAwIC0gMDAwMDAwMDBjMDAwMDAw MCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGYwMDAwMDAwIChy ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMxMDAwMCAocmVz ZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2Vy dmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZmZTAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZl ZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMGM0MDAwMDAwMCAodXNhYmxlKQ0K KFhFTikgQUNQSTogUlNEUCAwMDBGNkI4MCwgMDAyNCAocjIgUFRMVEQgKQ0KKFhFTikgQUNQSTog WFNEVCBCRkVFRTc4MCwgMDA1QyAocjEgSU5URUwgIDQ0MEJYICAgICA2MDQwMDAwIFZNVyAgIDEz MjQyNzIpDQooWEVOKSBBQ1BJOiBGQUNQIEJGRUZFRTk4LCAwMEY0IChyNCBJTlRFTCAgNDQwQlgg ICAgIDYwNDAwMDAgUFRMICAgICBGNDI0MCkNCihYRU4pIEFDUEk6IERTRFQgQkZFRUVDMjIsIDEw Mjc2IChyMSBQVExURCAgQ3VzdG9tICAgIDYwNDAwMDAgTVNGVCAgMzAwMDAwMSkNCihYRU4pIEFD UEk6IEZBQ1MgQkZFRkZGQzAsIDAwNDANCihYRU4pIEFDUEk6IEJPT1QgQkZFRUVCRkEsIDAwMjgg KHIxIFBUTFREICAkU0JGVEJMJCAgNjA0MDAwMCAgTFRQICAgICAgICAxKQ0KKFhFTikgQUNQSTog QVBJQyBCRkVFRUFEOCwgMDEyMiAocjEgUFRMVEQgICAgICAgIEFQSUMgICAgNjA0MDAwMCAgTFRQ ICAgICAgICAwKQ0KKFhFTikgQUNQSTogTUNGRyBCRkVFRUE5QywgMDAzQyAocjEgUFRMVEQgICRQ Q0lUQkwkICA2MDQwMDAwICBMVFAgICAgICAgIDEpDQooWEVOKSBBQ1BJOiBTUkFUIEJGRUVFODdD LCAwMjIwIChyMiBWTVdBUkUgTUVNUExVRyAgIDYwNDAwMDAgVk1XICAgICAgICAgMSkNCihYRU4p IEFDUEk6IEhQRVQgQkZFRUU4NDQsIDAwMzggKHIxIFZNV0FSRSBWTVcgSFBFVCAgNjA0MDAwMCBW TVcgICAgICAgICAxKQ0KKFhFTikgQUNQSTogV0FFVCBCRkVFRTgxQywgMDAyOCAocjEgVk1XQVJF IFZNVyBXQUVUICA2MDQwMDAwIFZNVyAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA0OTE1 MU1CICg1MDMzMTEzMmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0K KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg LT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUg MA0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA0IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDogUFhN IDEgLT4gQVBJQyA1IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA2IC0+IE5v ZGUgMQ0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA3IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDog UFhNIDIgLT4gQVBJQyA4IC0+IE5vZGUgMg0KKFhFTikgU1JBVDogUFhNIDIgLT4gQVBJQyA5IC0+ IE5vZGUgMg0KKFhFTikgU1JBVDogUFhNIDIgLT4gQVBJQyAxMCAtPiBOb2RlIDINCihYRU4pIFNS QVQ6IFBYTSAyIC0+IEFQSUMgMTEgLT4gTm9kZSAyDQooWEVOKSBTUkFUOiBQWE0gMyAtPiBBUElD IDEyIC0+IE5vZGUgMw0KKFhFTikgU1JBVDogUFhNIDMgLT4gQVBJQyAxMyAtPiBOb2RlIDMNCihY RU4pIFNSQVQ6IFBYTSAzIC0+IEFQSUMgMTQgLT4gTm9kZSAzDQooWEVOKSBTUkFUOiBQWE0gMyAt PiBBUElDIDE1IC0+IE5vZGUgMw0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihY RU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYzAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUg MCBQWE0gMCAxMDAwMDAwMDAtMzQwMDAwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDEgUFhNIDEgMzQw MDAwMDAwLTY0MDAwMDAwMA0KKFhFTikgU1JBVDogTm9kZSAyIFBYTSAyIDY0MDAwMDAwMC05NDAw MDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMyBQWE0gMyA5NDAwMDAwMDAtYzQwMDAwMDAwDQooWEVO KSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIGMzYjViMTAwMCAtIGMzYjViZTAwMA0K KFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4gaGVh cCBpbml0aWFsaXNlZCBETUEgd2lkdGggMzEgYml0cw0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl IGF0IDAwMGY2YmYwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVy IGJpZ3NtcA0KKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHgxMDA4DQooWEVOKSBBQ1BJ OiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxMDA0LDBdLCBwbTF4X2V2dFsxMDAwLDBdDQooWEVOKSBB Q1BJOiAgICAgICAgICAgICB3YWtldXBfdmVjW2JmZWZmZmNjXSwgdmVjX3NpemVbMjBdDQooWEVO KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMg KGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj MCA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0g bGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSA2OjEyIEFQSUMgdmVy c2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0g ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4p IFByb2Nlc3NvciAjMyA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFj cGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCA2 OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFw aWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNSA2OjEyIEFQSUMgdmVyc2lv biAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNl0gZW5h YmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNiA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkNCihYRU4pIFBy b2Nlc3NvciAjNyA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwOF0gbGFwaWNfaWRbMHgwOF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjOCA2OjEy IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNf aWRbMHgwOV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjOSA2OjEyIEFQSUMgdmVyc2lvbiAy MQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYV0gbGFwaWNfaWRbMHgwYV0gZW5hYmxl ZCkNCihYRU4pIFByb2Nlc3NvciAjMTAgNjoxMiBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MGJdIGxhcGljX2lkWzB4MGJdIGVuYWJsZWQpDQooWEVOKSBQcm9j ZXNzb3IgIzExIDY6MTIgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDBjXSBsYXBpY19pZFsweDBjXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxMiA2OjEy IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZF0gbGFwaWNf aWRbMHgwZF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMTMgNjoxMiBBUElDIHZlcnNpb24g MjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGVdIGxhcGljX2lkWzB4MGVdIGVuYWJs ZWQpDQooWEVOKSBQcm9jZXNzb3IgIzE0IDY6MTIgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJ OiBMQVBJQyAoYWNwaV9pZFsweDBmXSBsYXBpY19pZFsweDBmXSBlbmFibGVkKQ0KKFhFTikgUHJv Y2Vzc29yICMxNSA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDBdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkg KGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExBUElDX05N SSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTogTEFQSUNf Tk1JIChhY3BpX2lkWzB4MDNdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExB UElDX05NSSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTog TEFQSUNfTk1JIChhY3BpX2lkWzB4MDZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFD UEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA4XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikg QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDldIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVO KSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihY RU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBiXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0K KFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGNdIGhpZ2ggZWRnZSBsaW50WzB4MV0p DQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwZF0gaGlnaCBlZGdlIGxpbnRbMHgx XSkNCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBlXSBoaWdoIGVkZ2UgbGludFsw eDFdKQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGZdIGhpZ2ggZWRnZSBsaW50 WzB4MV0pDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MTBdIGFkZHJlc3NbMHhmZWMwMDAwMF0g Z3NpX2Jhc2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMTYsIHZlcnNpb24gMTcsIGFk ZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMg MCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGhpZ2ggZWRnZSkNCihYRU4pIEFDUEk6IElSUTAgdXNl ZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4p IEVuYWJsaW5nIEFQSUMgbW9kZTogIFBoeXMuICBVc2luZyAxIEkvTyBBUElDcw0KKFhFTikgQUNQ STogSFBFVCBpZDogMHg4MDg2YWYwMSBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBFUlNUIHRhYmxl IHdhcyBub3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyAxNiBDUFVzICgwIGhvdHBsdWcg Q1BVcykNCihYRU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgMzA2NCBNU0kvTVNJLVgNCihYRU4pIE5v dCBlbmFibGluZyB4MkFQSUM6IGRlcGVuZHMgb24gaW9tbXVfc3VwcG9ydHNfZWltLg0KKFhFTikg VXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0 ZWN0ZWQgMjY2NS40NzggTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJp bmcuDQooWEVOKSBDUFUwOiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBw b3J0IGRpc2FibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAw MDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBl MDAwMDAwMCByZXNlcnZlZCBpbiBFODIwDQooWEVOKSBQQ0k6IFVzaW5nIE1DRkcgZm9yIHNlZ21l bnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBkaXNhYmxlZA0KKFhF TikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QN CihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9 LTENCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUDQooWEVOKSBBbGxvY2F0 ZWQgY29uc29sZSByaW5nIG9mIDEyOCBLaUIuDQooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNl ZCBmZWF0dXJlczoNCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgIC0gRXh0ZW5kZWQg UGFnZSBUYWJsZXMgKEVQVCkNCihYRU4pICAtIFZpcnR1YWwtUHJvY2Vzc29yIElkZW50aWZpZXJz IChWUElEKQ0KKFhFTikgIC0gVmlydHVhbCBOTUkNCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNz IGJpdG1hcA0KKFhFTikgIC0gVW5yZXN0cmljdGVkIEd1ZXN0DQooWEVOKSBIVk06IEFTSURzIGVu YWJsZWQuDQooWEVOKSBIVk06IFZNWCBlbmFibGVkDQooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lz dGVkIFBhZ2luZyAoSEFQKSBub3QgZGV0ZWN0ZWQNCihYRU4pIEhWTTogUFZIIG1vZGUgbm90IHN1 cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtDQooWEVOKSBDUFUxOiBObyBNQ0UgYmFua3MgcHJlc2Vu dC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUyOiBObyBNQ0UgYmFu a3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUzOiBO byBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVO KSBDUFU0OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2Fi bGVkDQooWEVOKSBDUFU1OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBw b3J0IGRpc2FibGVkDQooWEVOKSBDUFU2OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBj aGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU3OiBObyBNQ0UgYmFua3MgcHJlc2VudC4g TWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU4OiBObyBNQ0UgYmFua3Mg cHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU5OiBObyBN Q0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBD UFUxMDogTm8gTUNFIGJhbmtzIHByZXNlbnQuIE1hY2hpbmUgY2hlY2sgc3VwcG9ydCBkaXNhYmxl ZA0KKFhFTikgQ1BVMTE6IE5vIE1DRSBiYW5rcyBwcmVzZW50LiBNYWNoaW5lIGNoZWNrIHN1cHBv cnQgZGlzYWJsZWQNCihYRU4pIENQVTEyOiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBj aGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUxMzogTm8gTUNFIGJhbmtzIHByZXNlbnQu IE1hY2hpbmUgY2hlY2sgc3VwcG9ydCBkaXNhYmxlZA0KKFhFTikgQ1BVMTQ6IE5vIE1DRSBiYW5r cyBwcmVzZW50LiBNYWNoaW5lIGNoZWNrIHN1cHBvcnQgZGlzYWJsZWQNCihYRU4pIENQVTE1OiBO byBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVO KSBCcm91Z2h0IHVwIDE2IENQVXMNCihYRU4pIFRlc3RpbmcgTk1JIHdhdGNoZG9nIC0tLSBDUFUj MCBva2F5LiBDUFUjMSBva2F5LiBDUFUjMiBva2F5LiBDUFUjMyBva2F5LiBDUFUjNCBva2F5LiBD UFUjNSBva2F5LiBDUFUjNiBva2F5LiBDUFUjNyBva2F5LiBDUFUjOCBva2F5LiBDUFUjOSBva2F5 LiBDUFUjMTAgb2theS4gQ1BVIzExIG9rYXkuIENQVSMxMiBva2F5LiBDUFUjMTMgb2theS4gQ1BV IzE0IG9rYXkuIENQVSMxNSBva2F5Lg0KKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMNCihYRU4p ICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxz YiwgY29tcGF0MzINCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIg MHgxMDAwMDAwIC0+IDB4MjdmMzAwMA0KKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5U Og0KKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyMzgwMDAwMDAtPjAwMDAwMDAyM2MwMDAw MDAgKDIyMDA1OTMgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgIEluaXQuIHJhbWRpc2s6 IDAwMDAwMDBjM2Q0MTEwMDAtPjAwMDAwMDBjM2ZmZmZjMDANCihYRU4pIFZJUlRVQUwgTUVNT1JZ IEFSUkFOR0VNRU5UOg0KKFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZm ZmZmZmZmODI3ZjMwMDANCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyN2YzMDAwLT5m ZmZmZmZmZjg1M2UxYzAwDQooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4NTNlMjAwMC0+ ZmZmZmZmZmY4NjRlMjAwMA0KKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODY0ZTIwMDAt PmZmZmZmZmZmODY0ZTI0YjQNCihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg2NGUzMDAw LT5mZmZmZmZmZjg2NTFhMDAwDQooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NjUxYTAw MC0+ZmZmZmZmZmY4NjUxYjAwMA0KKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAw MDAtPmZmZmZmZmZmODY4MDAwMDANCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgyMTNl MWYwDQooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDggVkNQVXMNCihYRU4pIFN0ZC4gTG9nbGV2ZWw6 IEFsbA0KKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05T T0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUw0KKFhFTikgKioqKioqKiBUaGlzIG9wdGlvbiBpcyBp bnRlbmRlZCB0byBhaWQgZGVidWdnaW5nIG9mIFhlbiBieSBlbnN1cmluZw0KKFhFTikgKioqKioq KiB0aGF0IGFsbCBvdXRwdXQgaXMgc3luY2hyb25vdXNseSBkZWxpdmVyZWQgb24gdGhlIHNlcmlh bCBsaW5lLg0KKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNB TlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QNCihYRU4pICoqKioqKiogdGltZWtlZXBpbmcuIEl0IGlz IE5PVCByZWNvbW1lbmRlZCBmb3IgcHJvZHVjdGlvbiB1c2UhDQooWEVOKSAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVOKSAzLi4uIDIuLi4gMS4uLg0K KFhFTikgWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSAqKiogU2VyaWFs IGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0 IHRvIFhlbikNCihYRU4pIEZyZWVkIDI5NmtCIGluaXQgbWVtb3J5Lg0KbWFwcGluZyBrZXJuZWwg aW50byBwaHlzaWNhbCBtZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4uDQpJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQNCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0K SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdA0KTGludXggdmVyc2lvbiAzLjEwLjQ1 LXhlbi4zNDguNzAuNTAwMjkgKGJ1aWxkQG5pbW95KSAoZ2NjIHZlcnNpb24gNC40LjcgMjAxMjAz MTMgKFJlZCBIYXQgNC40LjctNCkgKEdDQykgKSAjMSBTTVAgUFJFRU1QVCBUdWUgSnVuIDMwIDA2 OjIxOjM4IFBEVCAyMDE1DQpDb21tYW5kIGxpbmU6IHJvIHJvb3Q9L2Rldi9tYXBwZXIvdmdfbWF0 ZC1sdl9yYSByZF9OT19MVUtTIHJkX0xWTV9MVj12Z19tYXRkL2x2X3JhIExBTkc9ZW5fVVMuVVRG LTggcmRfTFZNX0xWPXZnX21hdGQvbHZfc3dhcCByZF9OT19NRCBTWVNGT05UPWxhdGFyY3lyaGVi LXN1bjE2IEtFWUJPQVJEVFlQRT1wYyBLRVlUQUJMRT11cyByZF9OT19ETSBCT09UX09QVElPTj1k aXNrLUEgT1NfVFlQRT1YZW4gZWFybHlwcmludGs9eGVuIG5vbW9kZXNldCBjb25zb2xlPXR0eTEg Y29uc29sZT1odmMwDQpLRVJORUwgc3VwcG9ydGVkIGNwdXM6DQogIEludGVsIEdlbnVpbmVJbnRl bA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KRnJlZWluZyA5Zi0xMDAgcGZuIHJh bmdlOiA5NyBwYWdlcyBmcmVlZA0KRnJlZWluZyBiZmVlMC1iZmYwMCBwZm4gcmFuZ2U6IDMyIHBh Z2VzIGZyZWVkDQpGcmVlaW5nIGMwMDAwLTEwMDAwMCBwZm4gcmFuZ2U6IDI2MjE0NCBwYWdlcyBm cmVlZA0KUmVsZWFzZWQgMjYyMjczIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClNldCAyNjIyNzMg cGFnZShzKSB0byAxLTEgbWFwcGluZw0KUG9wdWxhdGluZyAyMjAwMDAtMjYwMDgxIHBmbiByYW5n ZTogMjYyMjczIHBhZ2VzIGFkZGVkDQplODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBt YXA6DQpYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNh YmxlDQpYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlmNDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVz ZXJ2ZWQNClhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMGJmZWRmZmZmXSB1 c2FibGUNClhlbjogW21lbSAweDAwMDAwMDAwYmZlZTAwMDAtMHgwMDAwMDAwMGJmZWZlZmZmXSBB Q1BJIGRhdGENClhlbjogW21lbSAweDAwMDAwMDAwYmZlZmYwMDAtMHgwMDAwMDAwMGJmZWZmZmZm XSBBQ1BJIE5WUw0KWGVuOiBbbWVtIDB4MDAwMDAwMDBiZmYwMDAwMC0weDAwMDAwMDAwYmZmZmZm ZmZdIHVzYWJsZQ0KWGVuOiBbbWVtIDB4MDAwMDAwMDBlMDAwMDAwMC0weDAwMDAwMDAwZWZmZmZm ZmZdIHJlc2VydmVkDQpYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMw ZmZmZl0gcmVzZXJ2ZWQNClhlbjogW21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZl ZWZmZmZmXSByZXNlcnZlZA0KWGVuOiBbbWVtIDB4MDAwMDAwMDBmZmZlMDAwMC0weDAwMDAwMDAw ZmZmZmZmZmZdIHJlc2VydmVkDQpYZW46IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAw MGMzZmZmZmZmZl0gdXNhYmxlDQpib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNCk5YIChF eGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KU01CSU9TIDIuNCBwcmVzZW50Lg0K ZTgyMDogbGFzdF9wZm4gPSAweGM0MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMA0KZTgy MDogbGFzdF9wZm4gPSAweGMwMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpTY2Fubmlu ZyAxIGFyZWFzIGZvciBsb3cgbWVtb3J5IGNvcnJ1cHRpb24NCmluaXRfbWVtb3J5X21hcHBpbmc6 IFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXQ0KaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAw eDI1ZmUwMDAwMC0weDI1ZmZmZmZmZl0NCmluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgyNWMw MDAwMDAtMHgyNWZkZmZmZmZdDQppbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MjAwMDAwMDAw LTB4MjViZmZmZmZmXQ0KaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4YmZl ZGZmZmZdDQppbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4YmZmMDAwMDAtMHhiZmZmZmZmZl0N CmluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgxMDAwMDAwMDAtMHgxZmZmZmZmZmZdDQppbml0 X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MjYwMDAwMDAwLTB4YzNmZmZmZmZmXQ0KUkFNRElTSzog W21lbSAweDAyN2YzMDAwLTB4MDUzZTFmZmZdDQpBQ1BJOiBSU0RQIDAwMDAwMDAwMDAwZjZiODAg MDAwMjQgKHYwMiBQVExURCApDQpBQ1BJOiBYU0RUIDAwMDAwMDAwYmZlZWU3ODAgMDAwNUMgKHYw MSBJTlRFTCAgNDQwQlggICAgMDYwNDAwMDAgVk1XICAwMTMyNDI3MikNCkFDUEk6IEZBQ1AgMDAw MDAwMDBiZmVmZWU5OCAwMDBGNCAodjA0IElOVEVMICA0NDBCWCAgICAwNjA0MDAwMCBQVEwgIDAw MEY0MjQwKQ0KQUNQSTogRFNEVCAwMDAwMDAwMGJmZWVlYzIyIDEwMjc2ICh2MDEgUFRMVEQgIEN1 c3RvbSAgIDA2MDQwMDAwIE1TRlQgMDMwMDAwMDEpDQpBQ1BJOiBGQUNTIDAwMDAwMDAwYmZlZmZm YzAgMDAwNDANCkFDUEk6IEJPT1QgMDAwMDAwMDBiZmVlZWJmYSAwMDAyOCAodjAxIFBUTFREICAk U0JGVEJMJCAwNjA0MDAwMCAgTFRQIDAwMDAwMDAxKQ0KQUNQSTogQVBJQyAwMDAwMDAwMGJmZWVl YWQ4IDAwMTIyICh2MDEgUFRMVEQgID8gQVBJQyAgIDA2MDQwMDAwICBMVFAgMDAwMDAwMDApDQpB Q1BJOiBNQ0ZHIDAwMDAwMDAwYmZlZWVhOWMgMDAwM0MgKHYwMSBQVExURCAgJFBDSVRCTCQgMDYw NDAwMDAgIExUUCAwMDAwMDAwMSkNCkFDUEk6IFNSQVQgMDAwMDAwMDBiZmVlZTg3YyAwMDIyMCAo djAyIFZNV0FSRSBNRU1QTFVHICAwNjA0MDAwMCBWTVcgIDAwMDAwMDAxKQ0KQUNQSTogSFBFVCAw MDAwMDAwMGJmZWVlODQ0IDAwMDM4ICh2MDEgVk1XQVJFIFZNVyBIUEVUIDA2MDQwMDAwIFZNVyAg MDAwMDAwMDEpDQpBQ1BJOiBXQUVUIDAwMDAwMDAwYmZlZWU4MWMgMDAwMjggKHYwMSBWTVdBUkUg Vk1XIFdBRVQgMDYwNDAwMDAgVk1XICAwMDAwMDAwMSkNClNldHRpbmcgQVBJQyByb3V0aW5nIHRv IHBoeXNpY2FsIGZsYXQuDQpab25lIHJhbmdlczoNCiAgRE1BICAgICAgW21lbSAweDAwMDAxMDAw LTB4MDBmZmZmZmZdDQogIERNQTMyICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KICBO b3JtYWwgICBbbWVtIDB4MTAwMDAwMDAwLTB4YzNmZmZmZmZmXQ0KTW92YWJsZSB6b25lIHN0YXJ0 IGZvciBlYWNoIG5vZGUNCkVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcw0KICBub2RlICAgMDogW21l bSAweDAwMDAxMDAwLTB4MDAwOWVmZmZdDQogIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHhi ZmVkZmZmZl0NCiAgbm9kZSAgIDA6IFttZW0gMHhiZmYwMDAwMC0weGJmZmZmZmZmXQ0KICBub2Rl ICAgMDogW21lbSAweDEwMDAwMDAwMC0weGMzZmZmZmZmZl0NCkFDUEk6IFBNLVRpbWVyIElPIFBv cnQ6IDB4MTAwOA0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5h YmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQp DQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCkFDUEk6IExB UElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwNl0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDddIGxhcGljX2lkWzB4MDddIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA4XSBs YXBpY19pZFsweDA4XSBlbmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNf aWRbMHgwOV0gZW5hYmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGFdIGxhcGljX2lkWzB4 MGFdIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsweDBiXSBl bmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwY10gbGFwaWNfaWRbMHgwY10gZW5hYmxl ZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGRdIGxhcGljX2lkWzB4MGRdIGVuYWJsZWQpDQpB Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19pZFsweDBlXSBlbmFibGVkKQ0KQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwZl0gbGFwaWNfaWRbMHgwZl0gZW5hYmxlZCkNCkFDUEk6IExBUElD X05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1J IChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFj cGlfaWRbMHgwMl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4 MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNV0g aGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdo IGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRn ZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwOF0gaGlnaCBlZGdlIGxp bnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA5XSBoaWdoIGVkZ2UgbGludFsw eDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGFdIGhpZ2ggZWRnZSBsaW50WzB4MV0p DQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFD UEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBjXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTog TEFQSUNfTk1JIChhY3BpX2lkWzB4MGRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwZV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05N SSAoYWNwaV9pZFsweDBmXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogSU9BUElDIChpZFsw eDEwXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KSU9BUElDWzBdOiBhcGljX2lk IDE2LCB2ZXJzaW9uIDE3LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpBQ1BJOiBJTlRf U1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBoaWdoIGVkZ2UpDQpVc2luZyBB Q1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCkFDUEk6IEhQRVQg aWQ6IDB4ODA4NmFmMDEgYmFzZTogMHhmZWQwMDAwMA0Kc21wYm9vdDogQWxsb3dpbmcgMTYgQ1BV cywgMCBob3RwbHVnIENQVXMNClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw MDAwOWYwMDAgLSAwMDAwMDAwMDAwMGEwMDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5 OiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9z YXZlIG1lbW9yeTogMDAwMDAwMDBiZmVlMDAwMCAtIDAwMDAwMDAwYmZlZmYwMDANClBNOiBSZWdp c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmZlZmYwMDAgLSAwMDAwMDAwMGJmZjAwMDAw DQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGMwMDAwMDAwIC0gMDAwMDAw MDBlMDAwMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBlMDAwMDAw MCAtIDAwMDAwMDAwZjAwMDAwMDANClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwZjAwMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVt b3J5OiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMxMDAwMA0KUE06IFJlZ2lzdGVyZWQg bm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZWMxMDAwMCAtIDAwMDAwMDAwZmVlMDAwMDANClBNOiBS ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAw MDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZjAwMDAwIC0gMDAw MDAwMDBmZmZlMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZmZl MDAwMCAtIDAwMDAwMDAxMDAwMDAwMDANCmU4MjA6IFttZW0gMHhjMDAwMDAwMC0weGRmZmZmZmZm XSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzDQpCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu ZWwgb24gWGVuDQpYZW4gdmVyc2lvbjogNC40LjAgKHByZXNlcnZlLUFEKQ0Kc2V0dXBfcGVyY3B1 OiBOUl9DUFVTOjQwOTYgbnJfY3B1bWFza19iaXRzOjE2IG5yX2NwdV9pZHM6MTYgbnJfbm9kZV9p ZHM6MQ0KUEVSQ1BVOiBFbWJlZGRlZCAzMCBwYWdlcy9jcHUgQGZmZmY4ODAyNTljMDAwMDAgczkw MzY4IHI4MTkyIGQyNDMyMCB1MTMxMDcyDQpCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVy LCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAxMjQxMDcyOA0KS2VybmVsIGNv bW1hbmQgbGluZTogcm8gcm9vdD0vZGV2L21hcHBlci92Z19tYXRkLWx2X3JhIHJkX05PX0xVS1Mg cmRfTFZNX0xWPXZnX21hdGQvbHZfcmEgTEFORz1lbl9VUy5VVEYtOCByZF9MVk1fTFY9dmdfbWF0 ZC9sdl9zd2FwIHJkX05PX01EIFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgS0VZQk9BUkRUWVBF PXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNIEJPT1RfT1BUSU9OPWRpc2stQSBPU19UWVBFPVhlbiBl YXJseXByaW50az14ZW4gbm9tb2Rlc2V0IGNvbnNvbGU9dHR5MSBjb25zb2xlPWh2YzANClBJRCBo YXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykNCkRlbnRyeSBj YWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgzODg2MDggKG9yZGVyOiAxNCwgNjcxMDg4NjQgYnl0 ZXMpDQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDQxOTQzMDQgKG9yZGVyOiAxMywg MzM1NTQ0MzIgYnl0ZXMpDQpzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDIyMzczNzAwMC0weDIyNzcz NzAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDIyMzczNzAwMC1mZmZmODgwMjI3NzM2ZmZm XQ0KTWVtb3J5OiA3ODc1NDUyay81MTM4MDIyNGsgYXZhaWxhYmxlICg1MjU4ayBrZXJuZWwgY29k ZSwgMTA0OTA5NmsgYWJzZW50LCA0MjQ1NTY3NmsgcmVzZXJ2ZWQsIDEyMzAxayBkYXRhLCAxMjI0 ayBpbml0KQ0KUHJlZW1wdGlibGUgaGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NCiAg ICAgICAgUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTQwOTYgdG8gbnJfY3B1X2lk cz04Lg0KTlJfSVJRUzoyNjI0MDAgbnJfaXJxczo3NDQgMTYNCnhlbjogc2NpIG92ZXJyaWRlOiBn bG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENCnhlbjogYWNwaSBzY2kgOQ0KQ29uc29s ZTogY29sb3VyIFZHQSsgODB4MjUNCmNvbnNvbGUgW3R0eTFdIGVuYWJsZWQNCmNvbnNvbGUgW2h2 YzBdIGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2FibGVkDQpjb25zb2xlIFtodmMwXSBlbmFibGVk LCBib290Y29uc29sZSBkaXNhYmxlZA0KaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAwDQp0 c2M6IERldGVjdGVkIDI2NjUuNDc4IE1IeiBwcm9jZXNzb3INCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDUz MzAuOTUgQm9nb01JUFMgKGxwaj0yNjY1NDc4KQ0KcGlkX21heDogZGVmYXVsdDogMzI3NjggbWlu aW11bTogMzAxDQpTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClNFTGludXg6ICBJbml0 aWFsaXppbmcuDQpNb3VudC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1Ng0KSW5pdGlhbGl6 aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcw0KSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcg0KSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbmV0X2Nscw0KSW5pdGlhbGl6aW5nIGNn cm91cCBzdWJzeXMgYmxraW8NCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIHBlcmZfZXZlbnQN CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIG5ldF9wcmlvDQpEaXNhYmxlZCBmYXN0IHN0cmlu ZyBvcGVyYXRpb25zDQpFTkVSR1lfUEVSRl9CSUFTOiBTZXQgdG8gJ25vcm1hbCcsIHdhcyAncGVy Zm9ybWFuY2UnDQpFTkVSR1lfUEVSRl9CSUFTOiBWaWV3IGFuZCB1cGRhdGUgd2l0aCB4ODZfZW5l cmd5X3BlcmZfcG9saWN5KDgpDQpDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMA0KQ1BVOiBQ cm9jZXNzb3IgQ29yZSBJRDogMA0KbWNlOiBDUFUgc3VwcG9ydHMgMiBNQ0UgYmFua3MNCihYRU4p IGRvbWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwMDI2MjAgLT4g MDAwMDI2NjANCkxhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgNywgNE1CIDcN Ckxhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMzIsIDRNQiAzMg0KdGxiX2Zs dXNoYWxsX3NoaWZ0OiA2DQpGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXM6IDIwayBmcmVlZA0KQUNQ STogQ29yZSByZXZpc2lvbiAyMDEzMDMyOA0KQUNQSTogQWxsIEFDUEkgVGFibGVzIHN1Y2Nlc3Nm dWxseSBhY3F1aXJlZA0KZnRyYWNlOiBhbGxvY2F0aW5nIDIyNzg1IGVudHJpZXMgaW4gOTAgcGFn ZXMNCmNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSA0MQ0KUGVyZm9ybWFuY2UgRXZlbnRzOiB1bnN1 cHBvcnRlZCBwNiBDUFUgbW9kZWwgNDQgbm8gUE1VIGRyaXZlciwgc29mdHdhcmUgZXZlbnRzIG9u bHkuDQpOTUkgd2F0Y2hkb2c6IGRpc2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBl bmFibGVkDQppbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENCmNwdSAxIHNwaW5sb2NrIGV2 ZW50IGlycSA0OA0KKFhFTikgZG9tYWluLmM6NjMyOmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBm bGFncyAwMDAwMjYyMCAtPiAwMDAwMjY2MA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9u cw0KaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAyDQpjcHUgMiBzcGlubG9jayBldmVudCBp cnEgNTUNCihYRU4pIGRvbWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3Mg MDAwMDI2MjAgLT4gMDAwMDI2NjANCkRpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMNCmlu c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMw0KY3B1IDMgc3BpbmxvY2sgZXZlbnQgaXJxIDYy DQooWEVOKSBkb21haW4uYzo2MzI6ZDAgQXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDAy NjIwIC0+IDAwMDAyNjYwDQpEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zDQppbnN0YWxs aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDQNCmNwdSA0IHNwaW5sb2NrIGV2ZW50IGlycSA2OQ0KKFhF TikgZG9tYWluLmM6NjMyOmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDAwMjYyMCAt PiAwMDAwMjY2MA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KaW5zdGFsbGluZyBY ZW4gdGltZXIgZm9yIENQVSA1DQpjcHUgNSBzcGlubG9jayBldmVudCBpcnEgNzYNCihYRU4pIGRv bWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwMDI2MjAgLT4gMDAw MDI2NjANCkRpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMNCmluc3RhbGxpbmcgWGVuIHRp bWVyIGZvciBDUFUgNg0KY3B1IDYgc3BpbmxvY2sgZXZlbnQgaXJxIDgzDQooWEVOKSBkb21haW4u Yzo2MzI6ZDAgQXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDAyNjIwIC0+IDAwMDAyNjYw DQpEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zDQppbnN0YWxsaW5nIFhlbiB0aW1lciBm b3IgQ1BVIDcNCmNwdSA3IHNwaW5sb2NrIGV2ZW50IGlycSA5MA0KKFhFTikgZG9tYWluLmM6NjMy OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDAwMjYyMCAtPiAwMDAwMjY2MA0KRGlz YWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KQnJvdWdodCB1cCA4IENQVXMNCg== --001a113e8e6a6cb0960519d97e41 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --001a113e8e6a6cb0960519d97e41-- From xen-users-bounces@lists.xen.org Thu Jul 02 00:27:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 00:27:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZASL1-0002lt-K9; Thu, 02 Jul 2015 00:26:47 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZASKz-0002lV-S7 for xen-users@lists.xen.org; Thu, 02 Jul 2015 00:26:46 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 13/47-00727-54584955; Thu, 02 Jul 2015 00:26:45 +0000 X-Env-Sender: josh.drenan@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1435796803!21800367!1 X-Originating-IP: [209.85.223.175] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_10_20,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2577 invoked from network); 2 Jul 2015 00:26:44 -0000 Received: from mail-ie0-f175.google.com (HELO mail-ie0-f175.google.com) (209.85.223.175) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 00:26:44 -0000 Received: by iebmu5 with SMTP id mu5so45976207ieb.1 for ; Wed, 01 Jul 2015 17:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=EjPAoXhPtiAwfu4A9dWE/ienbADoMHNyv+s5K2m/tTg=; b=zv1ZPOruPEuq//g7G9llndrRgRwx3gn01ov18bMVW78jrLXJrvdQMmpBO7sxKkwMlZ vKYSgy4s35sfl1DqxjrNEXsmfaKSXSNcZlPF0qVCaNaqoxrLWypAcuv105AxWOL5Jlqx LYA7cGyHKeh5ZvuMxue0HttBAdfzX8gbFiTczcXa5oCzUa/g+MCNR9xOvA3GSf6x69C2 gi074iWM7rK9/lGCAkqNxTSgkfgzVLqvjkAccP1VZvMRmtcKjUSSnTHFppkrL2lOgudA IdqecbDFoOAUx1ivL9MmnqcvBxIa70aY4iUkK093ihRNc7ejf6Fcez/bm8H5SWFS+WTw Dqmw== X-Received: by 10.107.138.201 with SMTP id c70mr42993394ioj.24.1435796803128; Wed, 01 Jul 2015 17:26:43 -0700 (PDT) MIME-Version: 1.0 From: Josh Drenan Date: Thu, 02 Jul 2015 00:26:32 +0000 Message-ID: To: "xen-users@lists.xen.org" Content-Type: multipart/mixed; boundary=001a113e8e6a6cb0960519d97e41 Subject: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --001a113e8e6a6cb0960519d97e41 Content-Type: multipart/alternative; boundary=001a113e8e6a6cb0900519d97e3f --001a113e8e6a6cb0900519d97e3f Content-Type: text/plain; charset=UTF-8 Greetings all I have an error where dom0 freezes during boot and was wondering if anyone could help. I have tried using most of the acpi command line options to no avail. I am trying to boot xen as a virtual machine inside of ESXI, it works if the total number of cores is less than or equal to 8 but no more for some reason. I have included the log from the boot. --001a113e8e6a6cb0900519d97e3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Greetings all I have an error where dom0 =C2=A0freezes dur= ing boot and was wondering if anyone could help. I have tried using most of= the acpi command line options to no avail.

I am trying = to boot xen as a virtual machine inside of ESXI, it works if the total numb= er of cores is less than or equal to 8 but no more for some reason.

I have included the log from the boot.
--001a113e8e6a6cb0900519d97e3f-- --001a113e8e6a6cb0960519d97e41 Content-Type: application/octet-stream; name="Xen_console2.log" Content-Disposition: attachment; filename="Xen_console2.log" Content-Transfer-Encoding: base64 X-Attachment-Id: 14e4c2786e2b3be390f1 IFhlbiA0LjQuMA0KKFhFTikgWGVuIHZlcnNpb24gNC40LjAgKGJ1aWxkQCkgKGdjYyAoR0NDKSA0 LjQuNyAyMDEyMDMxMyAoUmVkIEhhdCA0LjQuNy00KSkgZGVidWc9biBUdWUgSnVuIDMwIDA2OjEy OjI4IFBEVCAyMDE1DQooWEVOKSBMYXRlc3QgQ2hhbmdlU2V0Og0KKFhFTikgQ29uc29sZSBvdXRw dXQgaXMgc3luY2hyb25vdXMuDQooWEVOKSBCb290bG9hZGVyOiBHTlUgR1JVQiAwLjk3DQooWEVO KSBDb21tYW5kIGxpbmU6IGxvZ2x2bD1hbGwgZ3Vlc3RfbG9nbHZsPWFsbCBkb20wX21lbT04NzA0 TSBib290c2NydWI9ZmFsc2UgZG9tMF9tYXhfdmNwdXM9OCBkb20wX3ZjcHVzX3Bpbj10cnVlIG5t aT1kb20wIHdhdGNoZG9nPXRydWUgY29tMT0xMTUyMDAgY29uc29sZT1jb20xLHZnYSBzeW5jX2Nv bnNvbGU9dHJ1ZQ0KKFhFTikgVmlkZW8gaW5mb3JtYXRpb246DQooWEVOKSAgVkdBIGlzIHRleHQg bW9kZSA4MHgyNSwgZm9udCA4eDE2DQooWEVOKSBEaXNjIGluZm9ybWF0aW9uOg0KKFhFTikgIEZv dW5kIDEgTUJSIHNpZ25hdHVyZXMNCihYRU4pICBGb3VuZCAxIEVERCBpbmZvcm1hdGlvbiBzdHJ1 Y3R1cmVzDQooWEVOKSBYZW4tZTgyMCBSQU0gbWFwOg0KKFhFTikgIDAwMDAwMDAwMDAwMDAwMDAg LSAwMDAwMDAwMDAwMDlmNDAwICh1c2FibGUpDQooWEVOKSAgMDAwMDAwMDAwMDA5ZjQwMCAtIDAw MDAwMDAwMDAwYTAwMDAgKHJlc2VydmVkKQ0KKFhFTikgIDAwMDAwMDAwMDAwY2EwMDAgLSAwMDAw MDAwMDAwMGNjMDAwIChyZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMDAwMGRjMDAwIC0gMDAwMDAw MDAwMDEwMDAwMCAocmVzZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDAwMDEwMDAwMCAtIDAwMDAwMDAw YmZlZTAwMDAgKHVzYWJsZSkNCihYRU4pICAwMDAwMDAwMGJmZWUwMDAwIC0gMDAwMDAwMDBiZmVm ZjAwMCAoQUNQSSBkYXRhKQ0KKFhFTikgIDAwMDAwMDAwYmZlZmYwMDAgLSAwMDAwMDAwMGJmZjAw MDAwIChBQ1BJIE5WUykNCihYRU4pICAwMDAwMDAwMGJmZjAwMDAwIC0gMDAwMDAwMDBjMDAwMDAw MCAodXNhYmxlKQ0KKFhFTikgIDAwMDAwMDAwZTAwMDAwMDAgLSAwMDAwMDAwMGYwMDAwMDAwIChy ZXNlcnZlZCkNCihYRU4pICAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMxMDAwMCAocmVz ZXJ2ZWQpDQooWEVOKSAgMDAwMDAwMDBmZWUwMDAwMCAtIDAwMDAwMDAwZmVlMDEwMDAgKHJlc2Vy dmVkKQ0KKFhFTikgIDAwMDAwMDAwZmZmZTAwMDAgLSAwMDAwMDAwMTAwMDAwMDAwIChyZXNlcnZl ZCkNCihYRU4pICAwMDAwMDAwMTAwMDAwMDAwIC0gMDAwMDAwMGM0MDAwMDAwMCAodXNhYmxlKQ0K KFhFTikgQUNQSTogUlNEUCAwMDBGNkI4MCwgMDAyNCAocjIgUFRMVEQgKQ0KKFhFTikgQUNQSTog WFNEVCBCRkVFRTc4MCwgMDA1QyAocjEgSU5URUwgIDQ0MEJYICAgICA2MDQwMDAwIFZNVyAgIDEz MjQyNzIpDQooWEVOKSBBQ1BJOiBGQUNQIEJGRUZFRTk4LCAwMEY0IChyNCBJTlRFTCAgNDQwQlgg ICAgIDYwNDAwMDAgUFRMICAgICBGNDI0MCkNCihYRU4pIEFDUEk6IERTRFQgQkZFRUVDMjIsIDEw Mjc2IChyMSBQVExURCAgQ3VzdG9tICAgIDYwNDAwMDAgTVNGVCAgMzAwMDAwMSkNCihYRU4pIEFD UEk6IEZBQ1MgQkZFRkZGQzAsIDAwNDANCihYRU4pIEFDUEk6IEJPT1QgQkZFRUVCRkEsIDAwMjgg KHIxIFBUTFREICAkU0JGVEJMJCAgNjA0MDAwMCAgTFRQICAgICAgICAxKQ0KKFhFTikgQUNQSTog QVBJQyBCRkVFRUFEOCwgMDEyMiAocjEgUFRMVEQgICAgICAgIEFQSUMgICAgNjA0MDAwMCAgTFRQ ICAgICAgICAwKQ0KKFhFTikgQUNQSTogTUNGRyBCRkVFRUE5QywgMDAzQyAocjEgUFRMVEQgICRQ Q0lUQkwkICA2MDQwMDAwICBMVFAgICAgICAgIDEpDQooWEVOKSBBQ1BJOiBTUkFUIEJGRUVFODdD LCAwMjIwIChyMiBWTVdBUkUgTUVNUExVRyAgIDYwNDAwMDAgVk1XICAgICAgICAgMSkNCihYRU4p IEFDUEk6IEhQRVQgQkZFRUU4NDQsIDAwMzggKHIxIFZNV0FSRSBWTVcgSFBFVCAgNjA0MDAwMCBW TVcgICAgICAgICAxKQ0KKFhFTikgQUNQSTogV0FFVCBCRkVFRTgxQywgMDAyOCAocjEgVk1XQVJF IFZNVyBXQUVUICA2MDQwMDAwIFZNVyAgICAgICAgIDEpDQooWEVOKSBTeXN0ZW0gUkFNOiA0OTE1 MU1CICg1MDMzMTEzMmtCKQ0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAwIC0+IE5vZGUgMA0K KFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAxIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAg LT4gQVBJQyAyIC0+IE5vZGUgMA0KKFhFTikgU1JBVDogUFhNIDAgLT4gQVBJQyAzIC0+IE5vZGUg MA0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA0IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDogUFhN IDEgLT4gQVBJQyA1IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA2IC0+IE5v ZGUgMQ0KKFhFTikgU1JBVDogUFhNIDEgLT4gQVBJQyA3IC0+IE5vZGUgMQ0KKFhFTikgU1JBVDog UFhNIDIgLT4gQVBJQyA4IC0+IE5vZGUgMg0KKFhFTikgU1JBVDogUFhNIDIgLT4gQVBJQyA5IC0+ IE5vZGUgMg0KKFhFTikgU1JBVDogUFhNIDIgLT4gQVBJQyAxMCAtPiBOb2RlIDINCihYRU4pIFNS QVQ6IFBYTSAyIC0+IEFQSUMgMTEgLT4gTm9kZSAyDQooWEVOKSBTUkFUOiBQWE0gMyAtPiBBUElD IDEyIC0+IE5vZGUgMw0KKFhFTikgU1JBVDogUFhNIDMgLT4gQVBJQyAxMyAtPiBOb2RlIDMNCihY RU4pIFNSQVQ6IFBYTSAzIC0+IEFQSUMgMTQgLT4gTm9kZSAzDQooWEVOKSBTUkFUOiBQWE0gMyAt PiBBUElDIDE1IC0+IE5vZGUgMw0KKFhFTikgU1JBVDogTm9kZSAwIFBYTSAwIDAtYTAwMDANCihY RU4pIFNSQVQ6IE5vZGUgMCBQWE0gMCAxMDAwMDAtYzAwMDAwMDANCihYRU4pIFNSQVQ6IE5vZGUg MCBQWE0gMCAxMDAwMDAwMDAtMzQwMDAwMDAwDQooWEVOKSBTUkFUOiBOb2RlIDEgUFhNIDEgMzQw MDAwMDAwLTY0MDAwMDAwMA0KKFhFTikgU1JBVDogTm9kZSAyIFBYTSAyIDY0MDAwMDAwMC05NDAw MDAwMDANCihYRU4pIFNSQVQ6IE5vZGUgMyBQWE0gMyA5NDAwMDAwMDAtYzQwMDAwMDAwDQooWEVO KSBOVU1BOiBBbGxvY2F0ZWQgbWVtbm9kZW1hcCBmcm9tIGMzYjViMTAwMCAtIGMzYjViZTAwMA0K KFhFTikgTlVNQTogVXNpbmcgOCBmb3IgdGhlIGhhc2ggc2hpZnQuDQooWEVOKSBEb21haW4gaGVh cCBpbml0aWFsaXNlZCBETUEgd2lkdGggMzEgYml0cw0KKFhFTikgZm91bmQgU01QIE1QLXRhYmxl IGF0IDAwMGY2YmYwDQooWEVOKSBETUkgcHJlc2VudC4NCihYRU4pIFVzaW5nIEFQSUMgZHJpdmVy IGJpZ3NtcA0KKFhFTikgQUNQSTogUE0tVGltZXIgSU8gUG9ydDogMHgxMDA4DQooWEVOKSBBQ1BJ OiBTTEVFUCBJTkZPOiBwbTF4X2NudFsxMDA0LDBdLCBwbTF4X2V2dFsxMDAwLDBdDQooWEVOKSBB Q1BJOiAgICAgICAgICAgICB3YWtldXBfdmVjW2JmZWZmZmNjXSwgdmVjX3NpemVbMjBdDQooWEVO KSBBQ1BJOiBMb2NhbCBBUElDIGFkZHJlc3MgMHhmZWUwMDAwMA0KKFhFTikgQUNQSTogTEFQSUMg KGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAj MCA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMV0g bGFwaWNfaWRbMHgwMV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMSA2OjEyIEFQSUMgdmVy c2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMl0gbGFwaWNfaWRbMHgwMl0g ZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMiA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikg QUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCihYRU4p IFByb2Nlc3NvciAjMyA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFj cGlfaWRbMHgwNF0gbGFwaWNfaWRbMHgwNF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNCA2 OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNV0gbGFw aWNfaWRbMHgwNV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNSA2OjEyIEFQSUMgdmVyc2lv biAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwNl0gbGFwaWNfaWRbMHgwNl0gZW5h YmxlZCkNCihYRU4pIFByb2Nlc3NvciAjNiA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwN10gbGFwaWNfaWRbMHgwN10gZW5hYmxlZCkNCihYRU4pIFBy b2Nlc3NvciAjNyA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwOF0gbGFwaWNfaWRbMHgwOF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjOCA2OjEy IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNf aWRbMHgwOV0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjOSA2OjEyIEFQSUMgdmVyc2lvbiAy MQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwYV0gbGFwaWNfaWRbMHgwYV0gZW5hYmxl ZCkNCihYRU4pIFByb2Nlc3NvciAjMTAgNjoxMiBBUElDIHZlcnNpb24gMjENCihYRU4pIEFDUEk6 IExBUElDIChhY3BpX2lkWzB4MGJdIGxhcGljX2lkWzB4MGJdIGVuYWJsZWQpDQooWEVOKSBQcm9j ZXNzb3IgIzExIDY6MTIgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJOiBMQVBJQyAoYWNwaV9p ZFsweDBjXSBsYXBpY19pZFsweDBjXSBlbmFibGVkKQ0KKFhFTikgUHJvY2Vzc29yICMxMiA2OjEy IEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwZF0gbGFwaWNf aWRbMHgwZF0gZW5hYmxlZCkNCihYRU4pIFByb2Nlc3NvciAjMTMgNjoxMiBBUElDIHZlcnNpb24g MjENCihYRU4pIEFDUEk6IExBUElDIChhY3BpX2lkWzB4MGVdIGxhcGljX2lkWzB4MGVdIGVuYWJs ZWQpDQooWEVOKSBQcm9jZXNzb3IgIzE0IDY6MTIgQVBJQyB2ZXJzaW9uIDIxDQooWEVOKSBBQ1BJ OiBMQVBJQyAoYWNwaV9pZFsweDBmXSBsYXBpY19pZFsweDBmXSBlbmFibGVkKQ0KKFhFTikgUHJv Y2Vzc29yICMxNSA2OjEyIEFQSUMgdmVyc2lvbiAyMQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChh Y3BpX2lkWzB4MDBdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkg KGFjcGlfaWRbMHgwMV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExBUElDX05N SSAoYWNwaV9pZFsweDAyXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTogTEFQSUNf Tk1JIChhY3BpX2lkWzB4MDNdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwNF0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFDUEk6IExB UElDX05NSSAoYWNwaV9pZFsweDA1XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikgQUNQSTog TEFQSUNfTk1JIChhY3BpX2lkWzB4MDZdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVOKSBBQ1BJ OiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwN10gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihYRU4pIEFD UEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA4XSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KKFhFTikg QUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDldIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQooWEVO KSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCihY RU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBiXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0K KFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGNdIGhpZ2ggZWRnZSBsaW50WzB4MV0p DQooWEVOKSBBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwZF0gaGlnaCBlZGdlIGxpbnRbMHgx XSkNCihYRU4pIEFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBlXSBoaWdoIGVkZ2UgbGludFsw eDFdKQ0KKFhFTikgQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGZdIGhpZ2ggZWRnZSBsaW50 WzB4MV0pDQooWEVOKSBBQ1BJOiBJT0FQSUMgKGlkWzB4MTBdIGFkZHJlc3NbMHhmZWMwMDAwMF0g Z3NpX2Jhc2VbMF0pDQooWEVOKSBJT0FQSUNbMF06IGFwaWNfaWQgMTYsIHZlcnNpb24gMTcsIGFk ZHJlc3MgMHhmZWMwMDAwMCwgR1NJIDAtMjMNCihYRU4pIEFDUEk6IElOVF9TUkNfT1ZSIChidXMg MCBidXNfaXJxIDAgZ2xvYmFsX2lycSAyIGhpZ2ggZWRnZSkNCihYRU4pIEFDUEk6IElSUTAgdXNl ZCBieSBvdmVycmlkZS4NCihYRU4pIEFDUEk6IElSUTIgdXNlZCBieSBvdmVycmlkZS4NCihYRU4p IEVuYWJsaW5nIEFQSUMgbW9kZTogIFBoeXMuICBVc2luZyAxIEkvTyBBUElDcw0KKFhFTikgQUNQ STogSFBFVCBpZDogMHg4MDg2YWYwMSBiYXNlOiAweGZlZDAwMDAwDQooWEVOKSBFUlNUIHRhYmxl IHdhcyBub3QgZm91bmQNCihYRU4pIFVzaW5nIEFDUEkgKE1BRFQpIGZvciBTTVAgY29uZmlndXJh dGlvbiBpbmZvcm1hdGlvbg0KKFhFTikgU01QOiBBbGxvd2luZyAxNiBDUFVzICgwIGhvdHBsdWcg Q1BVcykNCihYRU4pIElSUSBsaW1pdHM6IDI0IEdTSSwgMzA2NCBNU0kvTVNJLVgNCihYRU4pIE5v dCBlbmFibGluZyB4MkFQSUM6IGRlcGVuZHMgb24gaW9tbXVfc3VwcG9ydHNfZWltLg0KKFhFTikg VXNpbmcgc2NoZWR1bGVyOiBTTVAgQ3JlZGl0IFNjaGVkdWxlciAoY3JlZGl0KQ0KKFhFTikgRGV0 ZWN0ZWQgMjY2NS40NzggTUh6IHByb2Nlc3Nvci4NCihYRU4pIEluaXRpbmcgbWVtb3J5IHNoYXJp bmcuDQooWEVOKSBDUFUwOiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBw b3J0IGRpc2FibGVkDQooWEVOKSBQQ0k6IE1DRkcgY29uZmlndXJhdGlvbiAwOiBiYXNlIGUwMDAw MDAwIHNlZ21lbnQgMDAwMCBidXNlcyAwMCAtIGZmDQooWEVOKSBQQ0k6IE1DRkcgYXJlYSBhdCBl MDAwMDAwMCByZXNlcnZlZCBpbiBFODIwDQooWEVOKSBQQ0k6IFVzaW5nIE1DRkcgZm9yIHNlZ21l bnQgMDAwMCBidXMgMDAtZmYNCihYRU4pIEkvTyB2aXJ0dWFsaXNhdGlvbiBkaXNhYmxlZA0KKFhF TikgRU5BQkxJTkcgSU8tQVBJQyBJUlFzDQooWEVOKSAgLT4gVXNpbmcgbmV3IEFDSyBtZXRob2QN CihYRU4pIC4uVElNRVI6IHZlY3Rvcj0weEYwIGFwaWMxPTAgcGluMT0yIGFwaWMyPS0xIHBpbjI9 LTENCihYRU4pIFBsYXRmb3JtIHRpbWVyIGlzIDE0LjMxOE1IeiBIUEVUDQooWEVOKSBBbGxvY2F0 ZWQgY29uc29sZSByaW5nIG9mIDEyOCBLaUIuDQooWEVOKSBWTVg6IFN1cHBvcnRlZCBhZHZhbmNl ZCBmZWF0dXJlczoNCihYRU4pICAtIEFQSUMgVFBSIHNoYWRvdw0KKFhFTikgIC0gRXh0ZW5kZWQg UGFnZSBUYWJsZXMgKEVQVCkNCihYRU4pICAtIFZpcnR1YWwtUHJvY2Vzc29yIElkZW50aWZpZXJz IChWUElEKQ0KKFhFTikgIC0gVmlydHVhbCBOTUkNCihYRU4pICAtIE1TUiBkaXJlY3QtYWNjZXNz IGJpdG1hcA0KKFhFTikgIC0gVW5yZXN0cmljdGVkIEd1ZXN0DQooWEVOKSBIVk06IEFTSURzIGVu YWJsZWQuDQooWEVOKSBIVk06IFZNWCBlbmFibGVkDQooWEVOKSBIVk06IEhhcmR3YXJlIEFzc2lz dGVkIFBhZ2luZyAoSEFQKSBub3QgZGV0ZWN0ZWQNCihYRU4pIEhWTTogUFZIIG1vZGUgbm90IHN1 cHBvcnRlZCBvbiB0aGlzIHBsYXRmb3JtDQooWEVOKSBDUFUxOiBObyBNQ0UgYmFua3MgcHJlc2Vu dC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUyOiBObyBNQ0UgYmFu a3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUzOiBO byBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVO KSBDUFU0OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2Fi bGVkDQooWEVOKSBDUFU1OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBw b3J0IGRpc2FibGVkDQooWEVOKSBDUFU2OiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBj aGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU3OiBObyBNQ0UgYmFua3MgcHJlc2VudC4g TWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU4OiBObyBNQ0UgYmFua3Mg cHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFU5OiBObyBN Q0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBD UFUxMDogTm8gTUNFIGJhbmtzIHByZXNlbnQuIE1hY2hpbmUgY2hlY2sgc3VwcG9ydCBkaXNhYmxl ZA0KKFhFTikgQ1BVMTE6IE5vIE1DRSBiYW5rcyBwcmVzZW50LiBNYWNoaW5lIGNoZWNrIHN1cHBv cnQgZGlzYWJsZWQNCihYRU4pIENQVTEyOiBObyBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBj aGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVOKSBDUFUxMzogTm8gTUNFIGJhbmtzIHByZXNlbnQu IE1hY2hpbmUgY2hlY2sgc3VwcG9ydCBkaXNhYmxlZA0KKFhFTikgQ1BVMTQ6IE5vIE1DRSBiYW5r cyBwcmVzZW50LiBNYWNoaW5lIGNoZWNrIHN1cHBvcnQgZGlzYWJsZWQNCihYRU4pIENQVTE1OiBO byBNQ0UgYmFua3MgcHJlc2VudC4gTWFjaGluZSBjaGVjayBzdXBwb3J0IGRpc2FibGVkDQooWEVO KSBCcm91Z2h0IHVwIDE2IENQVXMNCihYRU4pIFRlc3RpbmcgTk1JIHdhdGNoZG9nIC0tLSBDUFUj MCBva2F5LiBDUFUjMSBva2F5LiBDUFUjMiBva2F5LiBDUFUjMyBva2F5LiBDUFUjNCBva2F5LiBD UFUjNSBva2F5LiBDUFUjNiBva2F5LiBDUFUjNyBva2F5LiBDUFUjOCBva2F5LiBDUFUjOSBva2F5 LiBDUFUjMTAgb2theS4gQ1BVIzExIG9rYXkuIENQVSMxMiBva2F5LiBDUFUjMTMgb2theS4gQ1BV IzE0IG9rYXkuIENQVSMxNSBva2F5Lg0KKFhFTikgQUNQSSBzbGVlcCBtb2RlczogUzMNCihYRU4p ICoqKiBMT0FESU5HIERPTUFJTiAwICoqKg0KKFhFTikgIFhlbiAga2VybmVsOiA2NC1iaXQsIGxz YiwgY29tcGF0MzINCihYRU4pICBEb20wIGtlcm5lbDogNjQtYml0LCBQQUUsIGxzYiwgcGFkZHIg MHgxMDAwMDAwIC0+IDB4MjdmMzAwMA0KKFhFTikgUEhZU0lDQUwgTUVNT1JZIEFSUkFOR0VNRU5U Og0KKFhFTikgIERvbTAgYWxsb2MuOiAgIDAwMDAwMDAyMzgwMDAwMDAtPjAwMDAwMDAyM2MwMDAw MDAgKDIyMDA1OTMgcGFnZXMgdG8gYmUgYWxsb2NhdGVkKQ0KKFhFTikgIEluaXQuIHJhbWRpc2s6 IDAwMDAwMDBjM2Q0MTEwMDAtPjAwMDAwMDBjM2ZmZmZjMDANCihYRU4pIFZJUlRVQUwgTUVNT1JZ IEFSUkFOR0VNRU5UOg0KKFhFTikgIExvYWRlZCBrZXJuZWw6IGZmZmZmZmZmODEwMDAwMDAtPmZm ZmZmZmZmODI3ZjMwMDANCihYRU4pICBJbml0LiByYW1kaXNrOiBmZmZmZmZmZjgyN2YzMDAwLT5m ZmZmZmZmZjg1M2UxYzAwDQooWEVOKSAgUGh5cy1NYWNoIG1hcDogZmZmZmZmZmY4NTNlMjAwMC0+ ZmZmZmZmZmY4NjRlMjAwMA0KKFhFTikgIFN0YXJ0IGluZm86ICAgIGZmZmZmZmZmODY0ZTIwMDAt PmZmZmZmZmZmODY0ZTI0YjQNCihYRU4pICBQYWdlIHRhYmxlczogICBmZmZmZmZmZjg2NGUzMDAw LT5mZmZmZmZmZjg2NTFhMDAwDQooWEVOKSAgQm9vdCBzdGFjazogICAgZmZmZmZmZmY4NjUxYTAw MC0+ZmZmZmZmZmY4NjUxYjAwMA0KKFhFTikgIFRPVEFMOiAgICAgICAgIGZmZmZmZmZmODAwMDAw MDAtPmZmZmZmZmZmODY4MDAwMDANCihYRU4pICBFTlRSWSBBRERSRVNTOiBmZmZmZmZmZjgyMTNl MWYwDQooWEVOKSBEb20wIGhhcyBtYXhpbXVtIDggVkNQVXMNCihYRU4pIFN0ZC4gTG9nbGV2ZWw6 IEFsbA0KKFhFTikgR3Vlc3QgTG9nbGV2ZWw6IEFsbA0KKFhFTikgKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKg0KKFhFTikgKioqKioqKiBXQVJOSU5HOiBDT05T T0xFIE9VVFBVVCBJUyBTWU5DSFJPTk9VUw0KKFhFTikgKioqKioqKiBUaGlzIG9wdGlvbiBpcyBp bnRlbmRlZCB0byBhaWQgZGVidWdnaW5nIG9mIFhlbiBieSBlbnN1cmluZw0KKFhFTikgKioqKioq KiB0aGF0IGFsbCBvdXRwdXQgaXMgc3luY2hyb25vdXNseSBkZWxpdmVyZWQgb24gdGhlIHNlcmlh bCBsaW5lLg0KKFhFTikgKioqKioqKiBIb3dldmVyIGl0IGNhbiBpbnRyb2R1Y2UgU0lHTklGSUNB TlQgbGF0ZW5jaWVzIGFuZCBhZmZlY3QNCihYRU4pICoqKioqKiogdGltZWtlZXBpbmcuIEl0IGlz IE5PVCByZWNvbW1lbmRlZCBmb3IgcHJvZHVjdGlvbiB1c2UhDQooWEVOKSAqKioqKioqKioqKioq KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqDQooWEVOKSAzLi4uIDIuLi4gMS4uLg0K KFhFTikgWGVuIGlzIHJlbGlucXVpc2hpbmcgVkdBIGNvbnNvbGUuDQooWEVOKSAqKiogU2VyaWFs IGlucHV0IC0+IERPTTAgKHR5cGUgJ0NUUkwtYScgdGhyZWUgdGltZXMgdG8gc3dpdGNoIGlucHV0 IHRvIFhlbikNCihYRU4pIEZyZWVkIDI5NmtCIGluaXQgbWVtb3J5Lg0KbWFwcGluZyBrZXJuZWwg aW50byBwaHlzaWNhbCBtZW1vcnkNCmFib3V0IHRvIGdldCBzdGFydGVkLi4uDQpJbml0aWFsaXpp bmcgY2dyb3VwIHN1YnN5cyBjcHVzZXQNCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIGNwdQ0K SW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgY3B1YWNjdA0KTGludXggdmVyc2lvbiAzLjEwLjQ1 LXhlbi4zNDguNzAuNTAwMjkgKGJ1aWxkQG5pbW95KSAoZ2NjIHZlcnNpb24gNC40LjcgMjAxMjAz MTMgKFJlZCBIYXQgNC40LjctNCkgKEdDQykgKSAjMSBTTVAgUFJFRU1QVCBUdWUgSnVuIDMwIDA2 OjIxOjM4IFBEVCAyMDE1DQpDb21tYW5kIGxpbmU6IHJvIHJvb3Q9L2Rldi9tYXBwZXIvdmdfbWF0 ZC1sdl9yYSByZF9OT19MVUtTIHJkX0xWTV9MVj12Z19tYXRkL2x2X3JhIExBTkc9ZW5fVVMuVVRG LTggcmRfTFZNX0xWPXZnX21hdGQvbHZfc3dhcCByZF9OT19NRCBTWVNGT05UPWxhdGFyY3lyaGVi LXN1bjE2IEtFWUJPQVJEVFlQRT1wYyBLRVlUQUJMRT11cyByZF9OT19ETSBCT09UX09QVElPTj1k aXNrLUEgT1NfVFlQRT1YZW4gZWFybHlwcmludGs9eGVuIG5vbW9kZXNldCBjb25zb2xlPXR0eTEg Y29uc29sZT1odmMwDQpLRVJORUwgc3VwcG9ydGVkIGNwdXM6DQogIEludGVsIEdlbnVpbmVJbnRl bA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KRnJlZWluZyA5Zi0xMDAgcGZuIHJh bmdlOiA5NyBwYWdlcyBmcmVlZA0KRnJlZWluZyBiZmVlMC1iZmYwMCBwZm4gcmFuZ2U6IDMyIHBh Z2VzIGZyZWVkDQpGcmVlaW5nIGMwMDAwLTEwMDAwMCBwZm4gcmFuZ2U6IDI2MjE0NCBwYWdlcyBm cmVlZA0KUmVsZWFzZWQgMjYyMjczIHBhZ2VzIG9mIHVudXNlZCBtZW1vcnkNClNldCAyNjIyNzMg cGFnZShzKSB0byAxLTEgbWFwcGluZw0KUG9wdWxhdGluZyAyMjAwMDAtMjYwMDgxIHBmbiByYW5n ZTogMjYyMjczIHBhZ2VzIGFkZGVkDQplODIwOiBCSU9TLXByb3ZpZGVkIHBoeXNpY2FsIFJBTSBt YXA6DQpYZW46IFttZW0gMHgwMDAwMDAwMDAwMDAwMDAwLTB4MDAwMDAwMDAwMDA5ZWZmZl0gdXNh YmxlDQpYZW46IFttZW0gMHgwMDAwMDAwMDAwMDlmNDAwLTB4MDAwMDAwMDAwMDBmZmZmZl0gcmVz ZXJ2ZWQNClhlbjogW21lbSAweDAwMDAwMDAwMDAxMDAwMDAtMHgwMDAwMDAwMGJmZWRmZmZmXSB1 c2FibGUNClhlbjogW21lbSAweDAwMDAwMDAwYmZlZTAwMDAtMHgwMDAwMDAwMGJmZWZlZmZmXSBB Q1BJIGRhdGENClhlbjogW21lbSAweDAwMDAwMDAwYmZlZmYwMDAtMHgwMDAwMDAwMGJmZWZmZmZm XSBBQ1BJIE5WUw0KWGVuOiBbbWVtIDB4MDAwMDAwMDBiZmYwMDAwMC0weDAwMDAwMDAwYmZmZmZm ZmZdIHVzYWJsZQ0KWGVuOiBbbWVtIDB4MDAwMDAwMDBlMDAwMDAwMC0weDAwMDAwMDAwZWZmZmZm ZmZdIHJlc2VydmVkDQpYZW46IFttZW0gMHgwMDAwMDAwMGZlYzAwMDAwLTB4MDAwMDAwMDBmZWMw ZmZmZl0gcmVzZXJ2ZWQNClhlbjogW21lbSAweDAwMDAwMDAwZmVlMDAwMDAtMHgwMDAwMDAwMGZl ZWZmZmZmXSByZXNlcnZlZA0KWGVuOiBbbWVtIDB4MDAwMDAwMDBmZmZlMDAwMC0weDAwMDAwMDAw ZmZmZmZmZmZdIHJlc2VydmVkDQpYZW46IFttZW0gMHgwMDAwMDAwMTAwMDAwMDAwLTB4MDAwMDAw MGMzZmZmZmZmZl0gdXNhYmxlDQpib290Y29uc29sZSBbeGVuYm9vdDBdIGVuYWJsZWQNCk5YIChF eGVjdXRlIERpc2FibGUpIHByb3RlY3Rpb246IGFjdGl2ZQ0KU01CSU9TIDIuNCBwcmVzZW50Lg0K ZTgyMDogbGFzdF9wZm4gPSAweGM0MDAwMCBtYXhfYXJjaF9wZm4gPSAweDQwMDAwMDAwMA0KZTgy MDogbGFzdF9wZm4gPSAweGMwMDAwIG1heF9hcmNoX3BmbiA9IDB4NDAwMDAwMDAwDQpTY2Fubmlu ZyAxIGFyZWFzIGZvciBsb3cgbWVtb3J5IGNvcnJ1cHRpb24NCmluaXRfbWVtb3J5X21hcHBpbmc6 IFttZW0gMHgwMDAwMDAwMC0weDAwMGZmZmZmXQ0KaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAw eDI1ZmUwMDAwMC0weDI1ZmZmZmZmZl0NCmluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgyNWMw MDAwMDAtMHgyNWZkZmZmZmZdDQppbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MjAwMDAwMDAw LTB4MjViZmZmZmZmXQ0KaW5pdF9tZW1vcnlfbWFwcGluZzogW21lbSAweDAwMTAwMDAwLTB4YmZl ZGZmZmZdDQppbml0X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4YmZmMDAwMDAtMHhiZmZmZmZmZl0N CmluaXRfbWVtb3J5X21hcHBpbmc6IFttZW0gMHgxMDAwMDAwMDAtMHgxZmZmZmZmZmZdDQppbml0 X21lbW9yeV9tYXBwaW5nOiBbbWVtIDB4MjYwMDAwMDAwLTB4YzNmZmZmZmZmXQ0KUkFNRElTSzog W21lbSAweDAyN2YzMDAwLTB4MDUzZTFmZmZdDQpBQ1BJOiBSU0RQIDAwMDAwMDAwMDAwZjZiODAg MDAwMjQgKHYwMiBQVExURCApDQpBQ1BJOiBYU0RUIDAwMDAwMDAwYmZlZWU3ODAgMDAwNUMgKHYw MSBJTlRFTCAgNDQwQlggICAgMDYwNDAwMDAgVk1XICAwMTMyNDI3MikNCkFDUEk6IEZBQ1AgMDAw MDAwMDBiZmVmZWU5OCAwMDBGNCAodjA0IElOVEVMICA0NDBCWCAgICAwNjA0MDAwMCBQVEwgIDAw MEY0MjQwKQ0KQUNQSTogRFNEVCAwMDAwMDAwMGJmZWVlYzIyIDEwMjc2ICh2MDEgUFRMVEQgIEN1 c3RvbSAgIDA2MDQwMDAwIE1TRlQgMDMwMDAwMDEpDQpBQ1BJOiBGQUNTIDAwMDAwMDAwYmZlZmZm YzAgMDAwNDANCkFDUEk6IEJPT1QgMDAwMDAwMDBiZmVlZWJmYSAwMDAyOCAodjAxIFBUTFREICAk U0JGVEJMJCAwNjA0MDAwMCAgTFRQIDAwMDAwMDAxKQ0KQUNQSTogQVBJQyAwMDAwMDAwMGJmZWVl YWQ4IDAwMTIyICh2MDEgUFRMVEQgID8gQVBJQyAgIDA2MDQwMDAwICBMVFAgMDAwMDAwMDApDQpB Q1BJOiBNQ0ZHIDAwMDAwMDAwYmZlZWVhOWMgMDAwM0MgKHYwMSBQVExURCAgJFBDSVRCTCQgMDYw NDAwMDAgIExUUCAwMDAwMDAwMSkNCkFDUEk6IFNSQVQgMDAwMDAwMDBiZmVlZTg3YyAwMDIyMCAo djAyIFZNV0FSRSBNRU1QTFVHICAwNjA0MDAwMCBWTVcgIDAwMDAwMDAxKQ0KQUNQSTogSFBFVCAw MDAwMDAwMGJmZWVlODQ0IDAwMDM4ICh2MDEgVk1XQVJFIFZNVyBIUEVUIDA2MDQwMDAwIFZNVyAg MDAwMDAwMDEpDQpBQ1BJOiBXQUVUIDAwMDAwMDAwYmZlZWU4MWMgMDAwMjggKHYwMSBWTVdBUkUg Vk1XIFdBRVQgMDYwNDAwMDAgVk1XICAwMDAwMDAwMSkNClNldHRpbmcgQVBJQyByb3V0aW5nIHRv IHBoeXNpY2FsIGZsYXQuDQpab25lIHJhbmdlczoNCiAgRE1BICAgICAgW21lbSAweDAwMDAxMDAw LTB4MDBmZmZmZmZdDQogIERNQTMyICAgIFttZW0gMHgwMTAwMDAwMC0weGZmZmZmZmZmXQ0KICBO b3JtYWwgICBbbWVtIDB4MTAwMDAwMDAwLTB4YzNmZmZmZmZmXQ0KTW92YWJsZSB6b25lIHN0YXJ0 IGZvciBlYWNoIG5vZGUNCkVhcmx5IG1lbW9yeSBub2RlIHJhbmdlcw0KICBub2RlICAgMDogW21l bSAweDAwMDAxMDAwLTB4MDAwOWVmZmZdDQogIG5vZGUgICAwOiBbbWVtIDB4MDAxMDAwMDAtMHhi ZmVkZmZmZl0NCiAgbm9kZSAgIDA6IFttZW0gMHhiZmYwMDAwMC0weGJmZmZmZmZmXQ0KICBub2Rl ICAgMDogW21lbSAweDEwMDAwMDAwMC0weGMzZmZmZmZmZl0NCkFDUEk6IFBNLVRpbWVyIElPIFBv cnQ6IDB4MTAwOA0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwMF0gbGFwaWNfaWRbMHgwMF0gZW5h YmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MDFdIGxhcGljX2lkWzB4MDFdIGVuYWJsZWQp DQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDAyXSBsYXBpY19pZFsweDAyXSBlbmFibGVkKQ0KQUNQ STogTEFQSUMgKGFjcGlfaWRbMHgwM10gbGFwaWNfaWRbMHgwM10gZW5hYmxlZCkNCkFDUEk6IExB UElDIChhY3BpX2lkWzB4MDRdIGxhcGljX2lkWzB4MDRdIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAo YWNwaV9pZFsweDA1XSBsYXBpY19pZFsweDA1XSBlbmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlf aWRbMHgwNl0gbGFwaWNfaWRbMHgwNl0gZW5hYmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4 MDddIGxhcGljX2lkWzB4MDddIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDA4XSBs YXBpY19pZFsweDA4XSBlbmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwOV0gbGFwaWNf aWRbMHgwOV0gZW5hYmxlZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGFdIGxhcGljX2lkWzB4 MGFdIGVuYWJsZWQpDQpBQ1BJOiBMQVBJQyAoYWNwaV9pZFsweDBiXSBsYXBpY19pZFsweDBiXSBl bmFibGVkKQ0KQUNQSTogTEFQSUMgKGFjcGlfaWRbMHgwY10gbGFwaWNfaWRbMHgwY10gZW5hYmxl ZCkNCkFDUEk6IExBUElDIChhY3BpX2lkWzB4MGRdIGxhcGljX2lkWzB4MGRdIGVuYWJsZWQpDQpB Q1BJOiBMQVBJQyAoYWNwaV9pZFsweDBlXSBsYXBpY19pZFsweDBlXSBlbmFibGVkKQ0KQUNQSTog TEFQSUMgKGFjcGlfaWRbMHgwZl0gbGFwaWNfaWRbMHgwZl0gZW5hYmxlZCkNCkFDUEk6IExBUElD X05NSSAoYWNwaV9pZFsweDAwXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1J IChhY3BpX2lkWzB4MDFdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFj cGlfaWRbMHgwMl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9p ZFsweDAzXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4 MDRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwNV0g aGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA2XSBoaWdo IGVkZ2UgbGludFsweDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MDddIGhpZ2ggZWRn ZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwOF0gaGlnaCBlZGdlIGxp bnRbMHgxXSkNCkFDUEk6IExBUElDX05NSSAoYWNwaV9pZFsweDA5XSBoaWdoIGVkZ2UgbGludFsw eDFdKQ0KQUNQSTogTEFQSUNfTk1JIChhY3BpX2lkWzB4MGFdIGhpZ2ggZWRnZSBsaW50WzB4MV0p DQpBQ1BJOiBMQVBJQ19OTUkgKGFjcGlfaWRbMHgwYl0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFD UEk6IExBUElDX05NSSAoYWNwaV9pZFsweDBjXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTog TEFQSUNfTk1JIChhY3BpX2lkWzB4MGRdIGhpZ2ggZWRnZSBsaW50WzB4MV0pDQpBQ1BJOiBMQVBJ Q19OTUkgKGFjcGlfaWRbMHgwZV0gaGlnaCBlZGdlIGxpbnRbMHgxXSkNCkFDUEk6IExBUElDX05N SSAoYWNwaV9pZFsweDBmXSBoaWdoIGVkZ2UgbGludFsweDFdKQ0KQUNQSTogSU9BUElDIChpZFsw eDEwXSBhZGRyZXNzWzB4ZmVjMDAwMDBdIGdzaV9iYXNlWzBdKQ0KSU9BUElDWzBdOiBhcGljX2lk IDE2LCB2ZXJzaW9uIDE3LCBhZGRyZXNzIDB4ZmVjMDAwMDAsIEdTSSAwLTIzDQpBQ1BJOiBJTlRf U1JDX09WUiAoYnVzIDAgYnVzX2lycSAwIGdsb2JhbF9pcnEgMiBoaWdoIGVkZ2UpDQpVc2luZyBB Q1BJIChNQURUKSBmb3IgU01QIGNvbmZpZ3VyYXRpb24gaW5mb3JtYXRpb24NCkFDUEk6IEhQRVQg aWQ6IDB4ODA4NmFmMDEgYmFzZTogMHhmZWQwMDAwMA0Kc21wYm9vdDogQWxsb3dpbmcgMTYgQ1BV cywgMCBob3RwbHVnIENQVXMNClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAw MDAwOWYwMDAgLSAwMDAwMDAwMDAwMGEwMDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5 OiAwMDAwMDAwMDAwMGEwMDAwIC0gMDAwMDAwMDAwMDEwMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9z YXZlIG1lbW9yeTogMDAwMDAwMDBiZmVlMDAwMCAtIDAwMDAwMDAwYmZlZmYwMDANClBNOiBSZWdp c3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwYmZlZmYwMDAgLSAwMDAwMDAwMGJmZjAwMDAw DQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGMwMDAwMDAwIC0gMDAwMDAw MDBlMDAwMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBlMDAwMDAw MCAtIDAwMDAwMDAwZjAwMDAwMDANClBNOiBSZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAw MDAwZjAwMDAwMDAgLSAwMDAwMDAwMGZlYzAwMDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVt b3J5OiAwMDAwMDAwMGZlYzAwMDAwIC0gMDAwMDAwMDBmZWMxMDAwMA0KUE06IFJlZ2lzdGVyZWQg bm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZWMxMDAwMCAtIDAwMDAwMDAwZmVlMDAwMDANClBNOiBS ZWdpc3RlcmVkIG5vc2F2ZSBtZW1vcnk6IDAwMDAwMDAwZmVlMDAwMDAgLSAwMDAwMDAwMGZlZjAw MDAwDQpQTTogUmVnaXN0ZXJlZCBub3NhdmUgbWVtb3J5OiAwMDAwMDAwMGZlZjAwMDAwIC0gMDAw MDAwMDBmZmZlMDAwMA0KUE06IFJlZ2lzdGVyZWQgbm9zYXZlIG1lbW9yeTogMDAwMDAwMDBmZmZl MDAwMCAtIDAwMDAwMDAxMDAwMDAwMDANCmU4MjA6IFttZW0gMHhjMDAwMDAwMC0weGRmZmZmZmZm XSBhdmFpbGFibGUgZm9yIFBDSSBkZXZpY2VzDQpCb290aW5nIHBhcmF2aXJ0dWFsaXplZCBrZXJu ZWwgb24gWGVuDQpYZW4gdmVyc2lvbjogNC40LjAgKHByZXNlcnZlLUFEKQ0Kc2V0dXBfcGVyY3B1 OiBOUl9DUFVTOjQwOTYgbnJfY3B1bWFza19iaXRzOjE2IG5yX2NwdV9pZHM6MTYgbnJfbm9kZV9p ZHM6MQ0KUEVSQ1BVOiBFbWJlZGRlZCAzMCBwYWdlcy9jcHUgQGZmZmY4ODAyNTljMDAwMDAgczkw MzY4IHI4MTkyIGQyNDMyMCB1MTMxMDcyDQpCdWlsdCAxIHpvbmVsaXN0cyBpbiBab25lIG9yZGVy LCBtb2JpbGl0eSBncm91cGluZyBvbi4gIFRvdGFsIHBhZ2VzOiAxMjQxMDcyOA0KS2VybmVsIGNv bW1hbmQgbGluZTogcm8gcm9vdD0vZGV2L21hcHBlci92Z19tYXRkLWx2X3JhIHJkX05PX0xVS1Mg cmRfTFZNX0xWPXZnX21hdGQvbHZfcmEgTEFORz1lbl9VUy5VVEYtOCByZF9MVk1fTFY9dmdfbWF0 ZC9sdl9zd2FwIHJkX05PX01EIFNZU0ZPTlQ9bGF0YXJjeXJoZWItc3VuMTYgS0VZQk9BUkRUWVBF PXBjIEtFWVRBQkxFPXVzIHJkX05PX0RNIEJPT1RfT1BUSU9OPWRpc2stQSBPU19UWVBFPVhlbiBl YXJseXByaW50az14ZW4gbm9tb2Rlc2V0IGNvbnNvbGU9dHR5MSBjb25zb2xlPWh2YzANClBJRCBo YXNoIHRhYmxlIGVudHJpZXM6IDQwOTYgKG9yZGVyOiAzLCAzMjc2OCBieXRlcykNCkRlbnRyeSBj YWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDgzODg2MDggKG9yZGVyOiAxNCwgNjcxMDg4NjQgYnl0 ZXMpDQpJbm9kZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDQxOTQzMDQgKG9yZGVyOiAxMywg MzM1NTQ0MzIgYnl0ZXMpDQpzb2Z0d2FyZSBJTyBUTEIgW21lbSAweDIyMzczNzAwMC0weDIyNzcz NzAwMF0gKDY0TUIpIG1hcHBlZCBhdCBbZmZmZjg4MDIyMzczNzAwMC1mZmZmODgwMjI3NzM2ZmZm XQ0KTWVtb3J5OiA3ODc1NDUyay81MTM4MDIyNGsgYXZhaWxhYmxlICg1MjU4ayBrZXJuZWwgY29k ZSwgMTA0OTA5NmsgYWJzZW50LCA0MjQ1NTY3NmsgcmVzZXJ2ZWQsIDEyMzAxayBkYXRhLCAxMjI0 ayBpbml0KQ0KUHJlZW1wdGlibGUgaGllcmFyY2hpY2FsIFJDVSBpbXBsZW1lbnRhdGlvbi4NCiAg ICAgICAgUkNVIHJlc3RyaWN0aW5nIENQVXMgZnJvbSBOUl9DUFVTPTQwOTYgdG8gbnJfY3B1X2lk cz04Lg0KTlJfSVJRUzoyNjI0MDAgbnJfaXJxczo3NDQgMTYNCnhlbjogc2NpIG92ZXJyaWRlOiBn bG9iYWxfaXJxPTkgdHJpZ2dlcj0wIHBvbGFyaXR5PTENCnhlbjogYWNwaSBzY2kgOQ0KQ29uc29s ZTogY29sb3VyIFZHQSsgODB4MjUNCmNvbnNvbGUgW3R0eTFdIGVuYWJsZWQNCmNvbnNvbGUgW2h2 YzBdIGVuYWJsZWQsIGJvb3Rjb25zb2xlIGRpc2FibGVkDQpjb25zb2xlIFtodmMwXSBlbmFibGVk LCBib290Y29uc29sZSBkaXNhYmxlZA0KaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAwDQp0 c2M6IERldGVjdGVkIDI2NjUuNDc4IE1IeiBwcm9jZXNzb3INCkNhbGlicmF0aW5nIGRlbGF5IGxv b3AgKHNraXBwZWQpLCB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRpbWVyIGZyZXF1ZW5jeS4uIDUz MzAuOTUgQm9nb01JUFMgKGxwaj0yNjY1NDc4KQ0KcGlkX21heDogZGVmYXVsdDogMzI3NjggbWlu aW11bTogMzAxDQpTZWN1cml0eSBGcmFtZXdvcmsgaW5pdGlhbGl6ZWQNClNFTGludXg6ICBJbml0 aWFsaXppbmcuDQpNb3VudC1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDI1Ng0KSW5pdGlhbGl6 aW5nIGNncm91cCBzdWJzeXMgZGV2aWNlcw0KSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgZnJl ZXplcg0KSW5pdGlhbGl6aW5nIGNncm91cCBzdWJzeXMgbmV0X2Nscw0KSW5pdGlhbGl6aW5nIGNn cm91cCBzdWJzeXMgYmxraW8NCkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIHBlcmZfZXZlbnQN CkluaXRpYWxpemluZyBjZ3JvdXAgc3Vic3lzIG5ldF9wcmlvDQpEaXNhYmxlZCBmYXN0IHN0cmlu ZyBvcGVyYXRpb25zDQpFTkVSR1lfUEVSRl9CSUFTOiBTZXQgdG8gJ25vcm1hbCcsIHdhcyAncGVy Zm9ybWFuY2UnDQpFTkVSR1lfUEVSRl9CSUFTOiBWaWV3IGFuZCB1cGRhdGUgd2l0aCB4ODZfZW5l cmd5X3BlcmZfcG9saWN5KDgpDQpDUFU6IFBoeXNpY2FsIFByb2Nlc3NvciBJRDogMA0KQ1BVOiBQ cm9jZXNzb3IgQ29yZSBJRDogMA0KbWNlOiBDUFUgc3VwcG9ydHMgMiBNQ0UgYmFua3MNCihYRU4p IGRvbWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwMDI2MjAgLT4g MDAwMDI2NjANCkxhc3QgbGV2ZWwgaVRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgNywgNE1CIDcN Ckxhc3QgbGV2ZWwgZFRMQiBlbnRyaWVzOiA0S0IgNTEyLCAyTUIgMzIsIDRNQiAzMg0KdGxiX2Zs dXNoYWxsX3NoaWZ0OiA2DQpGcmVlaW5nIFNNUCBhbHRlcm5hdGl2ZXM6IDIwayBmcmVlZA0KQUNQ STogQ29yZSByZXZpc2lvbiAyMDEzMDMyOA0KQUNQSTogQWxsIEFDUEkgVGFibGVzIHN1Y2Nlc3Nm dWxseSBhY3F1aXJlZA0KZnRyYWNlOiBhbGxvY2F0aW5nIDIyNzg1IGVudHJpZXMgaW4gOTAgcGFn ZXMNCmNwdSAwIHNwaW5sb2NrIGV2ZW50IGlycSA0MQ0KUGVyZm9ybWFuY2UgRXZlbnRzOiB1bnN1 cHBvcnRlZCBwNiBDUFUgbW9kZWwgNDQgbm8gUE1VIGRyaXZlciwgc29mdHdhcmUgZXZlbnRzIG9u bHkuDQpOTUkgd2F0Y2hkb2c6IGRpc2FibGVkIChjcHUwKTogaGFyZHdhcmUgZXZlbnRzIG5vdCBl bmFibGVkDQppbnN0YWxsaW5nIFhlbiB0aW1lciBmb3IgQ1BVIDENCmNwdSAxIHNwaW5sb2NrIGV2 ZW50IGlycSA0OA0KKFhFTikgZG9tYWluLmM6NjMyOmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBm bGFncyAwMDAwMjYyMCAtPiAwMDAwMjY2MA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9u cw0KaW5zdGFsbGluZyBYZW4gdGltZXIgZm9yIENQVSAyDQpjcHUgMiBzcGlubG9jayBldmVudCBp cnEgNTUNCihYRU4pIGRvbWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3Mg MDAwMDI2MjAgLT4gMDAwMDI2NjANCkRpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMNCmlu c3RhbGxpbmcgWGVuIHRpbWVyIGZvciBDUFUgMw0KY3B1IDMgc3BpbmxvY2sgZXZlbnQgaXJxIDYy DQooWEVOKSBkb21haW4uYzo2MzI6ZDAgQXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDAy NjIwIC0+IDAwMDAyNjYwDQpEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zDQppbnN0YWxs aW5nIFhlbiB0aW1lciBmb3IgQ1BVIDQNCmNwdSA0IHNwaW5sb2NrIGV2ZW50IGlycSA2OQ0KKFhF TikgZG9tYWluLmM6NjMyOmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDAwMjYyMCAt PiAwMDAwMjY2MA0KRGlzYWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KaW5zdGFsbGluZyBY ZW4gdGltZXIgZm9yIENQVSA1DQpjcHUgNSBzcGlubG9jayBldmVudCBpcnEgNzYNCihYRU4pIGRv bWFpbi5jOjYzMjpkMCBBdHRlbXB0IHRvIGNoYW5nZSBDUjQgZmxhZ3MgMDAwMDI2MjAgLT4gMDAw MDI2NjANCkRpc2FibGVkIGZhc3Qgc3RyaW5nIG9wZXJhdGlvbnMNCmluc3RhbGxpbmcgWGVuIHRp bWVyIGZvciBDUFUgNg0KY3B1IDYgc3BpbmxvY2sgZXZlbnQgaXJxIDgzDQooWEVOKSBkb21haW4u Yzo2MzI6ZDAgQXR0ZW1wdCB0byBjaGFuZ2UgQ1I0IGZsYWdzIDAwMDAyNjIwIC0+IDAwMDAyNjYw DQpEaXNhYmxlZCBmYXN0IHN0cmluZyBvcGVyYXRpb25zDQppbnN0YWxsaW5nIFhlbiB0aW1lciBm b3IgQ1BVIDcNCmNwdSA3IHNwaW5sb2NrIGV2ZW50IGlycSA5MA0KKFhFTikgZG9tYWluLmM6NjMy OmQwIEF0dGVtcHQgdG8gY2hhbmdlIENSNCBmbGFncyAwMDAwMjYyMCAtPiAwMDAwMjY2MA0KRGlz YWJsZWQgZmFzdCBzdHJpbmcgb3BlcmF0aW9ucw0KQnJvdWdodCB1cCA4IENQVXMNCg== --001a113e8e6a6cb0960519d97e41 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --001a113e8e6a6cb0960519d97e41-- From xen-users-bounces@lists.xen.org Thu Jul 02 08:34:58 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 08:34:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAZwN-0005g2-A3; Thu, 02 Jul 2015 08:33:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAZwL-0005fx-EA for xen-users@lists.xen.org; Thu, 02 Jul 2015 08:33:49 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 9A/86-05081-C67F4955; Thu, 02 Jul 2015 08:33:48 +0000 X-Env-Sender: prvs=6180f4332=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1435826026!18431010!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, ML_RADAR_SPEW_LINKS_8, spamassassin: ,received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20106 invoked from network); 2 Jul 2015 08:33:47 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 08:33:47 -0000 X-IronPort-AV: E=Sophos;i="5.15,391,1432598400"; d="scan'208";a="280649085" Message-ID: <1435826023.21469.305.camel@citrix.com> From: Ian Campbell To: Brandon Date: Thu, 2 Jul 2015 09:33:43 +0100 In-Reply-To: <022401d0b418$327975e0$976c61a0$@thinkhuge.net> References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> <55940D6A.2050304@prgmr.com> <022401d0b418$327975e0$976c61a0$@thinkhuge.net> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org, 'Sarah Newman' Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Brandon, As well as Xen4CentOS (http://wiki.xenproject.org/wiki/Xen4CentOS and http://wiki.centos.org/HowTos/Xen/Xen4QuickStart) there are various consultants offering paid support of various kinds listed at http://www.xenproject.org/directory/directory/consulting.html Of those I know that http://xen.crc.id.au/ does CentOS (and related distros) packages and offers support (I have no particular affiliation with the xen.crc.id.au guys, and I've not used their stuff myself). Ian. On Wed, 2015-07-01 at 09:08 -0700, Brandon wrote: > Hi Sarah and List, > > Thanks so much for the reply and info. > > I am running 3.10.68-11.el6.centos.alt.x86_64 most everywhere so I will > upgrade asap. > > > -----Original Message----- > From: Sarah Newman [mailto:srn@prgmr.com] > Sent: Wednesday, July 01, 2015 8:55 AM > To: Brandon; xen-users@lists.xen.org > Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen > 4.4.2 > > On 07/01/2015 07:56 AM, Brandon wrote: > > Hi Xen User List, > > > > > > > > I have a recurring bug shown below which is causing me serious problems. > It's so serious my company is considering abandoning XEN for KVM but, we > > have many XEN servers and VMs so this is not an easy decision. My > CentOS6 Xen servers are built using SolusVM install script and run Windows > 2008 R2 > > / 2012 R1 guests. They run great except for this recurring bug. > > > > > > > > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL > Toolstack and we've been encountering this showstopper bug for the last 6 > > months or so randomly on different servers. When this BUG is encountered > my VM guests will no longer be able to boot if they are restarted. I am > > forced to reboot the entire server interrupting all VM guests. I've had > about 6-7 encounters with this bug. One time it hard crashed the server > > while I was migrating a VM to another server. The other times I have > made it to the weekend so I can do a graceful reboot. > > > > > > > > Does anyone know of this issue? > > > > > > > > Is there any paid Xen support that can debug and solve this? I'm using > CentOS6 so this is not a RHEL box under support contract but, we'd probably > > be willing to pay in a per incident type scenario if the cost was > reasonable. > > > > > > > > Any advice is much appreciated. > > > > Looks like it might be > http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oops-in-xen-netbk-rx-action > -xenvif-gop-skb > > According to Wei Liu the bug is gone in version 3.12 or later, though I have > not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days > ago. > > Regards, Sarah > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 08:34:58 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 08:34:58 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAZwN-0005g2-A3; Thu, 02 Jul 2015 08:33:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAZwL-0005fx-EA for xen-users@lists.xen.org; Thu, 02 Jul 2015 08:33:49 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id 9A/86-05081-C67F4955; Thu, 02 Jul 2015 08:33:48 +0000 X-Env-Sender: prvs=6180f4332=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1435826026!18431010!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, ML_RADAR_SPEW_LINKS_8, spamassassin: ,received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20106 invoked from network); 2 Jul 2015 08:33:47 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 08:33:47 -0000 X-IronPort-AV: E=Sophos;i="5.15,391,1432598400"; d="scan'208";a="280649085" Message-ID: <1435826023.21469.305.camel@citrix.com> From: Ian Campbell To: Brandon Date: Thu, 2 Jul 2015 09:33:43 +0100 In-Reply-To: <022401d0b418$327975e0$976c61a0$@thinkhuge.net> References: <01a501d0b40e$1a429f60$4ec7de20$@thinkhuge.net> <55940D6A.2050304@prgmr.com> <022401d0b418$327975e0$976c61a0$@thinkhuge.net> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org, 'Sarah Newman' Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen 4.4.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Brandon, As well as Xen4CentOS (http://wiki.xenproject.org/wiki/Xen4CentOS and http://wiki.centos.org/HowTos/Xen/Xen4QuickStart) there are various consultants offering paid support of various kinds listed at http://www.xenproject.org/directory/directory/consulting.html Of those I know that http://xen.crc.id.au/ does CentOS (and related distros) packages and offers support (I have no particular affiliation with the xen.crc.id.au guys, and I've not used their stuff myself). Ian. On Wed, 2015-07-01 at 09:08 -0700, Brandon wrote: > Hi Sarah and List, > > Thanks so much for the reply and info. > > I am running 3.10.68-11.el6.centos.alt.x86_64 most everywhere so I will > upgrade asap. > > > -----Original Message----- > From: Sarah Newman [mailto:srn@prgmr.com] > Sent: Wednesday, July 01, 2015 8:55 AM > To: Brandon; xen-users@lists.xen.org > Subject: Re: [Xen-users] BUG: unable to handle kernel paging request Xen > 4.4.2 > > On 07/01/2015 07:56 AM, Brandon wrote: > > Hi Xen User List, > > > > > > > > I have a recurring bug shown below which is causing me serious problems. > It's so serious my company is considering abandoning XEN for KVM but, we > > have many XEN servers and VMs so this is not an easy decision. My > CentOS6 Xen servers are built using SolusVM install script and run Windows > 2008 R2 > > / 2012 R1 guests. They run great except for this recurring bug. > > > > > > > > The servers are Xen 4.4.2 (and some slightly earlier versions) using XL > Toolstack and we've been encountering this showstopper bug for the last 6 > > months or so randomly on different servers. When this BUG is encountered > my VM guests will no longer be able to boot if they are restarted. I am > > forced to reboot the entire server interrupting all VM guests. I've had > about 6-7 encounters with this bug. One time it hard crashed the server > > while I was migrating a VM to another server. The other times I have > made it to the weekend so I can do a graceful reboot. > > > > > > > > Does anyone know of this issue? > > > > > > > > Is there any paid Xen support that can debug and solve this? I'm using > CentOS6 so this is not a RHEL box under support contract but, we'd probably > > be willing to pay in a per incident type scenario if the cost was > reasonable. > > > > > > > > Any advice is much appreciated. > > > > Looks like it might be > http://xen-devel.narkive.com/4ANUbmbs/rfh-kernel-oops-in-xen-netbk-rx-action > -xenvif-gop-skb > > According to Wei Liu the bug is gone in version 3.12 or later, though I have > not reviewed the code myself. Xen4CentOS released kernel-3.18.12-11 2 days > ago. > > Regards, Sarah > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 09:04:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 09:04:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAaPE-0007vf-1K; Thu, 02 Jul 2015 09:03:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAaPC-0007vX-KD for xen-users@lists.xen.org; Thu, 02 Jul 2015 09:03:38 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 97/FF-02952-96EF4955; Thu, 02 Jul 2015 09:03:37 +0000 X-Env-Sender: prvs=6180f4332=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1435827815!20675326!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6666 invoked from network); 2 Jul 2015 09:03:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 09:03:37 -0000 X-IronPort-AV: E=Sophos;i="5.15,391,1432598400"; d="scan'208";a="277650767" Message-ID: <1435827812.21469.321.camel@citrix.com> From: Ian Campbell To: Josh Drenan Date: Thu, 2 Jul 2015 10:03:32 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote: > Greetings all I have an error where dom0 freezes during boot and was > wondering if anyone could help. I have tried using most of the acpi > command line options to no avail. > > > I am trying to boot xen as a virtual machine inside of ESXI, it works > if the total number of cores is less than or equal to 8 but no more > for some reason. > > I have included the log from the boot. How many cores (physical and hyperthreaded) does the host have? I'm afraid I've no idea what's going on, but some things which might give some clues: Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then the usual set of letters (h for help). Depending on kernel version you might need "sysrq_always_enabled" and/or "kernel.sysrq=1" on your dom0 command line else it'll just say it's not allowed. Interesting ones would be the key which gives you a backtraces on all cpus, or shows you all waiting processes. Secondly on the Xen console you can press Ctrl-a 3 times (by default, xen's conswitch option can change it) to switch to Xen debug key mode, at which point h gets you help and there are various helpful keys you can press, 'd', 'q' and '0' being the ones I usually find useful stuff in. '*' gets you everything. Perhaps somewhere in all that there might be some hint what is going on. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 09:04:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 09:04:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAaPE-0007vf-1K; Thu, 02 Jul 2015 09:03:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAaPC-0007vX-KD for xen-users@lists.xen.org; Thu, 02 Jul 2015 09:03:38 +0000 Received: from [85.158.137.68] by server-12.bemta-3.messagelabs.com id 97/FF-02952-96EF4955; Thu, 02 Jul 2015 09:03:37 +0000 X-Env-Sender: prvs=6180f4332=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1435827815!20675326!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6666 invoked from network); 2 Jul 2015 09:03:37 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 09:03:37 -0000 X-IronPort-AV: E=Sophos;i="5.15,391,1432598400"; d="scan'208";a="277650767" Message-ID: <1435827812.21469.321.camel@citrix.com> From: Ian Campbell To: Josh Drenan Date: Thu, 2 Jul 2015 10:03:32 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote: > Greetings all I have an error where dom0 freezes during boot and was > wondering if anyone could help. I have tried using most of the acpi > command line options to no avail. > > > I am trying to boot xen as a virtual machine inside of ESXI, it works > if the total number of cores is less than or equal to 8 but no more > for some reason. > > I have included the log from the boot. How many cores (physical and hyperthreaded) does the host have? I'm afraid I've no idea what's going on, but some things which might give some clues: Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then the usual set of letters (h for help). Depending on kernel version you might need "sysrq_always_enabled" and/or "kernel.sysrq=1" on your dom0 command line else it'll just say it's not allowed. Interesting ones would be the key which gives you a backtraces on all cpus, or shows you all waiting processes. Secondly on the Xen console you can press Ctrl-a 3 times (by default, xen's conswitch option can change it) to switch to Xen debug key mode, at which point h gets you help and there are various helpful keys you can press, 'd', 'q' and '0' being the ones I usually find useful stuff in. '*' gets you everything. Perhaps somewhere in all that there might be some hint what is going on. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 14:09:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 14:09:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAf9w-00034b-20; Thu, 02 Jul 2015 14:08:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAf9u-00034P-Qz for xen-users@lists.xen.org; Thu, 02 Jul 2015 14:08:10 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id FD/9F-03035-AC545955; Thu, 02 Jul 2015 14:08:10 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1435846089!17647120!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31690 invoked from network); 2 Jul 2015 14:08:09 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2015 14:08:09 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id B6088C306 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 6CB7DC1B6 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id 2235B9E033 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Message-ID: <559545C7.3010600@epiontis.com> Date: Thu, 02 Jul 2015 16:08:07 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I looked further into the issue. When I start a migration with "xl migrate " the destination machine sets up a vm "--incoming" and seems to sync memory because "xl list" shows "Mem" for the incoming vm going up stepwise until 2048. After that though the vm doesn't get launched. The vm is frozen for about a minute, the dom0 begins swapping out the 2GB to disk (because it only has 512M available for itself) and a process /usr/lib/xen-4.5/bin/libxl-save-helper --restore-domain takes about 90% of the dom0 memory. After that the vm ist launched, memory consumption goes back to normal, swap space is freed. Is this some kind of cold migration process? Is there some option I'm missing that does real live migration? Alex _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 14:09:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 14:09:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAf9w-00034b-20; Thu, 02 Jul 2015 14:08:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAf9u-00034P-Qz for xen-users@lists.xen.org; Thu, 02 Jul 2015 14:08:10 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id FD/9F-03035-AC545955; Thu, 02 Jul 2015 14:08:10 +0000 X-Env-Sender: it_mailinglists@epiontis.com X-Msg-Ref: server-6.tower-31.messagelabs.com!1435846089!17647120!1 X-Originating-IP: [141.16.91.162] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31690 invoked from network); 2 Jul 2015 14:08:09 -0000 Received: from pc1.epiontis.fta-berlin.de (HELO pc1.epiontis.fta-berlin.de) (141.16.91.162) by server-6.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2015 14:08:09 -0000 Received: from pc1.epiontis.fta-berlin.de (localhost [127.0.0.1]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id B6088C306 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Received: from goethe.epiontis.epi (goethe.epiontis.epi [192.168.38.100]) by pc1.epiontis.fta-berlin.de (Postfix) with ESMTP id 6CB7DC1B6 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Received: from [192.168.38.132] (alamo.epiontis.epi [192.168.38.132]) by goethe.epiontis.epi (Postfix) with ESMTPS id 2235B9E033 for ; Thu, 2 Jul 2015 16:08:08 +0200 (CEST) Message-ID: <559545C7.3010600@epiontis.com> Date: Thu, 02 Jul 2015 16:08:07 +0200 From: Epiontis IT User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> In-Reply-To: <1435761032.21469.292.camel@citrix.com> X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/01/2015 04:30 PM, Ian Campbell wrote: > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: >> Hello, >> >> I'm new to XEN live migration. I have a question regarding XEN memory >> management while doing a vm live migration. I observed that migrating a >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target >> machine to have memory available that is the size of the memory >> allocated to the vm (2G). Since I follow "XEN best practices" and set >> dom0_mem to 512M the target machine begins swapping out 2G to disk which >> makes everything nearly unresponsive. Is this requirement for the dom0 >> memory size intended or might there be an issue with my setup? > I don't think you should need 2G dom0 memory, you should need 2G of free > host memory. > > Perhaps something on your destination host is thinking it wants to > balloon dom0 down in order to make that free host memory available? > > Ian. I looked further into the issue. When I start a migration with "xl migrate " the destination machine sets up a vm "--incoming" and seems to sync memory because "xl list" shows "Mem" for the incoming vm going up stepwise until 2048. After that though the vm doesn't get launched. The vm is frozen for about a minute, the dom0 begins swapping out the 2GB to disk (because it only has 512M available for itself) and a process /usr/lib/xen-4.5/bin/libxl-save-helper --restore-domain takes about 90% of the dom0 memory. After that the vm ist launched, memory consumption goes back to normal, swap space is freed. Is this some kind of cold migration process? Is there some option I'm missing that does real live migration? Alex _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 02 14:35:10 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 14:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAfZ7-0005pU-36; Thu, 02 Jul 2015 14:34:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAfZ5-0005pO-Ck for xen-users@lists.xen.org; Thu, 02 Jul 2015 14:34:11 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id F9/51-01068-2EB45955; Thu, 02 Jul 2015 14:34:10 +0000 X-Env-Sender: josh.drenan@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435847647!22085691!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17189 invoked from network); 2 Jul 2015 14:34:08 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 14:34:08 -0000 Received: by iecuq6 with SMTP id uq6so57690826iec.2 for ; Thu, 02 Jul 2015 07:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=KzzDYq5h5anMq3ua3petTv5HFHQdRJqaQNjQKqHzIAc=; b=h0XFiXg4ElQv/7I/sqN4PjaYd5bghvAfauIZnTU9CvFp9O2sob6CkoS9M/+OiiBa0+ UdB+6Fkr49rG+skZ1Qxlom4KgcDVdUVIhqVmgtPr0C7qM8oIkoJbuhsga0PN3kn40hnY tD12GGs6+JID6/ARxuZvMPxdPXX77Dp9o6c6O03zfLG4pk4PBYdYgTu6pc8lHuwi1ia8 kJFnAJwQXRjFjKXDWV/Hzr6YUofWXCgmhgK55mYJ5+CdIAgP/jmp7v4w9H+ZOpgquK8F N2RycR+acQM/f5MG3ySN55i3Gm5LHmU8kmDniklJqWSge/hYBfZZw+mbfWgqThOmivvM LXhQ== X-Received: by 10.107.30.69 with SMTP id e66mr15742475ioe.76.1435847647430; Thu, 02 Jul 2015 07:34:07 -0700 (PDT) MIME-Version: 1.0 References: <1435827812.21469.321.camel@citrix.com> In-Reply-To: <1435827812.21469.321.camel@citrix.com> From: Josh Drenan Date: Thu, 02 Jul 2015 14:33:58 +0000 Message-ID: To: Ian Campbell Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1069691098555127919==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1069691098555127919== Content-Type: multipart/alternative; boundary=001a1140f33afa0d3a0519e554bd --001a1140f33afa0d3a0519e554bd Content-Type: text/plain; charset=UTF-8 Thanks for the response I'll start with those commands to see if I can learn anything new. The host has 2 sockets with 6 cores per socket for 12 physical cores, 24 logical cores with hyper threading. On Thu, Jul 2, 2015 at 5:03 AM Ian Campbell wrote: > On Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote: > > Greetings all I have an error where dom0 freezes during boot and was > > wondering if anyone could help. I have tried using most of the acpi > > command line options to no avail. > > > > > > I am trying to boot xen as a virtual machine inside of ESXI, it works > > if the total number of cores is less than or equal to 8 but no more > > for some reason. > > > > I have included the log from the boot. > > How many cores (physical and hyperthreaded) does the host have? > > I'm afraid I've no idea what's going on, but some things which might > give some clues: > > Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then > the usual set of letters (h for help). Depending on kernel version you > might need "sysrq_always_enabled" and/or "kernel.sysrq=1" on your dom0 > command line else it'll just say it's not allowed. Interesting ones > would be the key which gives you a backtraces on all cpus, or shows you > all waiting processes. > > Secondly on the Xen console you can press Ctrl-a 3 times (by default, > xen's conswitch option can change it) to switch to Xen debug key mode, > at which point h gets you help and there are various helpful keys you > can press, 'd', 'q' and '0' being the ones I usually find useful stuff > in. '*' gets you everything. > > Perhaps somewhere in all that there might be some hint what is going on. > > Ian. > > --001a1140f33afa0d3a0519e554bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the response I'll start with those commands= to see if I can learn anything new.
The host has 2 sockets with 6 cores= per socket for 12 physical cores, 24 logical cores with hyper threading.
On Thu, Jul 2, 2015 at = 5:03 AM Ian Campbell <ian.cam= pbell@citrix.com> wrote:
On = Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote:
> Greetings all I have an error where dom0=C2=A0 freezes during boot and= was
> wondering if anyone could help. I have tried using most of the acpi > command line options to no avail.
>
>
> I am trying to boot xen as a virtual machine inside of ESXI, it works<= br> > if the total number of cores is less than or equal to 8 but no more > for some reason.
>
> I have included the log from the boot.

How many cores (physical and hyperthreaded) does the host have?

I'm afraid I've no idea what's going on, but some things which = might
give some clues:

Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then the usual set of letters (h for help). Depending on kernel version you
might need "sysrq_always_enabled" and/or "kernel.sysrq=3D1&q= uot; on your dom0
command line else it'll just say it's not allowed. Interesting ones=
would be the key which gives you a backtraces on all cpus, or shows you
all waiting processes.

Secondly on the Xen console you can press Ctrl-a 3 times (by default,
xen's conswitch option can change it) to switch to Xen debug key mode,<= br> at which point h gets you help and there are various helpful keys you
can press, 'd', 'q' and '0' being the ones I usuall= y find useful stuff
in. '*' gets you everything.

Perhaps somewhere in all that there might be some hint what is going on.
Ian.

--001a1140f33afa0d3a0519e554bd-- --===============1069691098555127919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1069691098555127919==-- From xen-users-bounces@lists.xen.org Thu Jul 02 14:35:10 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 14:35:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAfZ7-0005pU-36; Thu, 02 Jul 2015 14:34:13 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAfZ5-0005pO-Ck for xen-users@lists.xen.org; Thu, 02 Jul 2015 14:34:11 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id F9/51-01068-2EB45955; Thu, 02 Jul 2015 14:34:10 +0000 X-Env-Sender: josh.drenan@gmail.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435847647!22085691!1 X-Originating-IP: [209.85.223.180] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17189 invoked from network); 2 Jul 2015 14:34:08 -0000 Received: from mail-ie0-f180.google.com (HELO mail-ie0-f180.google.com) (209.85.223.180) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 14:34:08 -0000 Received: by iecuq6 with SMTP id uq6so57690826iec.2 for ; Thu, 02 Jul 2015 07:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=KzzDYq5h5anMq3ua3petTv5HFHQdRJqaQNjQKqHzIAc=; b=h0XFiXg4ElQv/7I/sqN4PjaYd5bghvAfauIZnTU9CvFp9O2sob6CkoS9M/+OiiBa0+ UdB+6Fkr49rG+skZ1Qxlom4KgcDVdUVIhqVmgtPr0C7qM8oIkoJbuhsga0PN3kn40hnY tD12GGs6+JID6/ARxuZvMPxdPXX77Dp9o6c6O03zfLG4pk4PBYdYgTu6pc8lHuwi1ia8 kJFnAJwQXRjFjKXDWV/Hzr6YUofWXCgmhgK55mYJ5+CdIAgP/jmp7v4w9H+ZOpgquK8F N2RycR+acQM/f5MG3ySN55i3Gm5LHmU8kmDniklJqWSge/hYBfZZw+mbfWgqThOmivvM LXhQ== X-Received: by 10.107.30.69 with SMTP id e66mr15742475ioe.76.1435847647430; Thu, 02 Jul 2015 07:34:07 -0700 (PDT) MIME-Version: 1.0 References: <1435827812.21469.321.camel@citrix.com> In-Reply-To: <1435827812.21469.321.camel@citrix.com> From: Josh Drenan Date: Thu, 02 Jul 2015 14:33:58 +0000 Message-ID: To: Ian Campbell Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] Dom0 Hangs while booting X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1069691098555127919==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1069691098555127919== Content-Type: multipart/alternative; boundary=001a1140f33afa0d3a0519e554bd --001a1140f33afa0d3a0519e554bd Content-Type: text/plain; charset=UTF-8 Thanks for the response I'll start with those commands to see if I can learn anything new. The host has 2 sockets with 6 cores per socket for 12 physical cores, 24 logical cores with hyper threading. On Thu, Jul 2, 2015 at 5:03 AM Ian Campbell wrote: > On Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote: > > Greetings all I have an error where dom0 freezes during boot and was > > wondering if anyone could help. I have tried using most of the acpi > > command line options to no avail. > > > > > > I am trying to boot xen as a virtual machine inside of ESXI, it works > > if the total number of cores is less than or equal to 8 but no more > > for some reason. > > > > I have included the log from the boot. > > How many cores (physical and hyperthreaded) does the host have? > > I'm afraid I've no idea what's going on, but some things which might > give some clues: > > Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then > the usual set of letters (h for help). Depending on kernel version you > might need "sysrq_always_enabled" and/or "kernel.sysrq=1" on your dom0 > command line else it'll just say it's not allowed. Interesting ones > would be the key which gives you a backtraces on all cpus, or shows you > all waiting processes. > > Secondly on the Xen console you can press Ctrl-a 3 times (by default, > xen's conswitch option can change it) to switch to Xen debug key mode, > at which point h gets you help and there are various helpful keys you > can press, 'd', 'q' and '0' being the ones I usually find useful stuff > in. '*' gets you everything. > > Perhaps somewhere in all that there might be some hint what is going on. > > Ian. > > --001a1140f33afa0d3a0519e554bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the response I'll start with those commands= to see if I can learn anything new.
The host has 2 sockets with 6 cores= per socket for 12 physical cores, 24 logical cores with hyper threading.
On Thu, Jul 2, 2015 at = 5:03 AM Ian Campbell <ian.cam= pbell@citrix.com> wrote:
On = Thu, 2015-07-02 at 00:26 +0000, Josh Drenan wrote:
> Greetings all I have an error where dom0=C2=A0 freezes during boot and= was
> wondering if anyone could help. I have tried using most of the acpi > command line options to no avail.
>
>
> I am trying to boot xen as a virtual machine inside of ESXI, it works<= br> > if the total number of cores is less than or equal to 8 but no more > for some reason.
>
> I have included the log from the boot.

How many cores (physical and hyperthreaded) does the host have?

I'm afraid I've no idea what's going on, but some things which = might
give some clues:

Magic Sysrq to dom0, the keystroke for a Xen hvc console is Ctrl-o, then the usual set of letters (h for help). Depending on kernel version you
might need "sysrq_always_enabled" and/or "kernel.sysrq=3D1&q= uot; on your dom0
command line else it'll just say it's not allowed. Interesting ones=
would be the key which gives you a backtraces on all cpus, or shows you
all waiting processes.

Secondly on the Xen console you can press Ctrl-a 3 times (by default,
xen's conswitch option can change it) to switch to Xen debug key mode,<= br> at which point h gets you help and there are various helpful keys you
can press, 'd', 'q' and '0' being the ones I usuall= y find useful stuff
in. '*' gets you everything.

Perhaps somewhere in all that there might be some hint what is going on.
Ian.

--001a1140f33afa0d3a0519e554bd-- --===============1069691098555127919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1069691098555127919==-- From xen-users-bounces@lists.xen.org Thu Jul 02 16:52:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 16:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhi7-0002s8-18; Thu, 02 Jul 2015 16:51:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhi6-0002ru-DT for xen-users@lists.xen.org; Thu, 02 Jul 2015 16:51:38 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 46/C3-27764-91C65955; Thu, 02 Jul 2015 16:51:37 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1435855896!28783494!1 X-Originating-IP: [209.85.220.172] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27262 invoked from network); 2 Jul 2015 16:51:36 -0000 Received: from mail-qk0-f172.google.com (HELO mail-qk0-f172.google.com) (209.85.220.172) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 16:51:36 -0000 Received: by qkhu186 with SMTP id u186so55955911qkh.0 for ; Thu, 02 Jul 2015 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pKWjRt3LYwzlKjUSnJ5btTdMD5TLL3/yMvAmQJ/S3GM=; b=ZWiBIA1IEzrqrP9mSJPf0JZoIvaz5xS2PMd1GKHVPO5HVX+ZzOGqXUulF+2VoCpvdD VRANOnTGNn3w6HRkbRuwVba2/ngoBDysMnbL0oBOwS50VCE/kvawGZBhe1REZCa1LRR6 HQoRZpJUCYPJFuXuCEiv+GmxShgoadiPEU2Te6pYZ69QiIZJTyT/v7xhjY8VyUs7/784 /yKiG5SZcD0AzoXPIlylKEW6CDMe4stn2wgM0ydHPkaerul4548zFR+eB1gRxsVttrer ncf4rzkuuUaY4FJ/fridNQsu7b+e8s/OQE5mtNLfXk/ILAQfUYvLUnl+pl0VedWcHwPk vxXA== MIME-Version: 1.0 X-Received: by 10.55.23.195 with SMTP id 64mr66209153qkx.9.1435855895802; Thu, 02 Jul 2015 09:51:35 -0700 (PDT) Received: by 10.140.102.104 with HTTP; Thu, 2 Jul 2015 09:51:35 -0700 (PDT) Date: Thu, 2 Jul 2015 10:51:35 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] vmware horizon view free replacement X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6522565130363724552==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6522565130363724552== Content-Type: multipart/alternative; boundary=001a1147f1a29e3a2d0519e74010 --001a1147f1a29e3a2d0519e74010 Content-Type: text/plain; charset=UTF-8 I wonder if anyone had setup xen to replace vmware horizon view. I guess I could install number of virtual desktops and have proxy to connect rpd to each virtual desktop. --001a1147f1a29e3a2d0519e74010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wonder if anyone had setup xen to replace vmware horizon= view. I guess I could install number of virtual desktops and have proxy to= connect rpd to each virtual desktop.=C2=A0

--001a1147f1a29e3a2d0519e74010-- --===============6522565130363724552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6522565130363724552==-- From xen-users-bounces@lists.xen.org Thu Jul 02 16:52:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 16:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhi7-0002s8-18; Thu, 02 Jul 2015 16:51:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhi6-0002ru-DT for xen-users@lists.xen.org; Thu, 02 Jul 2015 16:51:38 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 46/C3-27764-91C65955; Thu, 02 Jul 2015 16:51:37 +0000 X-Env-Sender: jaceksburghardt@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1435855896!28783494!1 X-Originating-IP: [209.85.220.172] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_10_20,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27262 invoked from network); 2 Jul 2015 16:51:36 -0000 Received: from mail-qk0-f172.google.com (HELO mail-qk0-f172.google.com) (209.85.220.172) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 2 Jul 2015 16:51:36 -0000 Received: by qkhu186 with SMTP id u186so55955911qkh.0 for ; Thu, 02 Jul 2015 09:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=pKWjRt3LYwzlKjUSnJ5btTdMD5TLL3/yMvAmQJ/S3GM=; b=ZWiBIA1IEzrqrP9mSJPf0JZoIvaz5xS2PMd1GKHVPO5HVX+ZzOGqXUulF+2VoCpvdD VRANOnTGNn3w6HRkbRuwVba2/ngoBDysMnbL0oBOwS50VCE/kvawGZBhe1REZCa1LRR6 HQoRZpJUCYPJFuXuCEiv+GmxShgoadiPEU2Te6pYZ69QiIZJTyT/v7xhjY8VyUs7/784 /yKiG5SZcD0AzoXPIlylKEW6CDMe4stn2wgM0ydHPkaerul4548zFR+eB1gRxsVttrer ncf4rzkuuUaY4FJ/fridNQsu7b+e8s/OQE5mtNLfXk/ILAQfUYvLUnl+pl0VedWcHwPk vxXA== MIME-Version: 1.0 X-Received: by 10.55.23.195 with SMTP id 64mr66209153qkx.9.1435855895802; Thu, 02 Jul 2015 09:51:35 -0700 (PDT) Received: by 10.140.102.104 with HTTP; Thu, 2 Jul 2015 09:51:35 -0700 (PDT) Date: Thu, 2 Jul 2015 10:51:35 -0600 Message-ID: From: jacek burghardt To: xen-users Subject: [Xen-users] vmware horizon view free replacement X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============6522565130363724552==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============6522565130363724552== Content-Type: multipart/alternative; boundary=001a1147f1a29e3a2d0519e74010 --001a1147f1a29e3a2d0519e74010 Content-Type: text/plain; charset=UTF-8 I wonder if anyone had setup xen to replace vmware horizon view. I guess I could install number of virtual desktops and have proxy to connect rpd to each virtual desktop. --001a1147f1a29e3a2d0519e74010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I wonder if anyone had setup xen to replace vmware horizon= view. I guess I could install number of virtual desktops and have proxy to= connect rpd to each virtual desktop.=C2=A0

--001a1147f1a29e3a2d0519e74010-- --===============6522565130363724552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============6522565130363724552==-- From xen-users-bounces@lists.xen.org Thu Jul 02 17:04:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 17:04:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhuP-00040j-TM; Thu, 02 Jul 2015 17:04:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhuO-00040Y-FN for xen-users@lists.xen.org; Thu, 02 Jul 2015 17:04:20 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 4C/DA-13047-31F65955; Thu, 02 Jul 2015 17:04:19 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1435856657!27784428!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 2 Jul 2015 17:04:18 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2015 17:04:18 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t62H4GLF016985 for ; Thu, 2 Jul 2015 12:04:16 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t62H4GuG024964 for ; Thu, 2 Jul 2015 12:04:16 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 2 Jul 2015 12:04:09 -0500 Message-ID: <559560F8.7070001@ti.com> Date: Thu, 2 Jul 2015 12:04:08 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------070606010509080600030809" X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------070606010509080600030809 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello All, I'm experiencing some issues with booting a DomU Linux kernel on a DRA72 chip. I am able to successfully create the VM, but whenever I run xl console to connect to the DomU, there is no output from the console, and I cannot input anything either. Whenever I do an xl list, it shows the domain as blocked, so it is starting up to a certain degree. Running xenctx on the domain, I see that the PC value is pointing to a function in the kernel called cpu_v7_do_idle() (arch/arm/mm/proc-v7.S ). I've read different threads on issues similar to this on the email list, like: [1] http://www.gossamer-threads.com/lists/xen/users/376894 [2] http://xen.1045712.n5.nabble.com/Trying-to-create-new-domain-on-4-3-but-domU-is-starting-crashed-sc-td5717826.html From [1], I applied the patch ([0]) that uses xen_raw_printk() to try to print directly to the console. From [2], I added in the guest console logging described at http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs. CONFIG_DEBUG_LL is not enabled in my kernel configuration. A little information about my setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 - Xen Tools: - Compiled from same source as Xen, no local changes to the tools. My guest filesystem is an image on the SD card, and is mounted with a loop setup. It contains the minimal Ubuntu 14.04 core filesystem, with the extra configuration files to enable the HVC console. I've attached several files. I've attached my configuration file for domU, the guest lines from xl dmesg, and the guest log in /var/log/xen/xl-domU.log. The main question I have is how do I debug my domU kernel? I need a good way to access the printk's coming from the kernel to figure out what is going on. Thanks, Brandon Perez --------------070606010509080600030809 Content-Type: text/plain; charset="UTF-8"; name="domU.cfg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="domU.cfg" a2VybmVsID0gIi9yb290L3pJbWFnZSIKbWVtb3J5ID0gMTI4Cm5hbWUgPSAiZG9tVSIKdmNw dXMgPSAxCmRpc2sgPSBbJ3BoeTovZGV2L2xvb3AwLHh2ZGEsdyddCmV4dHJhID0gImNvbnNv bGU9aHZjMCByb290PS9kZXYveHZkYSBydyBkZWJ1ZyBlYXJseXByaW50az14ZW5ib290IGlu aXQ9L2Jpbi9zaCIK --------------070606010509080600030809 Content-Type: text/x-log; name="guest_dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="guest_dmesg.log" (d1) 6xen:grant_table: Grant tables using version 1 layout (d1) Grant table initialized (d1) 6xen:events: Using FIFO-based ABI (d1) 6Xen: initializing cpu0 (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 --------------070606010509080600030809 Content-Type: text/plain; charset="UTF-8"; name="xl-domU.log.8" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xl-domU.log.8" V2FpdGluZyBmb3IgZG9tYWluIGRvbVUgKGRvbWlkIDYpIHRvIGRpZSBbcGlkIDMwMjNdCmxp YnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo2MDA6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0 ZXI6IHdhdGNoIHc9MHgzZmVjNCB3cGF0aD1AcmVsZWFzZURvbWFpbiB0b2tlbj0zLzA6IHJl Z2lzdGVyIHNsb3RudW09MwpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NTM3OndhdGNo ZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHgzZmVjNCB3cGF0aD1AcmVsZWFzZURvbWFpbiB0b2tl bj0zLzA6IGV2ZW50IGVwYXRoPUByZWxlYXNlRG9tYWluCmxpYnhsOiBkZWJ1ZzogbGlieGwu YzoxMTk5OmRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiBbZXZnPTB4M2U2Zjg6Nl0g bmVudHJpZXM9MSByYz0xIDYuLjYKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyMTA6ZG9tYWlu X2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6IFtldmc9MHgzZTZmODo2XSAgIGdvdD1kb21haW5p bmZvc1swXSBnb3QtPmRvbWFpbj02CmxpYnhsOiBkZWJ1ZzogbGlieGwuYzoxMjM3OmRvbWFp bl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiAgZXhpc3RzIHNodXRkb3duX3JlcG9ydGVkPTAg ZG9taW5mLmZsYWdzPWZmZmYwMDAwCmxpYnhsOiBkZWJ1ZzogbGlieGwuYzoxMjAzOmRvbWFp bl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiBbZXZnPTBdIGFsbCByZXBvcnRlZApsaWJ4bDog ZGVidWc6IGxpYnhsLmM6MTI2Njpkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogZG9t YWluIGRlYXRoIHNlYXJjaCBkb25lCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1Mzc6 d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDNmZWM0IHdwYXRoPUByZWxlYXNlRG9tYWlu IHRva2VuPTMvMDogZXZlbnQgZXBhdGg9QHJlbGVhc2VEb21haW4KbGlieGw6IGRlYnVnOiBs aWJ4bC5jOjExOTk6ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6IFtldmc9MHgzZTZm ODo2XSBuZW50cmllcz0xIHJjPTEgNi4uNgpsaWJ4bDogZGVidWc6IGxpYnhsLmM6MTIxMDpk b21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogW2V2Zz0weDNlNmY4OjZdICAgZ290PWRv bWFpbmluZm9zWzBdIGdvdC0+ZG9tYWluPTYKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyMzc6 ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6ICBleGlzdHMgc2h1dGRvd25fcmVwb3J0 ZWQ9MCBkb21pbmYuZmxhZ3M9ZmZmZjAwMTkKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjExNTU6 ZG9tYWluX2RlYXRoX29jY3VycmVkOiBkeWluZwpsaWJ4bDogZGVidWc6IGxpYnhsLmM6MTIw Mzpkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogW2V2Zz0wXSBhbGwgcmVwb3J0ZWQK bGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyNjY6ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJh Y2s6IGRvbWFpbiBkZWF0aCBzZWFyY2ggZG9uZQpEb21haW4gNiBoYXMgYmVlbiBkZXN0cm95 ZWQuCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo2Mzg6bGlieGxfX2V2X3hzd2F0Y2hf ZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDNmZWM0IHdwYXRoPUByZWxlYXNlRG9tYWluIHRva2Vu PTMvMDogZGVyZWdpc3RlciBzbG90bnVtPTMKeGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVy OiB0b3RhbCBhbGxvY2F0aW9uczo0IHRvdGFsIHJlbGVhc2VzOjQKeGM6IGRlYnVnOiBoeXBl cmNhbGwgYnVmZmVyOiBjdXJyZW50IGFsbG9jYXRpb25zOjAgbWF4aW11bSBhbGxvY2F0aW9u czoyCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjogY2FjaGUgY3VycmVudCBzaXplOjIK eGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiBjYWNoZSBoaXRzOjIgbWlzc2VzOjIgdG9v YmlnOjAK --------------070606010509080600030809 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------070606010509080600030809-- From xen-users-bounces@lists.xen.org Thu Jul 02 17:04:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 02 Jul 2015 17:04:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhuP-00040j-TM; Thu, 02 Jul 2015 17:04:21 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAhuO-00040Y-FN for xen-users@lists.xen.org; Thu, 02 Jul 2015 17:04:20 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 4C/DA-13047-31F65955; Thu, 02 Jul 2015 17:04:19 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1435856657!27784428!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20726 invoked from network); 2 Jul 2015 17:04:18 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-4.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2015 17:04:18 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t62H4GLF016985 for ; Thu, 2 Jul 2015 12:04:16 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t62H4GuG024964 for ; Thu, 2 Jul 2015 12:04:16 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 2 Jul 2015 12:04:09 -0500 Message-ID: <559560F8.7070001@ti.com> Date: Thu, 2 Jul 2015 12:04:08 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------070606010509080600030809" X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------070606010509080600030809 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello All, I'm experiencing some issues with booting a DomU Linux kernel on a DRA72 chip. I am able to successfully create the VM, but whenever I run xl console to connect to the DomU, there is no output from the console, and I cannot input anything either. Whenever I do an xl list, it shows the domain as blocked, so it is starting up to a certain degree. Running xenctx on the domain, I see that the PC value is pointing to a function in the kernel called cpu_v7_do_idle() (arch/arm/mm/proc-v7.S ). I've read different threads on issues similar to this on the email list, like: [1] http://www.gossamer-threads.com/lists/xen/users/376894 [2] http://xen.1045712.n5.nabble.com/Trying-to-create-new-domain-on-4-3-but-domU-is-starting-crashed-sc-td5717826.html From [1], I applied the patch ([0]) that uses xen_raw_printk() to try to print directly to the console. From [2], I added in the guest console logging described at http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen#Guest_console_logs. CONFIG_DEBUG_LL is not enabled in my kernel configuration. A little information about my setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 - Xen Tools: - Compiled from same source as Xen, no local changes to the tools. My guest filesystem is an image on the SD card, and is mounted with a loop setup. It contains the minimal Ubuntu 14.04 core filesystem, with the extra configuration files to enable the HVC console. I've attached several files. I've attached my configuration file for domU, the guest lines from xl dmesg, and the guest log in /var/log/xen/xl-domU.log. The main question I have is how do I debug my domU kernel? I need a good way to access the printk's coming from the kernel to figure out what is going on. Thanks, Brandon Perez --------------070606010509080600030809 Content-Type: text/plain; charset="UTF-8"; name="domU.cfg" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="domU.cfg" a2VybmVsID0gIi9yb290L3pJbWFnZSIKbWVtb3J5ID0gMTI4Cm5hbWUgPSAiZG9tVSIKdmNw dXMgPSAxCmRpc2sgPSBbJ3BoeTovZGV2L2xvb3AwLHh2ZGEsdyddCmV4dHJhID0gImNvbnNv bGU9aHZjMCByb290PS9kZXYveHZkYSBydyBkZWJ1ZyBlYXJseXByaW50az14ZW5ib290IGlu aXQ9L2Jpbi9zaCIK --------------070606010509080600030809 Content-Type: text/x-log; name="guest_dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="guest_dmesg.log" (d1) 6xen:grant_table: Grant tables using version 1 layout (d1) Grant table initialized (d1) 6xen:events: Using FIFO-based ABI (d1) 6Xen: initializing cpu0 (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 --------------070606010509080600030809 Content-Type: text/plain; charset="UTF-8"; name="xl-domU.log.8" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xl-domU.log.8" V2FpdGluZyBmb3IgZG9tYWluIGRvbVUgKGRvbWlkIDYpIHRvIGRpZSBbcGlkIDMwMjNdCmxp YnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo2MDA6bGlieGxfX2V2X3hzd2F0Y2hfcmVnaXN0 ZXI6IHdhdGNoIHc9MHgzZmVjNCB3cGF0aD1AcmVsZWFzZURvbWFpbiB0b2tlbj0zLzA6IHJl Z2lzdGVyIHNsb3RudW09MwpsaWJ4bDogZGVidWc6IGxpYnhsX2V2ZW50LmM6NTM3OndhdGNo ZmRfY2FsbGJhY2s6IHdhdGNoIHc9MHgzZmVjNCB3cGF0aD1AcmVsZWFzZURvbWFpbiB0b2tl bj0zLzA6IGV2ZW50IGVwYXRoPUByZWxlYXNlRG9tYWluCmxpYnhsOiBkZWJ1ZzogbGlieGwu YzoxMTk5OmRvbWFpbl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiBbZXZnPTB4M2U2Zjg6Nl0g bmVudHJpZXM9MSByYz0xIDYuLjYKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyMTA6ZG9tYWlu X2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6IFtldmc9MHgzZTZmODo2XSAgIGdvdD1kb21haW5p bmZvc1swXSBnb3QtPmRvbWFpbj02CmxpYnhsOiBkZWJ1ZzogbGlieGwuYzoxMjM3OmRvbWFp bl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiAgZXhpc3RzIHNodXRkb3duX3JlcG9ydGVkPTAg ZG9taW5mLmZsYWdzPWZmZmYwMDAwCmxpYnhsOiBkZWJ1ZzogbGlieGwuYzoxMjAzOmRvbWFp bl9kZWF0aF94c3dhdGNoX2NhbGxiYWNrOiBbZXZnPTBdIGFsbCByZXBvcnRlZApsaWJ4bDog ZGVidWc6IGxpYnhsLmM6MTI2Njpkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogZG9t YWluIGRlYXRoIHNlYXJjaCBkb25lCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo1Mzc6 d2F0Y2hmZF9jYWxsYmFjazogd2F0Y2ggdz0weDNmZWM0IHdwYXRoPUByZWxlYXNlRG9tYWlu IHRva2VuPTMvMDogZXZlbnQgZXBhdGg9QHJlbGVhc2VEb21haW4KbGlieGw6IGRlYnVnOiBs aWJ4bC5jOjExOTk6ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6IFtldmc9MHgzZTZm ODo2XSBuZW50cmllcz0xIHJjPTEgNi4uNgpsaWJ4bDogZGVidWc6IGxpYnhsLmM6MTIxMDpk b21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogW2V2Zz0weDNlNmY4OjZdICAgZ290PWRv bWFpbmluZm9zWzBdIGdvdC0+ZG9tYWluPTYKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyMzc6 ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJhY2s6ICBleGlzdHMgc2h1dGRvd25fcmVwb3J0 ZWQ9MCBkb21pbmYuZmxhZ3M9ZmZmZjAwMTkKbGlieGw6IGRlYnVnOiBsaWJ4bC5jOjExNTU6 ZG9tYWluX2RlYXRoX29jY3VycmVkOiBkeWluZwpsaWJ4bDogZGVidWc6IGxpYnhsLmM6MTIw Mzpkb21haW5fZGVhdGhfeHN3YXRjaF9jYWxsYmFjazogW2V2Zz0wXSBhbGwgcmVwb3J0ZWQK bGlieGw6IGRlYnVnOiBsaWJ4bC5jOjEyNjY6ZG9tYWluX2RlYXRoX3hzd2F0Y2hfY2FsbGJh Y2s6IGRvbWFpbiBkZWF0aCBzZWFyY2ggZG9uZQpEb21haW4gNiBoYXMgYmVlbiBkZXN0cm95 ZWQuCmxpYnhsOiBkZWJ1ZzogbGlieGxfZXZlbnQuYzo2Mzg6bGlieGxfX2V2X3hzd2F0Y2hf ZGVyZWdpc3Rlcjogd2F0Y2ggdz0weDNmZWM0IHdwYXRoPUByZWxlYXNlRG9tYWluIHRva2Vu PTMvMDogZGVyZWdpc3RlciBzbG90bnVtPTMKeGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVy OiB0b3RhbCBhbGxvY2F0aW9uczo0IHRvdGFsIHJlbGVhc2VzOjQKeGM6IGRlYnVnOiBoeXBl cmNhbGwgYnVmZmVyOiBjdXJyZW50IGFsbG9jYXRpb25zOjAgbWF4aW11bSBhbGxvY2F0aW9u czoyCnhjOiBkZWJ1ZzogaHlwZXJjYWxsIGJ1ZmZlcjogY2FjaGUgY3VycmVudCBzaXplOjIK eGM6IGRlYnVnOiBoeXBlcmNhbGwgYnVmZmVyOiBjYWNoZSBoaXRzOjIgbWlzc2VzOjIgdG9v YmlnOjAK --------------070606010509080600030809 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------070606010509080600030809-- From xen-users-bounces@lists.xen.org Fri Jul 03 09:01:43 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 09:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAwpt-0001M3-J1; Fri, 03 Jul 2015 09:00:41 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAwps-0001Ly-9f for xen-users@lists.xen.org; Fri, 03 Jul 2015 09:00:40 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 23/40-01469-73F46955; Fri, 03 Jul 2015 09:00:39 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1435914037!28941267!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8655 invoked from network); 3 Jul 2015 09:00:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 09:00:38 -0000 X-IronPort-AV: E=Sophos;i="5.15,399,1432598400"; d="scan'208";a="280932464" Message-ID: <1435914034.9447.23.camel@citrix.com> From: Ian Campbell To: Epiontis IT Date: Fri, 3 Jul 2015 10:00:34 +0100 In-Reply-To: <559545C7.3010600@epiontis.com> References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> <559545C7.3010600@epiontis.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-02 at 16:08 +0200, Epiontis IT wrote: > On 07/01/2015 04:30 PM, Ian Campbell wrote: > > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: > >> Hello, > >> > >> I'm new to XEN live migration. I have a question regarding XEN memory > >> management while doing a vm live migration. I observed that migrating a > >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target > >> machine to have memory available that is the size of the memory > >> allocated to the vm (2G). Since I follow "XEN best practices" and set > >> dom0_mem to 512M the target machine begins swapping out 2G to disk which > >> makes everything nearly unresponsive. Is this requirement for the dom0 > >> memory size intended or might there be an issue with my setup? > > I don't think you should need 2G dom0 memory, you should need 2G of free > > host memory. > > > > Perhaps something on your destination host is thinking it wants to > > balloon dom0 down in order to make that free host memory available? > > > > Ian. > I looked further into the issue. When I start a migration with "xl > migrate " the destination machine sets up a vm > "--incoming" and seems to sync memory because "xl list" shows "Mem" > for the incoming vm going up stepwise until 2048. After that though the > vm doesn't get launched. The vm is frozen for about a minute, the dom0 > begins swapping out the 2GB to disk (because it only has 512M available > for itself) and a process > > /usr/lib/xen-4.5/bin/libxl-save-helper --restore-domain > > takes about 90% of the dom0 memory. After that the vm ist launched, > memory consumption goes back to normal, swap space is freed. This sounds like a bug to me. Perhaps a memory leak in the helper or something with similar symptoms like leaking foreign mappings. It might be interesting to look at the pmap of the save helper process while this is going on, since it should show some huge mapping and whether it is associated with help or privcmd (foreign) mappings etc. Armed with that information I think it would be appropriate to report as a bug to the development list, see http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen > Is this some kind of cold migration process? Is there some option I'm > missing that does real live migration? xl migrate is always live and AFAIK always has been. Bery recent versions accept a --live option for compatibility with the old xend/xm command, but it does nothing, because the migration is already live. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 09:01:43 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 09:01:43 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAwpt-0001M3-J1; Fri, 03 Jul 2015 09:00:41 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAwps-0001Ly-9f for xen-users@lists.xen.org; Fri, 03 Jul 2015 09:00:40 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 23/40-01469-73F46955; Fri, 03 Jul 2015 09:00:39 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1435914037!28941267!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8655 invoked from network); 3 Jul 2015 09:00:38 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 09:00:38 -0000 X-IronPort-AV: E=Sophos;i="5.15,399,1432598400"; d="scan'208";a="280932464" Message-ID: <1435914034.9447.23.camel@citrix.com> From: Ian Campbell To: Epiontis IT Date: Fri, 3 Jul 2015 10:00:34 +0100 In-Reply-To: <559545C7.3010600@epiontis.com> References: <5593F71D.3020107@epiontis.com> <1435761032.21469.292.camel@citrix.com> <559545C7.3010600@epiontis.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Xen live migration dom0 memory X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-02 at 16:08 +0200, Epiontis IT wrote: > On 07/01/2015 04:30 PM, Ian Campbell wrote: > > On Wed, 2015-07-01 at 16:20 +0200, Epiontis IT wrote: > >> Hello, > >> > >> I'm new to XEN live migration. I have a question regarding XEN memory > >> management while doing a vm live migration. I observed that migrating a > >> vm on XEN 4.5.1 and Linux Kernel 4.1.0 requires the dom0 on the target > >> machine to have memory available that is the size of the memory > >> allocated to the vm (2G). Since I follow "XEN best practices" and set > >> dom0_mem to 512M the target machine begins swapping out 2G to disk which > >> makes everything nearly unresponsive. Is this requirement for the dom0 > >> memory size intended or might there be an issue with my setup? > > I don't think you should need 2G dom0 memory, you should need 2G of free > > host memory. > > > > Perhaps something on your destination host is thinking it wants to > > balloon dom0 down in order to make that free host memory available? > > > > Ian. > I looked further into the issue. When I start a migration with "xl > migrate " the destination machine sets up a vm > "--incoming" and seems to sync memory because "xl list" shows "Mem" > for the incoming vm going up stepwise until 2048. After that though the > vm doesn't get launched. The vm is frozen for about a minute, the dom0 > begins swapping out the 2GB to disk (because it only has 512M available > for itself) and a process > > /usr/lib/xen-4.5/bin/libxl-save-helper --restore-domain > > takes about 90% of the dom0 memory. After that the vm ist launched, > memory consumption goes back to normal, swap space is freed. This sounds like a bug to me. Perhaps a memory leak in the helper or something with similar symptoms like leaking foreign mappings. It might be interesting to look at the pmap of the save helper process while this is going on, since it should show some huge mapping and whether it is associated with help or privcmd (foreign) mappings etc. Armed with that information I think it would be appropriate to report as a bug to the development list, see http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen > Is this some kind of cold migration process? Is there some option I'm > missing that does real live migration? xl migrate is always live and AFAIK always has been. Bery recent versions accept a --live option for compatibility with the old xend/xm command, but it does nothing, because the migration is already live. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 10:33:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 10:33:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAyGH-0005z1-GC; Fri, 03 Jul 2015 10:32:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAyGG-0005yq-0q for xen-users@lists.xen.org; Fri, 03 Jul 2015 10:32:00 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 7A/80-23096-F9466955; Fri, 03 Jul 2015 10:31:59 +0000 X-Env-Sender: prvs=6190ec9e4=julien.grall@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1435919516!13418629!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2420 invoked from network); 3 Jul 2015 10:31:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 10:31:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,399,1432598400"; d="scan'208";a="277939346" Message-ID: <5596645D.7030401@citrix.com> Date: Fri, 3 Jul 2015 11:30:53 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , References: <559560F8.7070001@ti.com> In-Reply-To: <559560F8.7070001@ti.com> X-DLP: MIA1 Subject: Re: [Xen-users] [Xen-Users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 02/07/15 17:04, Brandon Perez wrote: > > (d1) 6xen:grant_table: Grant tables using version 1 layout > (d1) Grant table initialized > (d1) 6xen:events: Using FIFO-based ABI > (d1) 6Xen: initializing cpu0 > (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 It's hard to know what's going on with only these 5 lines. Is it the full log of the domU? If not, can you send it? Usually, the next step is to bring up the other processor, although you have only 1 vCPU in the device tree. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 10:33:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 10:33:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAyGH-0005z1-GC; Fri, 03 Jul 2015 10:32:01 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZAyGG-0005yq-0q for xen-users@lists.xen.org; Fri, 03 Jul 2015 10:32:00 +0000 Received: from [85.158.139.211] by server-7.bemta-5.messagelabs.com id 7A/80-23096-F9466955; Fri, 03 Jul 2015 10:31:59 +0000 X-Env-Sender: prvs=6190ec9e4=julien.grall@citrix.com X-Msg-Ref: server-10.tower-206.messagelabs.com!1435919516!13418629!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2420 invoked from network); 3 Jul 2015 10:31:57 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-10.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 10:31:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,399,1432598400"; d="scan'208";a="277939346" Message-ID: <5596645D.7030401@citrix.com> Date: Fri, 3 Jul 2015 11:30:53 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , References: <559560F8.7070001@ti.com> In-Reply-To: <559560F8.7070001@ti.com> X-DLP: MIA1 Subject: Re: [Xen-users] [Xen-Users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 02/07/15 17:04, Brandon Perez wrote: > > (d1) 6xen:grant_table: Grant tables using version 1 layout > (d1) Grant table initialized > (d1) 6xen:events: Using FIFO-based ABI > (d1) 6Xen: initializing cpu0 > (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 It's hard to know what's going on with only these 5 lines. Is it the full log of the domU? If not, can you send it? Usually, the next step is to bring up the other processor, although you have only 1 vCPU in the device tree. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 13:52:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 13:52:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1NY-0005ck-QB; Fri, 03 Jul 2015 13:51:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1NW-0005cd-V2 for xen-users@lists.xen.org; Fri, 03 Jul 2015 13:51:43 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 55/18-25881-E6396955; Fri, 03 Jul 2015 13:51:42 +0000 X-Env-Sender: alejokalderon@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1435931499!18742651!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4841 invoked from network); 3 Jul 2015 13:51:40 -0000 Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 13:51:40 -0000 Received: by ykdv136 with SMTP id v136so96325063ykd.0 for ; Fri, 03 Jul 2015 06:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gVXrZPtrNBN2KPxmyJdhtUFkov+iH80vi2T+3WYBxCo=; b=czUgkP1K1RAwBtGqf++AetioNsAaS1Lykfg4gdfdWz8Bfg918D+2nk+sIw+Ks32fyM 9PrADhkpT5jOOUfggDlrSNejUbyaRgwCj+1WjZMfVvLqXhpawXGlJDSIseBi3T5hypVs Glbk7OVY85pdrZba8J9RXBtaH+QzZJu1iUYZM7oKrJo5S2u7u4k8oezdv+zLW6hfu/OS CZSDxI5Nibi0EAZenj1+3B1YpV+XjiTs1pCTg7CBYjmrMcWXGV41HCF8FizuzMLa+9yL nSfBy9+FTqF3LCeSRMixFh62IwGfssNdQ6+xeWLQXclWIf5xsNiBdro0UOcWJB2XHbrS kI9w== MIME-Version: 1.0 X-Received: by 10.170.118.80 with SMTP id k77mr44324259ykb.64.1435931499576; Fri, 03 Jul 2015 06:51:39 -0700 (PDT) Received: by 10.37.101.215 with HTTP; Fri, 3 Jul 2015 06:51:39 -0700 (PDT) Date: Fri, 3 Jul 2015 08:51:39 -0500 Message-ID: From: =?UTF-8?Q?Alejandro_Calder=C3=B3n?= To: xen-users@lists.xen.org Subject: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9019864254130849894==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9019864254130849894== Content-Type: multipart/alternative; boundary=001a1138ea3cf445f80519f8daac --001a1138ea3cf445f80519f8daac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everyone. I would like to greet because I'm new in the list, I have little time working with XEN server and it worked fine for me, but after an unexpected shutdown of my server my VM cannot start again, when I try to run the following command: "xe vm-start uuid =3D edc7bf9c-4751-01cd-11th-a23ae15d7da2 --force" The server gives me the following response. "There are no suitable hosts to start esta VM on. The following table Provides per-host Reasons for why the VM Could not be started: xenserver: Can not start here [VM requires access to SR: 55ebfacc-2ccc-7d4d-18ad-a2aeb2038039 (Local storage)] There Were no hosts available to complete the specified operation." This is a big trouble for me, and I don't know how to repair this. Sorry for my bad English, and many thanks for your attention. Regards! --=20 --- ----- Cordialmente *Alejandro Calder=C3=B3nAdministrador De Redes I**nform=C3=A1ticas* *gnunick* [image: skype] [image: Blogger] [image: facebook] [image: twitter] [image: linkedIn] [image: Google+] Please do not send me Microsoft Office/Apple iWork Documents. Send OpenDocument instead! Por favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice. [image: eco] No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a los datos personales, y s= e dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le ruego que me lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. --001a1138ea3cf445f80519f8daac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone.

I would like to greet because I'= ;m new in the list, I have little time working with XEN server and it worke= d fine for me, but after an unexpected shutdown of my server my VM cannot s= tart again, when I try to run the following command:

"xe vm-sta= rt uuid =3D edc7bf9c-4751-01cd-11th-a23ae15d7da2 --force"

The s= erver gives me the following response.

"There are no suitable h= osts to start esta VM on.
The following table Provides per-host Reasons = for why the VM Could not be started:

xenserver: Can not start here [= VM requires access to SR: 55ebfacc-2ccc-7d4d-18ad-a2aeb2038039 (Local stora= ge)]


There Were no hosts available to complete the specified ope= ration."

This is a big trouble for me, and I don't know how= to repair this.

Sorry for my bad English, and many thanks for your = attention.

Regards!

--
---

-----

C= ordialmente

=C2=A0

Alejandro Calder= =C3=B3n
Administrador De Redes Inform=C3=A1ticas
gnunic= k
= =C2=A0
= =C2=A03D"skype"=C2=A03D"Blogger"=C2=A03D"facebook"=C2=A03D"twitter"=C2=A03D"linkedIn"=C2=A0=C2=A0=C2=A03D"Google+"=C2=A0=C2=A0

Please do not send me Microsoft Office/Appl= e iWork Documents. Send OpenDocument instead!

Por favor no me env=C3=ADes docum= entos de Microsoft Office o de iWork, env=C3=ADame documentos en formatos a= biertos como los de OpenOffice.

3D"eco"=C2=A0No me imprimas si no es necesario. Protejamos el medio ambiente.<= /span>

Este mens= aje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3= =B3n, especialmente en lo que respecta a los datos personales, y se dirigen= exclusivamente al destinatario referenciado. Si usted no lo es y lo ha rec= ibido por error o tiene conocimiento del mismo por cualquier motivo, le rue= go que me lo comunique por este medio y proceda a destruirlo o borrarlo, y = que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o c= omunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo p= ena de incurrir en responsabilidades legales. El emisor no garantiza la int= egridad, rapidez o seguridad del presente correo, ni se responsabiliza de p= osibles perjuicios derivados de la captura, incorporaciones de virus o cual= esquiera otras manipulaciones efectuadas por terceros.

--001a1138ea3cf445f80519f8daac-- --===============9019864254130849894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9019864254130849894==-- From xen-users-bounces@lists.xen.org Fri Jul 03 13:52:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 13:52:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1NY-0005ck-QB; Fri, 03 Jul 2015 13:51:44 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1NW-0005cd-V2 for xen-users@lists.xen.org; Fri, 03 Jul 2015 13:51:43 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id 55/18-25881-E6396955; Fri, 03 Jul 2015 13:51:42 +0000 X-Env-Sender: alejokalderon@gmail.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1435931499!18742651!1 X-Originating-IP: [209.85.160.173] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_50_60,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4841 invoked from network); 3 Jul 2015 13:51:40 -0000 Received: from mail-yk0-f173.google.com (HELO mail-yk0-f173.google.com) (209.85.160.173) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 13:51:40 -0000 Received: by ykdv136 with SMTP id v136so96325063ykd.0 for ; Fri, 03 Jul 2015 06:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gVXrZPtrNBN2KPxmyJdhtUFkov+iH80vi2T+3WYBxCo=; b=czUgkP1K1RAwBtGqf++AetioNsAaS1Lykfg4gdfdWz8Bfg918D+2nk+sIw+Ks32fyM 9PrADhkpT5jOOUfggDlrSNejUbyaRgwCj+1WjZMfVvLqXhpawXGlJDSIseBi3T5hypVs Glbk7OVY85pdrZba8J9RXBtaH+QzZJu1iUYZM7oKrJo5S2u7u4k8oezdv+zLW6hfu/OS CZSDxI5Nibi0EAZenj1+3B1YpV+XjiTs1pCTg7CBYjmrMcWXGV41HCF8FizuzMLa+9yL nSfBy9+FTqF3LCeSRMixFh62IwGfssNdQ6+xeWLQXclWIf5xsNiBdro0UOcWJB2XHbrS kI9w== MIME-Version: 1.0 X-Received: by 10.170.118.80 with SMTP id k77mr44324259ykb.64.1435931499576; Fri, 03 Jul 2015 06:51:39 -0700 (PDT) Received: by 10.37.101.215 with HTTP; Fri, 3 Jul 2015 06:51:39 -0700 (PDT) Date: Fri, 3 Jul 2015 08:51:39 -0500 Message-ID: From: =?UTF-8?Q?Alejandro_Calder=C3=B3n?= To: xen-users@lists.xen.org Subject: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9019864254130849894==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9019864254130849894== Content-Type: multipart/alternative; boundary=001a1138ea3cf445f80519f8daac --001a1138ea3cf445f80519f8daac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello everyone. I would like to greet because I'm new in the list, I have little time working with XEN server and it worked fine for me, but after an unexpected shutdown of my server my VM cannot start again, when I try to run the following command: "xe vm-start uuid =3D edc7bf9c-4751-01cd-11th-a23ae15d7da2 --force" The server gives me the following response. "There are no suitable hosts to start esta VM on. The following table Provides per-host Reasons for why the VM Could not be started: xenserver: Can not start here [VM requires access to SR: 55ebfacc-2ccc-7d4d-18ad-a2aeb2038039 (Local storage)] There Were no hosts available to complete the specified operation." This is a big trouble for me, and I don't know how to repair this. Sorry for my bad English, and many thanks for your attention. Regards! --=20 --- ----- Cordialmente *Alejandro Calder=C3=B3nAdministrador De Redes I**nform=C3=A1ticas* *gnunick* [image: skype] [image: Blogger] [image: facebook] [image: twitter] [image: linkedIn] [image: Google+] Please do not send me Microsoft Office/Apple iWork Documents. Send OpenDocument instead! Por favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice. [image: eco] No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a los datos personales, y s= e dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le ruego que me lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. --001a1138ea3cf445f80519f8daac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello everyone.

I would like to greet because I'= ;m new in the list, I have little time working with XEN server and it worke= d fine for me, but after an unexpected shutdown of my server my VM cannot s= tart again, when I try to run the following command:

"xe vm-sta= rt uuid =3D edc7bf9c-4751-01cd-11th-a23ae15d7da2 --force"

The s= erver gives me the following response.

"There are no suitable h= osts to start esta VM on.
The following table Provides per-host Reasons = for why the VM Could not be started:

xenserver: Can not start here [= VM requires access to SR: 55ebfacc-2ccc-7d4d-18ad-a2aeb2038039 (Local stora= ge)]


There Were no hosts available to complete the specified ope= ration."

This is a big trouble for me, and I don't know how= to repair this.

Sorry for my bad English, and many thanks for your = attention.

Regards!

--
---

-----

C= ordialmente

=C2=A0

Alejandro Calder= =C3=B3n
Administrador De Redes Inform=C3=A1ticas
gnunic= k
= =C2=A0
= =C2=A03D"skype"=C2=A03D"Blogger"=C2=A03D"facebook"=C2=A03D"twitter"=C2=A03D"linkedIn"=C2=A0=C2=A0=C2=A03D"Google+"=C2=A0=C2=A0

Please do not send me Microsoft Office/Appl= e iWork Documents. Send OpenDocument instead!

Por favor no me env=C3=ADes docum= entos de Microsoft Office o de iWork, env=C3=ADame documentos en formatos a= biertos como los de OpenOffice.

3D"eco"=C2=A0No me imprimas si no es necesario. Protejamos el medio ambiente.<= /span>

Este mens= aje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3= =B3n, especialmente en lo que respecta a los datos personales, y se dirigen= exclusivamente al destinatario referenciado. Si usted no lo es y lo ha rec= ibido por error o tiene conocimiento del mismo por cualquier motivo, le rue= go que me lo comunique por este medio y proceda a destruirlo o borrarlo, y = que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o c= omunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo p= ena de incurrir en responsabilidades legales. El emisor no garantiza la int= egridad, rapidez o seguridad del presente correo, ni se responsabiliza de p= osibles perjuicios derivados de la captura, incorporaciones de virus o cual= esquiera otras manipulaciones efectuadas por terceros.

--001a1138ea3cf445f80519f8daac-- --===============9019864254130849894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9019864254130849894==-- From xen-users-bounces@lists.xen.org Fri Jul 03 14:01:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:01:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1Wd-0007Sm-23; Fri, 03 Jul 2015 14:01:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1Wb-0007SJ-Ac for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:01:05 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id D6/24-10437-0A596955; Fri, 03 Jul 2015 14:01:04 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435932062!22438325!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22163 invoked from network); 3 Jul 2015 14:01:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:01:04 -0000 X-IronPort-AV: E=Sophos;i="5.15,400,1432598400"; d="scan'208";a="280989136" Message-ID: <1435932060.9447.115.camel@citrix.com> From: Ian Campbell To: Alejandro =?ISO-8859-1?Q?Calder=F3n?= Date: Fri, 3 Jul 2015 15:01:00 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gRnJpLCAyMDE1LTA3LTAzIGF0IDA4OjUxIC0wNTAwLCBBbGVqYW5kcm8gQ2FsZGVyw7NuIHdy b3RlOgoKSGVsbG8gQWxlamFuZHJvLAoKCj4gSSB3b3VsZCBsaWtlIHRvIGdyZWV0IGJlY2F1c2Ug SSdtIG5ldyBpbiB0aGUgbGlzdCwgSSBoYXZlIGxpdHRsZSB0aW1lCj4gd29ya2luZyB3aXRoIFhF TiBzZXJ2ZXIKClRoaXMgbGlzdCBpcyBwcmltYXJpbHkgZm9yIHVzZXJzIG9mIHRoZSB0b29sc3Rh Y2tzIHNoaXBwZWQgd2l0aCB0aGUgWGVuClByb2plY3QgcmVsZWFzZXMgb2YgWGVuLgoKWGVuU2Vy dmVyIGlzIGEgc2VwYXJhdGUgcHJvamVjdHMgd2l0aCBpdHMgb3duIGxpc3RzIGFuZCBmb3J1bXMg b3ZlciBhdAp3d3cueGVuc2VydmVyLm9yZywgSSB3b3VsZCBzdWdnZXN0IHlvdSBhc2sgWGVuU2Vy dmVyIHJlbGF0ZWQgcXVlc3Rpb25zCm92ZXIgdGhlcmUuCgpUaGFua3MsCklhbi4KCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxp bmcgbGlzdApYZW4tdXNlcnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t dXNlcnM= From xen-users-bounces@lists.xen.org Fri Jul 03 14:01:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:01:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1Wd-0007Sm-23; Fri, 03 Jul 2015 14:01:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1Wb-0007SJ-Ac for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:01:05 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id D6/24-10437-0A596955; Fri, 03 Jul 2015 14:01:04 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1435932062!22438325!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22163 invoked from network); 3 Jul 2015 14:01:04 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:01:04 -0000 X-IronPort-AV: E=Sophos;i="5.15,400,1432598400"; d="scan'208";a="280989136" Message-ID: <1435932060.9447.115.camel@citrix.com> From: Ian Campbell To: Alejandro =?ISO-8859-1?Q?Calder=F3n?= Date: Fri, 3 Jul 2015 15:01:00 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gRnJpLCAyMDE1LTA3LTAzIGF0IDA4OjUxIC0wNTAwLCBBbGVqYW5kcm8gQ2FsZGVyw7NuIHdy b3RlOgoKSGVsbG8gQWxlamFuZHJvLAoKCj4gSSB3b3VsZCBsaWtlIHRvIGdyZWV0IGJlY2F1c2Ug SSdtIG5ldyBpbiB0aGUgbGlzdCwgSSBoYXZlIGxpdHRsZSB0aW1lCj4gd29ya2luZyB3aXRoIFhF TiBzZXJ2ZXIKClRoaXMgbGlzdCBpcyBwcmltYXJpbHkgZm9yIHVzZXJzIG9mIHRoZSB0b29sc3Rh Y2tzIHNoaXBwZWQgd2l0aCB0aGUgWGVuClByb2plY3QgcmVsZWFzZXMgb2YgWGVuLgoKWGVuU2Vy dmVyIGlzIGEgc2VwYXJhdGUgcHJvamVjdHMgd2l0aCBpdHMgb3duIGxpc3RzIGFuZCBmb3J1bXMg b3ZlciBhdAp3d3cueGVuc2VydmVyLm9yZywgSSB3b3VsZCBzdWdnZXN0IHlvdSBhc2sgWGVuU2Vy dmVyIHJlbGF0ZWQgcXVlc3Rpb25zCm92ZXIgdGhlcmUuCgpUaGFua3MsCklhbi4KCgoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxp bmcgbGlzdApYZW4tdXNlcnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4t dXNlcnM= From xen-users-bounces@lists.xen.org Fri Jul 03 14:09:09 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1eC-0008T9-TM; Fri, 03 Jul 2015 14:08:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1eB-0008Sx-OT for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:08:55 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 97/C2-27764-77796955; Fri, 03 Jul 2015 14:08:55 +0000 X-Env-Sender: alejokalderon@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1435932524!29039449!1 X-Originating-IP: [209.85.160.174] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20079 invoked from network); 3 Jul 2015 14:08:45 -0000 Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:08:45 -0000 Received: by ykfy125 with SMTP id y125so96699355ykf.1 for ; Fri, 03 Jul 2015 07:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dt5uJPX/aZpW3ihuzFDz/pmCg/rz+IQY5Pa/sz2cT7I=; b=M3M4qMt0PQOaLG9NX97sBpwkymgRRKWLGJRdWs0/kLsFPjcSLRukcgHInBkqSTlj9P sksl5pMxEBGfpYXpLIBB/Naix8k+miNeiEAoydiEF4qEB0W3Lx2KhHvIbphdD9XJHP38 QgC3UNlZvnjCwAfsUIQUvn2TUk9/LU9fMdnBXh8CPPnY/6kxgC4UFkmULxZwZ4bO1c0e tv2oD9GQ3WFd6SQyjU7dKJBAaTiPrZ1Tt7C5iHJtpqSnWq3s+a0Flizf5vm0n0wac2cZ H/FpLkgOIOwN2KusoPJ3mDPE80aTuKlr+u+1psFRoofXEuZIKaYgFLfPMrIjI0EeXyTU Uosg== MIME-Version: 1.0 X-Received: by 10.170.75.194 with SMTP id r185mr44572672ykr.69.1435932524316; Fri, 03 Jul 2015 07:08:44 -0700 (PDT) Received: by 10.37.101.215 with HTTP; Fri, 3 Jul 2015 07:08:44 -0700 (PDT) In-Reply-To: <1435932060.9447.115.camel@citrix.com> References: <1435932060.9447.115.camel@citrix.com> Date: Fri, 3 Jul 2015 09:08:44 -0500 Message-ID: From: =?UTF-8?Q?Alejandro_Calder=C3=B3n?= To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4402433160689321440==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4402433160689321440== Content-Type: multipart/alternative; boundary=001a1139bbe20890590519f918ff --001a1139bbe20890590519f918ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Ian, I'm goiing to contact him. Regars! 2015-07-03 9:01 GMT-05:00 Ian Campbell : > On Fri, 2015-07-03 at 08:51 -0500, Alejandro Calder=C3=B3n wrote: > > Hello Alejandro, > > > > I would like to greet because I'm new in the list, I have little time > > working with XEN server > > This list is primarily for users of the toolstacks shipped with the Xen > Project releases of Xen. > > XenServer is a separate projects with its own lists and forums over at > www.xenserver.org, I would suggest you ask XenServer related questions > over there. > > Thanks, > Ian. > > > --=20 --- ----- Cordialmente *Alejandro Calder=C3=B3nAdministrador De Redes I**nform=C3=A1ticas* *gnunick* [image: skype] [image: Blogger] [image: facebook] [image: twitter] [image: linkedIn] [image: Google+] Please do not send me Microsoft Office/Apple iWork Documents. Send OpenDocument instead! Por favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice. [image: eco] No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a los datos personales, y s= e dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le ruego que me lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. --001a1139bbe20890590519f918ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Ian, I'm goiing to contact him.

Regars!

2015-07-03 9:01 GMT-05:00 Ian Campbell <ian.campbell@citrix.com>:
On Fri, 2015-07-03 at 08:5= 1 -0500, Alejandro Calder=C3=B3n wrote:

Hello Alejandro,


> I would like to greet because I'm new in the list, I have little t= ime
> working with XEN server

This list is primarily for users of the toolstacks shipped with the = Xen
Project releases of Xen.

XenServer is a separate projects with its own lists and forums over at
w= ww.xenserver.org, I would suggest you ask XenServer related questions over there.

Thanks,
Ian.





--
---

-= ----

Cord= ialmente

= =C2=A0

=
Alejandro Calder=C3=B3n
Administrador De Redes I= nform=C3=A1ticas
gnunick		=C2=A0
=C2=A03D"skype"=C2=A03D"Blogger"=C2=A03D"faceboo==C2=A0=C2=A03D"linkedIn"= =C2=A0=C2=A0=C2=A03D"Google+"=C2=A0=C2=A0

Please do = not send me Microsoft Office/Apple iWork Documents. Send OpenDocument inste= ad!

P= or favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice.

3D"eco"=C2=A0No me imprimas si no es necesar= io. Protejamos el medio ambiente.

Este mensaje y, en su caso, los ficheros anexos so= n propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a = los datos personales, y se dirigen exclusivamente al destinatario referenci= ado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del = mismo por cualquier motivo, le ruego que me lo comunique por este medio y p= roceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar,= reproducir, alterar, archivar o comunicar a terceros el presente mensaje y= ficheros anexos, todo ello bajo pena de incurrir en responsabilidades lega= les. El emisor no garantiza la integridad, rapidez o seguridad del presente= correo, ni se responsabiliza de posibles perjuicios derivados de la captur= a, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas = por terceros.

--001a1139bbe20890590519f918ff-- --===============4402433160689321440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4402433160689321440==-- From xen-users-bounces@lists.xen.org Fri Jul 03 14:09:09 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:09:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1eC-0008T9-TM; Fri, 03 Jul 2015 14:08:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB1eB-0008Sx-OT for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:08:55 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 97/C2-27764-77796955; Fri, 03 Jul 2015 14:08:55 +0000 X-Env-Sender: alejokalderon@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1435932524!29039449!1 X-Originating-IP: [209.85.160.174] X-SpamReason: No, hits=0.6 required=7.0 tests=HTML_60_70,HTML_MESSAGE, ML_RADAR_SPEW_LINKS_8,RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20079 invoked from network); 3 Jul 2015 14:08:45 -0000 Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:08:45 -0000 Received: by ykfy125 with SMTP id y125so96699355ykf.1 for ; Fri, 03 Jul 2015 07:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dt5uJPX/aZpW3ihuzFDz/pmCg/rz+IQY5Pa/sz2cT7I=; b=M3M4qMt0PQOaLG9NX97sBpwkymgRRKWLGJRdWs0/kLsFPjcSLRukcgHInBkqSTlj9P sksl5pMxEBGfpYXpLIBB/Naix8k+miNeiEAoydiEF4qEB0W3Lx2KhHvIbphdD9XJHP38 QgC3UNlZvnjCwAfsUIQUvn2TUk9/LU9fMdnBXh8CPPnY/6kxgC4UFkmULxZwZ4bO1c0e tv2oD9GQ3WFd6SQyjU7dKJBAaTiPrZ1Tt7C5iHJtpqSnWq3s+a0Flizf5vm0n0wac2cZ H/FpLkgOIOwN2KusoPJ3mDPE80aTuKlr+u+1psFRoofXEuZIKaYgFLfPMrIjI0EeXyTU Uosg== MIME-Version: 1.0 X-Received: by 10.170.75.194 with SMTP id r185mr44572672ykr.69.1435932524316; Fri, 03 Jul 2015 07:08:44 -0700 (PDT) Received: by 10.37.101.215 with HTTP; Fri, 3 Jul 2015 07:08:44 -0700 (PDT) In-Reply-To: <1435932060.9447.115.camel@citrix.com> References: <1435932060.9447.115.camel@citrix.com> Date: Fri, 3 Jul 2015 09:08:44 -0500 Message-ID: From: =?UTF-8?Q?Alejandro_Calder=C3=B3n?= To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Help XENServer Cannot start here VM requires access to SR X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4402433160689321440==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4402433160689321440== Content-Type: multipart/alternative; boundary=001a1139bbe20890590519f918ff --001a1139bbe20890590519f918ff Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Ian, I'm goiing to contact him. Regars! 2015-07-03 9:01 GMT-05:00 Ian Campbell : > On Fri, 2015-07-03 at 08:51 -0500, Alejandro Calder=C3=B3n wrote: > > Hello Alejandro, > > > > I would like to greet because I'm new in the list, I have little time > > working with XEN server > > This list is primarily for users of the toolstacks shipped with the Xen > Project releases of Xen. > > XenServer is a separate projects with its own lists and forums over at > www.xenserver.org, I would suggest you ask XenServer related questions > over there. > > Thanks, > Ian. > > > --=20 --- ----- Cordialmente *Alejandro Calder=C3=B3nAdministrador De Redes I**nform=C3=A1ticas* *gnunick* [image: skype] [image: Blogger] [image: facebook] [image: twitter] [image: linkedIn] [image: Google+] Please do not send me Microsoft Office/Apple iWork Documents. Send OpenDocument instead! Por favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice. [image: eco] No me imprimas si no es necesario. Protejamos el medio ambiente. Este mensaje y, en su caso, los ficheros anexos son propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a los datos personales, y s= e dirigen exclusivamente al destinatario referenciado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le ruego que me lo comunique por este medio y proceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje y ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. --001a1139bbe20890590519f918ff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Ian, I'm goiing to contact him.

Regars!

2015-07-03 9:01 GMT-05:00 Ian Campbell <ian.campbell@citrix.com>:
On Fri, 2015-07-03 at 08:5= 1 -0500, Alejandro Calder=C3=B3n wrote:

Hello Alejandro,


> I would like to greet because I'm new in the list, I have little t= ime
> working with XEN server

This list is primarily for users of the toolstacks shipped with the = Xen
Project releases of Xen.

XenServer is a separate projects with its own lists and forums over at
w= ww.xenserver.org, I would suggest you ask XenServer related questions over there.

Thanks,
Ian.





--
---

-= ----

Cord= ialmente

= =C2=A0

=
Alejandro Calder=C3=B3n
Administrador De Redes I= nform=C3=A1ticas
gnunick		=C2=A0
=C2=A03D"skype"=C2=A03D"Blogger"=C2=A03D"faceboo==C2=A0=C2=A03D"linkedIn"= =C2=A0=C2=A0=C2=A03D"Google+"=C2=A0=C2=A0

Please do = not send me Microsoft Office/Apple iWork Documents. Send OpenDocument inste= ad!

P= or favor no me env=C3=ADes documentos de Microsoft Office o de iWork, env= =C3=ADame documentos en formatos abiertos como los de OpenOffice.

3D"eco"=C2=A0No me imprimas si no es necesar= io. Protejamos el medio ambiente.

Este mensaje y, en su caso, los ficheros anexos so= n propiedad de Alejandro Calder=C3=B3n, especialmente en lo que respecta a = los datos personales, y se dirigen exclusivamente al destinatario referenci= ado. Si usted no lo es y lo ha recibido por error o tiene conocimiento del = mismo por cualquier motivo, le ruego que me lo comunique por este medio y p= roceda a destruirlo o borrarlo, y que en todo caso se abstenga de utilizar,= reproducir, alterar, archivar o comunicar a terceros el presente mensaje y= ficheros anexos, todo ello bajo pena de incurrir en responsabilidades lega= les. El emisor no garantiza la integridad, rapidez o seguridad del presente= correo, ni se responsabiliza de posibles perjuicios derivados de la captur= a, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas = por terceros.

--001a1139bbe20890590519f918ff-- --===============4402433160689321440== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4402433160689321440==-- From xen-users-bounces@lists.xen.org Fri Jul 03 14:52:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Jl-0004ie-Sa; Fri, 03 Jul 2015 14:51:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Jk-0004iQ-Fw for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:51:52 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id AA/25-13047-781A6955; Fri, 03 Jul 2015 14:51:51 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1435935110!22932252!1 X-Originating-IP: [209.85.220.46] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26441 invoked from network); 3 Jul 2015 14:51:51 -0000 Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:51:51 -0000 Received: by paceq1 with SMTP id eq1so58439140pac.3 for ; Fri, 03 Jul 2015 07:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7OovfOLwCqa/JiDP6TEGBKrNZ6g/KR0uFzbIYMuM7aA=; b=A17PzC+yqwCY9RgTJbFABlsRYKiket0ty68YBR/CUtjI9FuKM6X39ioqatNvWgNLAQ DlfcDYRYKm22vmR6DRMKK5jg68IE7oYgzAItLqF0/Gw36SfdnTSO3TiFaXJ46Dej+Qed f6g0NE4UmlBupXyxW4Nn0yF30iKQF26MEvCnawB5V2Cxms6Qv1+k5UPg4I1/3Cp07b6E /WlvRIEdvUep/EKSfLYfzoYZgroc78BRJzhGwr+WkUnSl/hktOSUWaQYJiJk9PV78QsK 9evaexv0qzuxIQNl82+43sHKInZT3qoBN9Pqwbp+TeCdvXcNjs5HRaLIu8VTPE8xBH7F RlHA== X-Received: by 10.70.137.39 with SMTP id qf7mr20389139pdb.39.1435935109773; Fri, 03 Jul 2015 07:51:49 -0700 (PDT) Received: from [192.168.0.11] ([203.153.68.91]) by mx.google.com with ESMTPSA id r4sm9382593pap.8.2015.07.03.07.51.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jul 2015 07:51:49 -0700 (PDT) Message-ID: <5596A18C.6040203@gmail.com> Date: Fri, 03 Jul 2015 23:51:56 +0900 From: LJA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users Subject: [Xen-users] Error occur when starting xencommons daemon.(Compiled xen) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello. I'm using gentoo linux. I build xen from source. version is 4.5.2. Compile, install-xen and install-tools are end without any error. But, When I type /etc/init.d/xencommons start, This error message is displayed. Starting xenconsoled... Starting QEMU as disk backend for dom0 /etc/init.d/xencommons: line 55: 26712 Illegal instruction $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile $QEMU_PIDFILE I tried old version of xen's qemu-system-i386 with replace new installed file. /usr/local/lib64/xen/bin/qemu-system-i386 But same. How can I solve this problem? Thank you for reading. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 14:52:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 14:52:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Jl-0004ie-Sa; Fri, 03 Jul 2015 14:51:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Jk-0004iQ-Fw for xen-users@lists.xen.org; Fri, 03 Jul 2015 14:51:52 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id AA/25-13047-781A6955; Fri, 03 Jul 2015 14:51:51 +0000 X-Env-Sender: getchus1@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1435935110!22932252!1 X-Originating-IP: [209.85.220.46] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26441 invoked from network); 3 Jul 2015 14:51:51 -0000 Received: from mail-pa0-f46.google.com (HELO mail-pa0-f46.google.com) (209.85.220.46) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 14:51:51 -0000 Received: by paceq1 with SMTP id eq1so58439140pac.3 for ; Fri, 03 Jul 2015 07:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=7OovfOLwCqa/JiDP6TEGBKrNZ6g/KR0uFzbIYMuM7aA=; b=A17PzC+yqwCY9RgTJbFABlsRYKiket0ty68YBR/CUtjI9FuKM6X39ioqatNvWgNLAQ DlfcDYRYKm22vmR6DRMKK5jg68IE7oYgzAItLqF0/Gw36SfdnTSO3TiFaXJ46Dej+Qed f6g0NE4UmlBupXyxW4Nn0yF30iKQF26MEvCnawB5V2Cxms6Qv1+k5UPg4I1/3Cp07b6E /WlvRIEdvUep/EKSfLYfzoYZgroc78BRJzhGwr+WkUnSl/hktOSUWaQYJiJk9PV78QsK 9evaexv0qzuxIQNl82+43sHKInZT3qoBN9Pqwbp+TeCdvXcNjs5HRaLIu8VTPE8xBH7F RlHA== X-Received: by 10.70.137.39 with SMTP id qf7mr20389139pdb.39.1435935109773; Fri, 03 Jul 2015 07:51:49 -0700 (PDT) Received: from [192.168.0.11] ([203.153.68.91]) by mx.google.com with ESMTPSA id r4sm9382593pap.8.2015.07.03.07.51.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Jul 2015 07:51:49 -0700 (PDT) Message-ID: <5596A18C.6040203@gmail.com> Date: Fri, 03 Jul 2015 23:51:56 +0900 From: LJA User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users Subject: [Xen-users] Error occur when starting xencommons daemon.(Compiled xen) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello. I'm using gentoo linux. I build xen from source. version is 4.5.2. Compile, install-xen and install-tools are end without any error. But, When I type /etc/init.d/xencommons start, This error message is displayed. Starting xenconsoled... Starting QEMU as disk backend for dom0 /etc/init.d/xencommons: line 55: 26712 Illegal instruction $QEMU_XEN -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile $QEMU_PIDFILE I tried old version of xen's qemu-system-i386 with replace new installed file. /usr/local/lib64/xen/bin/qemu-system-i386 But same. How can I solve this problem? Thank you for reading. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 15:08:13 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 15:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2ZB-0006CC-T8; Fri, 03 Jul 2015 15:07:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Z9-0006C7-RK for xen-users@lists.xen.org; Fri, 03 Jul 2015 15:07:47 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 37/A1-03035-345A6955; Fri, 03 Jul 2015 15:07:47 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1435936065!22443776!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 476 invoked from network); 3 Jul 2015 15:07:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 15:07:46 -0000 X-IronPort-AV: E=Sophos;i="5.15,400,1432598400"; d="scan'208";a="277994204" Message-ID: <1435936026.9447.150.camel@citrix.com> From: Ian Campbell To: LJA Date: Fri, 3 Jul 2015 16:07:06 +0100 In-Reply-To: <5596A18C.6040203@gmail.com> References: <5596A18C.6040203@gmail.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Error occur when starting xencommons daemon.(Compiled xen) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-03 at 23:51 +0900, LJA wrote: > /etc/init.d/xencommons: line 55: 26712 Illegal instruction $QEMU_XEN If your qemu binary includes an Illegal instruction then there is most likely something wrong with your toolchain (i.e. compiler) or the options which you are passing to it (i.e. you have asked to target a newer processor than you actually have). In the first instance I'd suggest running this past the gentoo side of things, since it doesn't seem likely to be a Xen/qemu issue at first glance... > I tried old version of xen's qemu-system-i386 with replace new installed > file. > /usr/local/lib64/xen/bin/qemu-system-i386 > > But same. This older version previously worked? That doesn't really change my opinion above, but it might suggest an underlying library was where the issue had manifested itself and not the qemu binary itself. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 15:08:13 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 15:08:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2ZB-0006CC-T8; Fri, 03 Jul 2015 15:07:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB2Z9-0006C7-RK for xen-users@lists.xen.org; Fri, 03 Jul 2015 15:07:47 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 37/A1-03035-345A6955; Fri, 03 Jul 2015 15:07:47 +0000 X-Env-Sender: prvs=6194caab5=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1435936065!22443776!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 476 invoked from network); 3 Jul 2015 15:07:46 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 15:07:46 -0000 X-IronPort-AV: E=Sophos;i="5.15,400,1432598400"; d="scan'208";a="277994204" Message-ID: <1435936026.9447.150.camel@citrix.com> From: Ian Campbell To: LJA Date: Fri, 3 Jul 2015 16:07:06 +0100 In-Reply-To: <5596A18C.6040203@gmail.com> References: <5596A18C.6040203@gmail.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Error occur when starting xencommons daemon.(Compiled xen) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-03 at 23:51 +0900, LJA wrote: > /etc/init.d/xencommons: line 55: 26712 Illegal instruction $QEMU_XEN If your qemu binary includes an Illegal instruction then there is most likely something wrong with your toolchain (i.e. compiler) or the options which you are passing to it (i.e. you have asked to target a newer processor than you actually have). In the first instance I'd suggest running this past the gentoo side of things, since it doesn't seem likely to be a Xen/qemu issue at first glance... > I tried old version of xen's qemu-system-i386 with replace new installed > file. > /usr/local/lib64/xen/bin/qemu-system-i386 > > But same. This older version previously worked? That doesn't really change my opinion above, but it might suggest an underlying library was where the issue had manifested itself and not the qemu binary itself. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 22:45:12 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 22:45:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB9ge-0007Ek-0c; Fri, 03 Jul 2015 22:44:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB9gc-0007Ef-5T for Xen-users@lists.xen.org; Fri, 03 Jul 2015 22:43:58 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id A3/E8-18947-D2017955; Fri, 03 Jul 2015 22:43:57 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1435963435!29136274!1 X-Originating-IP: [98.138.91.56] X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9621 invoked from network); 3 Jul 2015 22:43:56 -0000 Received: from nm19-vm1.bullet.mail.ne1.yahoo.com (HELO nm19-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.56) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 22:43:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435963434; bh=OS3cZKUQv9fRJdMV4MakG+BbiZdtepB8S1v0KHj7PlU=; h=Date:From:Reply-To:To:Subject:From:Subject; b=dx+HsgbNLGibRVaWRokTX9UVbbzqIKUQoPIgOkRLnHvK4HtMezs0FJsIviTXCD+0Gz52pFZYtJlcK9DvpDVl8lp1PtazNvbNXqCusclwfyDDSeYPkL7vvMeSpm8f2wcmA9+0oFmPejttw2NuIwqf3WqapixLy/PpUv4VEwxE1w7q/Vd6kRRjstcT3mSTB7UsBYKP2kxccGZJ8Vpa8Z74ZpYMy4VhGmIiJZRQkj6jynMF139gDXyR70QNgKzKQKgic3P5ieiWLtqfFGrgebZsKRZAjmXhrUDIeyjbIsIBAQ9aQFctNrvLVInTZqTwzUydaBKvxsOIr+9aGKdB8W+/zg== Received: from [98.138.101.131] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 Received: from [98.138.89.163] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 686613.86350.bm@omp1019.mail.ne1.yahoo.com X-YMail-OSG: oZiEG34VM1kmdfIsRmNCJrAylqyKoA70dEJn5Cglulw1SGc_a4FDS68fb1D44u0 O9r0Ue.PaSKoGF8vG_CdfS6XhX88lrl4l.wwRIbkmauCNOc.batDlkfMCYhApeOcAT2Oq79eHzOv AyV9pe22NmHoSIb34syJ4HJb62JSpywVodN0e0CAl4n5PxYKGtSNKKIyl8qfq.xKSit5qdZFpDsZ o08IcJXwfy5BpDk0h9_LsuFWBWZxIOBwftnTWgEWUEdtnv84Uoy9L9WZYiZXrPRQ1iqobUxY4p2U 6SPLoi4UfzNaYC1NCGOX0sgHbPclI9yNjcFqXN.MMqAipvK6P28DXbamd5jV4P8o76lN.VH3Z6vy EloYlwYtvUxt2Gkdac5En1ib.z9NeCqdznrMxGZ96Cdl7Mg4wohCA2R4KqeuRthsf2i4430tFZ2w 4_K.lDQ7pgGf8CFIyPvHWHn2LryV9IpADXKVoJ1I8PFxpUmhxxv8p2C.XuUR9M9HOWYAT9X2eLfL F5RsNi5LxOoA- Received: by 98.138.101.183; Fri, 03 Jul 2015 22:43:54 +0000 Date: Fri, 3 Jul 2015 22:43:53 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 4791 Subject: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7480778789235543770==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7480778789235543770== Content-Type: multipart/alternative; boundary="----=_Part_1874608_1538328034.1435963433981" Content-Length: 4303 ------=_Part_1874608_1538328034.1435963433981 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, All: I have a fairly simple question. Before I installed Xen on my CentOS 6.6 ho= st, I'd added some configuration to the Grub configuration file (/boot/grub= /menu.lst) to allow access via the serial-console server: > default=3D0 > timeout=3D5 > splashimage=3D(hd0,0)/grub/splash.xpm.gz > serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1 > terminal --timeout=3D5 serial console > ...> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=3Dtty= 0 console=3DttyS0,115200n8 This seemed to work well until I added the stanzas to load Xen: > title CentOS (3.10.68-11.el6.centos.alt.x86_64) >=C2=A0=C2=A0=C2=A0 root (hd0,0) >=C2=A0=C2=A0=C2=A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall = guest_loglvl=3Dall >=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ...= quiet console=3Dtty0 console=3DttyS0,115200n8 >=C2=A0=C2=A0=C2=A0 module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0. How can I grant Dom0 permanent access to the serial-console port of the hos= t [hardware]? TIA,Eric PretoriousPortland, OR ------=_Part_1874608_1538328034.1435963433981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, All:

I have a fairly sim= ple question. Before I installed Xen on my CentOS 6.6 host, I'd added some = configuration to the Grub configuration file (/boot/grub/menu.lst) to allow= access via the serial-console server:

> default=3D0
> timeout=3D5
> spla= shimage=3D(hd0,0)/grub/splash.xpm.gz
> serial --unit=3D1 -= -speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1
> term= inal --timeout=3D5 serial console
> ...
> kernel /vmlinuz-2.6.32-504.= 1.3.el6.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8

This seemed to work well until= I added the stanzas to load Xen:

> title CentOS (3.10.68-11.el6.centos.alt.x86_64)
>    root (hd0,0)
>   = kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall<= br class=3D"">>    module /vmlinuz-3.10.68-11.el6.centos.= alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>    module /initramfs-3.10.68-11.el6.centos.alt.x86_6= 4.img

= Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0.

How can I grant Dom0 perma= nent access to the serial-console port of the host [hardware]?

TIA,
Eric Pretorious
Portland, OR
------=_Part_1874608_1538328034.1435963433981-- --===============7480778789235543770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7480778789235543770==-- From xen-users-bounces@lists.xen.org Fri Jul 03 22:45:12 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 22:45:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB9ge-0007Ek-0c; Fri, 03 Jul 2015 22:44:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZB9gc-0007Ef-5T for Xen-users@lists.xen.org; Fri, 03 Jul 2015 22:43:58 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id A3/E8-18947-D2017955; Fri, 03 Jul 2015 22:43:57 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1435963435!29136274!1 X-Originating-IP: [98.138.91.56] X-SpamReason: No, hits=1.0 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_50_60,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9621 invoked from network); 3 Jul 2015 22:43:56 -0000 Received: from nm19-vm1.bullet.mail.ne1.yahoo.com (HELO nm19-vm1.bullet.mail.ne1.yahoo.com) (98.138.91.56) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 22:43:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435963434; bh=OS3cZKUQv9fRJdMV4MakG+BbiZdtepB8S1v0KHj7PlU=; h=Date:From:Reply-To:To:Subject:From:Subject; b=dx+HsgbNLGibRVaWRokTX9UVbbzqIKUQoPIgOkRLnHvK4HtMezs0FJsIviTXCD+0Gz52pFZYtJlcK9DvpDVl8lp1PtazNvbNXqCusclwfyDDSeYPkL7vvMeSpm8f2wcmA9+0oFmPejttw2NuIwqf3WqapixLy/PpUv4VEwxE1w7q/Vd6kRRjstcT3mSTB7UsBYKP2kxccGZJ8Vpa8Z74ZpYMy4VhGmIiJZRQkj6jynMF139gDXyR70QNgKzKQKgic3P5ieiWLtqfFGrgebZsKRZAjmXhrUDIeyjbIsIBAQ9aQFctNrvLVInTZqTwzUydaBKvxsOIr+9aGKdB8W+/zg== Received: from [98.138.101.131] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 Received: from [98.138.89.163] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 Received: from [127.0.0.1] by omp1019.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 22:43:54 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 686613.86350.bm@omp1019.mail.ne1.yahoo.com X-YMail-OSG: oZiEG34VM1kmdfIsRmNCJrAylqyKoA70dEJn5Cglulw1SGc_a4FDS68fb1D44u0 O9r0Ue.PaSKoGF8vG_CdfS6XhX88lrl4l.wwRIbkmauCNOc.batDlkfMCYhApeOcAT2Oq79eHzOv AyV9pe22NmHoSIb34syJ4HJb62JSpywVodN0e0CAl4n5PxYKGtSNKKIyl8qfq.xKSit5qdZFpDsZ o08IcJXwfy5BpDk0h9_LsuFWBWZxIOBwftnTWgEWUEdtnv84Uoy9L9WZYiZXrPRQ1iqobUxY4p2U 6SPLoi4UfzNaYC1NCGOX0sgHbPclI9yNjcFqXN.MMqAipvK6P28DXbamd5jV4P8o76lN.VH3Z6vy EloYlwYtvUxt2Gkdac5En1ib.z9NeCqdznrMxGZ96Cdl7Mg4wohCA2R4KqeuRthsf2i4430tFZ2w 4_K.lDQ7pgGf8CFIyPvHWHn2LryV9IpADXKVoJ1I8PFxpUmhxxv8p2C.XuUR9M9HOWYAT9X2eLfL F5RsNi5LxOoA- Received: by 98.138.101.183; Fri, 03 Jul 2015 22:43:54 +0000 Date: Fri, 3 Jul 2015 22:43:53 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 4791 Subject: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7480778789235543770==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7480778789235543770== Content-Type: multipart/alternative; boundary="----=_Part_1874608_1538328034.1435963433981" Content-Length: 4303 ------=_Part_1874608_1538328034.1435963433981 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, All: I have a fairly simple question. Before I installed Xen on my CentOS 6.6 ho= st, I'd added some configuration to the Grub configuration file (/boot/grub= /menu.lst) to allow access via the serial-console server: > default=3D0 > timeout=3D5 > splashimage=3D(hd0,0)/grub/splash.xpm.gz > serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1 > terminal --timeout=3D5 serial console > ...> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=3Dtty= 0 console=3DttyS0,115200n8 This seemed to work well until I added the stanzas to load Xen: > title CentOS (3.10.68-11.el6.centos.alt.x86_64) >=C2=A0=C2=A0=C2=A0 root (hd0,0) >=C2=A0=C2=A0=C2=A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall = guest_loglvl=3Dall >=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ...= quiet console=3Dtty0 console=3DttyS0,115200n8 >=C2=A0=C2=A0=C2=A0 module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0. How can I grant Dom0 permanent access to the serial-console port of the hos= t [hardware]? TIA,Eric PretoriousPortland, OR ------=_Part_1874608_1538328034.1435963433981 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, All:

I have a fairly sim= ple question. Before I installed Xen on my CentOS 6.6 host, I'd added some = configuration to the Grub configuration file (/boot/grub/menu.lst) to allow= access via the serial-console server:

> default=3D0
> timeout=3D5
> spla= shimage=3D(hd0,0)/grub/splash.xpm.gz
> serial --unit=3D1 -= -speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1
> term= inal --timeout=3D5 serial console
> ...
> kernel /vmlinuz-2.6.32-504.= 1.3.el6.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8

This seemed to work well until= I added the stanzas to load Xen:

> title CentOS (3.10.68-11.el6.centos.alt.x86_64)
>    root (hd0,0)
>   = kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall<= br class=3D"">>    module /vmlinuz-3.10.68-11.el6.centos.= alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>    module /initramfs-3.10.68-11.el6.centos.alt.x86_6= 4.img

= Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0.

How can I grant Dom0 perma= nent access to the serial-console port of the host [hardware]?

TIA,
Eric Pretorious
Portland, OR
------=_Part_1874608_1538328034.1435963433981-- --===============7480778789235543770== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7480778789235543770==-- From xen-users-bounces@lists.xen.org Fri Jul 03 23:08:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:08:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBA3y-0008BS-1s; Fri, 03 Jul 2015 23:08:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBA3w-0008BN-MW for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:08:04 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id F6/41-21300-4D517955; Fri, 03 Jul 2015 23:08:04 +0000 X-Env-Sender: srn@prgmr.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1435964882!21538608!1 X-Originating-IP: [71.19.149.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1648 invoked from network); 3 Jul 2015 23:08:02 -0000 Received: from mail.prgmr.com (HELO mail.prgmr.com) (71.19.149.6) by server-16.tower-27.messagelabs.com with SMTP; 3 Jul 2015 23:08:02 -0000 Received: from [192.168.1.3] (173-228-60-9.dsl.dynamic.fusionbroadband.com [173.228.60.9]) (Authenticated sender: srn) by mail.prgmr.com (Postfix) with ESMTPSA id 1962F28C001; Fri, 3 Jul 2015 19:11:49 -0400 (EDT) Message-ID: <559715CF.7010805@prgmr.com> Date: Fri, 03 Jul 2015 16:07:59 -0700 From: Sarah Newman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric , "Xen-users@lists.xen.org" References: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/03/2015 03:43 PM, Eric wrote: > Hello, All: > > I have a fairly simple question. Before I installed Xen on my CentOS 6.6 host, I'd added some configuration to the Grub configuration file > (/boot/grub/menu.lst) to allow access via the serial-console server: > >> default=0 >> timeout=5 >> splashimage=(hd0,0)/grub/splash.xpm.gz >> serial --unit=1 --speed=115200 --word=8 --parity=no --stop=1 >> terminal --timeout=5 serial console >> ... >> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=tty0 console=ttyS0,115200n8 > > This seemed to work well until I added the stanzas to load Xen: > >> title CentOS (3.10.68-11.el6.centos.alt.x86_64) >> root (hd0,0) >> kernel /xen.gz dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all >> module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ... quiet console=tty0 console=ttyS0,115200n8 >> module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img > > Now I'm able to view/interact with the host's BIOS; the Grub boot menu, and; I'm able to watch the initial portion of the boot process. However, after > the xend starts I'm no longer able to view or to interact with Dom0. > > How can I grant Dom0 permanent access to the serial-console port of the host [hardware]? you probably want kernel /boot/xen.gz com1=115200,8n1 console=com1 module /boot/vmlinuz-3.10.68-11.el6.centos.alt.x86_64 console=hvc0 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 23:08:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:08:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBA3y-0008BS-1s; Fri, 03 Jul 2015 23:08:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBA3w-0008BN-MW for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:08:04 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id F6/41-21300-4D517955; Fri, 03 Jul 2015 23:08:04 +0000 X-Env-Sender: srn@prgmr.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1435964882!21538608!1 X-Originating-IP: [71.19.149.6] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1648 invoked from network); 3 Jul 2015 23:08:02 -0000 Received: from mail.prgmr.com (HELO mail.prgmr.com) (71.19.149.6) by server-16.tower-27.messagelabs.com with SMTP; 3 Jul 2015 23:08:02 -0000 Received: from [192.168.1.3] (173-228-60-9.dsl.dynamic.fusionbroadband.com [173.228.60.9]) (Authenticated sender: srn) by mail.prgmr.com (Postfix) with ESMTPSA id 1962F28C001; Fri, 3 Jul 2015 19:11:49 -0400 (EDT) Message-ID: <559715CF.7010805@prgmr.com> Date: Fri, 03 Jul 2015 16:07:59 -0700 From: Sarah Newman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Eric , "Xen-users@lists.xen.org" References: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/03/2015 03:43 PM, Eric wrote: > Hello, All: > > I have a fairly simple question. Before I installed Xen on my CentOS 6.6 host, I'd added some configuration to the Grub configuration file > (/boot/grub/menu.lst) to allow access via the serial-console server: > >> default=0 >> timeout=5 >> splashimage=(hd0,0)/grub/splash.xpm.gz >> serial --unit=1 --speed=115200 --word=8 --parity=no --stop=1 >> terminal --timeout=5 serial console >> ... >> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=tty0 console=ttyS0,115200n8 > > This seemed to work well until I added the stanzas to load Xen: > >> title CentOS (3.10.68-11.el6.centos.alt.x86_64) >> root (hd0,0) >> kernel /xen.gz dom0_mem=1024M,max:1024M loglvl=all guest_loglvl=all >> module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ... quiet console=tty0 console=ttyS0,115200n8 >> module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img > > Now I'm able to view/interact with the host's BIOS; the Grub boot menu, and; I'm able to watch the initial portion of the boot process. However, after > the xend starts I'm no longer able to view or to interact with Dom0. > > How can I grant Dom0 permanent access to the serial-console port of the host [hardware]? you probably want kernel /boot/xen.gz com1=115200,8n1 console=com1 module /boot/vmlinuz-3.10.68-11.el6.centos.alt.x86_64 console=hvc0 _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 03 23:38:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:38:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAX1-0000eB-PT; Fri, 03 Jul 2015 23:38:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAX0-0000e3-5d for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:38:06 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 82/8C-30658-DDC17955; Fri, 03 Jul 2015 23:38:05 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1435966682!29110180!1 X-Originating-IP: [98.138.91.93] X-SpamReason: No, hits=1.2 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_60_70,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19424 invoked from network); 3 Jul 2015 23:38:03 -0000 Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (HELO nm17-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.93) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 23:38:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435966682; bh=FJ6Q86zXeL1aLHT6Z9RbQXJeziZ/DUFn3gAm7e73MrA=; h=Date:From:Reply-To:To:Subject:From:Subject; b=CbKK5RcGauotyClKhpnK7itfT04iZ+Qe/NDv/xUo7NnEEGbXGeAT2F0ma/O5WnxNqsQMBshvC5RstOlx3NXlVl3hsr0a/IUh5TvZ7ydz5AGp1Te0tS6W4XnEtthidH9kF88HNZYADTkXf38PlCavSLTEWcXWeWRMPfyznCoEsKmoEc1bZ9dvE+mik4h1t7mm58ZKCMvPq0AYQyIZQ7J4OQUGB6nCmFMzCZCLHr8Zi/FwN4sq2C+j1BlYH96Q9ExoqCNIh5nEHrW+8GGPYQ71OyTY3fNxDnVaTDOkj+5pNtF8NPXGbr4uqG8aTTN5nYfzQqrJ2z1Mmz1WvNNaW/AyuA== Received: from [98.138.100.115] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 Received: from [98.138.89.170] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 312398.66990.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: rzP0yFMVM1kPeq3EysVl.MCyVU98URYqhL_JhGVW0geqWJzMXVpfndCJ_SCg8h8 2mp3BuL9JFdMomAT_4WRpEcywiKZYZYm3Ph9u3z340.TKXlca3cY8iwl87TLkOJUzLrpp8p5w2FD ToXEGX6pdbl0jFDT.YEbNVgbD602NRcejOO9BPM8e45q0vBxBREIrMrxB4i4nNPuiDQTgcw9q6HH AbY1_EIPzLv4B_hAoPBA3KTcaBNNT2uAbN4_UxXl.CSyHM8BYhT2jnznHo1jZNf5KvP2919dCvAT 7GFQMdLTzpJZkdyZmShYo7F4EEEF2kvVWc0f0gThgtikRVgdarCWV.RkXIEkKz4hWEsFkpo43U_h MkuNOv0uK_TTlMC9KDcT3pBqAwyBH.Dio00vhnZQN0DO7UCFpGk8Lw2SVkMBbfSv_1PAis_6f.od xkzjBEdZjEUBX49Ogx5HBPueQLjqdGwXTIw2G2vg0dJhKNYIPtI_A1obpomU4wugTnju.Jy1u48G M2H5qIgkkFo8- Received: by 98.138.105.204; Fri, 03 Jul 2015 23:38:01 +0000 Date: Fri, 3 Jul 2015 23:38:01 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 14526 Subject: [Xen-users] Open vSwitch: Best Practices for Configuring a Bonded Interface? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2563986996574609649==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2563986996574609649== Content-Type: multipart/alternative; boundary="----=_Part_1864396_1200587234.1435966681525" Content-Length: 14037 ------=_Part_1864396_1200587234.1435966681525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, All: I've just installed OVS on my Xen host and I'm wondering if there's a recom= mended configuration for using bonded [pysical] interfaces with OVS? e.g., = My host system has six [physical] interfaces. I've combined those [physical= ] interfaces to create three bonded interfaces: 'bond0', 'bond1', and 'bond= 2'.=20 For the initial OVS implementation, I created three virtual bridges: 'EXT',= 'MGT', and 'SAN': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" Then I removed the IP address from the bonded interface 'bond2' (manually *= and* via configuration files) and connected it to the virtual bridge 'EXT': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" This works well enough but, after a reboot, the 'bond2' interface refuses = to pass any traffic to the [physical] gateway, XXX.YYY.237.1: > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > From XXX.YYY.237.65 icmp_seq=3D1 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937= ms > pipe 3 ...until I disconnect the bond (i.e., 'bond2') from the virtual switch and = re-attach it: > [root@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist add= -port EXT bond2 > > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 time=3D48.8 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2049ms > rtt min/avg/max/mdev =3D 47.650/51.073/56.724/4.033 ms =20 Should I destroy the 'bond2' interface and create the bond using OVS instea= d? Or is this configuration correct? TIA,Eric PretoriousPortland, OR REFERENCE: [root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/network-scripts/i= fcfg-{bond2,EXT} NETWORKING=3Dyes GATEWAY=3DXXX.YYY.237.1 HOSTNAME=3Dxen-2 DNS1=3D208.67.220.220 DNS2=3D208.67.222.222 ...DEVICE=3Dbond2 BOOTPROTO=3Dnone ONBOOT=3Dyes NM_CONTOLLED=3Dno USERCTL=3Dno BONDING_OPTS=3D'mode=3D1 miimon=3D100' ...DEVICE=3DEXT OVSBRIDGE=3DEXT TYPE=3Dovs DEVICETYPE=3DOVSPort IPADDR=3DXXX.YYY.237.65 NETMASK=3D255.255.255.0 BOOTPROTO=3Dstatic ONBOOT=3Dyes ------=_Part_1864396_1200587234.1435966681525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, All:

I've just installed OVS on my Xen host and I'm wondering if t= here's a recommended configuration for using bonded [pysical] interfaces wi= th OVS? e.g., My host system has six [physical] interfaces. I've combined t= hose [physical] interfaces to create three bonded interfaces: 'bond0', 'bon= d1', and 'bond2'.

For the initial OVS implementation, I created three virtual bridges: 'EXT= ', 'MGT', and 'SAN':

> [r= oot@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-4773-8bd9-582= a9ebbd01a
>     Bridge SAN
>         Port SAN
>           = ;  Interface SAN
>      = ;           type: interna= l
>     Bridge EXT
>&= nbsp;        Port EXT
>=              In= terface EXT
>       &nb= sp;         type: internal
>     Bridge MGT
>  = ;       Port MGT
> &nbs= p;           Interface MG= T
>         &= nbsp;       type: internal
>     ovs_version: "2.3.2"

<= /div>
Then I remove= d the IP address from the bonded interface 'bond2' (manually *and* via conf= iguration files) and connected it to the virtual bridge 'EXT':

> [root@xen-2 ~]# ovs-vsctl show
&= gt; 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a
>  &nbs= p;  Bridge SAN
>      &= nbsp;  Port SAN
>      =        Interface SAN
> =             &nb= sp;   type: internal
>     B= ridge EXT
>        = ; Port "bond2"
>       =       Interface "bond2"
> &n= bsp;       Port EXT
> &= nbsp;           Interface= EXT
>        &nbs= p;        type: internal
&= gt;     Bridge MGT
>   =       Port MGT
>   = ;          Interface MGT
>          &n= bsp;      type: internal
>     ovs_version: "2.3.2"
<= div class=3D"" id=3D"yui_3_16_0_1_1435963048963_16701" dir=3D"ltr">
This works well enou= gh but, after a reboot, the 'bond2' interface refuses to pass any traffic t= o the [physical] gateway, XXX.YYY.237.1:

> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
> PING XXX.Y= YY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> From XXX.= YYY.237.65 icmp_seq=3D1 Destination Host Unreachable
> Fro= m XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable
&g= t; From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable
>
> --- XXX.YYY.237.1 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss,= time 2937ms
> pipe 3

...until I disc= onnect the bond (i.e., 'bond2') from the virtual switch and re-attach it:
> [root@xen-2 ~]# ovs-vsctl del-port = EXT bond2 && ovs-vsctl --may-exist add-port EXT bond2
>
> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
> PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 m= s
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 tim= e=3D48.8 ms
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 tt= l=3D64 time=3D47.6 ms
>
> --- XXX.YYY.237= .1 ping statistics ---
> 3 packets transmitted, 3 received= , 0% packet loss, time 2049ms
> rtt min/avg/max/mdev =3D 4= 7.650/51.073/56.724/4.033 ms
Should I destroy = the 'bond2' interface and create the bond using OVS instead? Or is this con= figuration correct?

TIA,
= Eric Pretorious
Portland, OR=

REFERENCE:

[root@xen-2 ~]# cat /= etc/sysconfig/network /etc/sysconfig/network-scripts/ifcfg-{bond2,EXT}
NETWORKING=3Dyes
GATEWAY=3DXXX.YYY.237.1
HOSTNAME=3Dxen-2
DNS1=3D208.67.220.220
DN= S2=3D208.67.222.222
...
DEVICE=3Dbond2
BOOTPROTO=3Dnone
ONBOOT=3Dyes
NM_CONTOLLED=3Dno
USERCT= L=3Dno
BONDING_OPTS=3D'mode=3D1 miimon=3D100'
.= ..
DEVICE=3DE= XT
OVSBRIDGE=3DEXT
TYPE=3Dovs
DEV= ICETYPE=3DOVSPort
IPADDR=3DXXX.YYY.237.65
NETMA= SK=3D255.255.255.0
BOOTPROTO=3Dstatic
ONBOOT=3D= yes
------=_Part_1864396_1200587234.1435966681525-- --===============2563986996574609649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2563986996574609649==-- From xen-users-bounces@lists.xen.org Fri Jul 03 23:38:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:38:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAX1-0000eB-PT; Fri, 03 Jul 2015 23:38:07 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAX0-0000e3-5d for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:38:06 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 82/8C-30658-DDC17955; Fri, 03 Jul 2015 23:38:05 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1435966682!29110180!1 X-Originating-IP: [98.138.91.93] X-SpamReason: No, hits=1.2 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_60_70,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19424 invoked from network); 3 Jul 2015 23:38:03 -0000 Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (HELO nm17-vm2.bullet.mail.ne1.yahoo.com) (98.138.91.93) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 23:38:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435966682; bh=FJ6Q86zXeL1aLHT6Z9RbQXJeziZ/DUFn3gAm7e73MrA=; h=Date:From:Reply-To:To:Subject:From:Subject; b=CbKK5RcGauotyClKhpnK7itfT04iZ+Qe/NDv/xUo7NnEEGbXGeAT2F0ma/O5WnxNqsQMBshvC5RstOlx3NXlVl3hsr0a/IUh5TvZ7ydz5AGp1Te0tS6W4XnEtthidH9kF88HNZYADTkXf38PlCavSLTEWcXWeWRMPfyznCoEsKmoEc1bZ9dvE+mik4h1t7mm58ZKCMvPq0AYQyIZQ7J4OQUGB6nCmFMzCZCLHr8Zi/FwN4sq2C+j1BlYH96Q9ExoqCNIh5nEHrW+8GGPYQ71OyTY3fNxDnVaTDOkj+5pNtF8NPXGbr4uqG8aTTN5nYfzQqrJ2z1Mmz1WvNNaW/AyuA== Received: from [98.138.100.115] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 Received: from [98.138.89.170] by tm106.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 Received: from [127.0.0.1] by omp1026.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:38:02 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 312398.66990.bm@omp1026.mail.ne1.yahoo.com X-YMail-OSG: rzP0yFMVM1kPeq3EysVl.MCyVU98URYqhL_JhGVW0geqWJzMXVpfndCJ_SCg8h8 2mp3BuL9JFdMomAT_4WRpEcywiKZYZYm3Ph9u3z340.TKXlca3cY8iwl87TLkOJUzLrpp8p5w2FD ToXEGX6pdbl0jFDT.YEbNVgbD602NRcejOO9BPM8e45q0vBxBREIrMrxB4i4nNPuiDQTgcw9q6HH AbY1_EIPzLv4B_hAoPBA3KTcaBNNT2uAbN4_UxXl.CSyHM8BYhT2jnznHo1jZNf5KvP2919dCvAT 7GFQMdLTzpJZkdyZmShYo7F4EEEF2kvVWc0f0gThgtikRVgdarCWV.RkXIEkKz4hWEsFkpo43U_h MkuNOv0uK_TTlMC9KDcT3pBqAwyBH.Dio00vhnZQN0DO7UCFpGk8Lw2SVkMBbfSv_1PAis_6f.od xkzjBEdZjEUBX49Ogx5HBPueQLjqdGwXTIw2G2vg0dJhKNYIPtI_A1obpomU4wugTnju.Jy1u48G M2H5qIgkkFo8- Received: by 98.138.105.204; Fri, 03 Jul 2015 23:38:01 +0000 Date: Fri, 3 Jul 2015 23:38:01 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 14526 Subject: [Xen-users] Open vSwitch: Best Practices for Configuring a Bonded Interface? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2563986996574609649==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2563986996574609649== Content-Type: multipart/alternative; boundary="----=_Part_1864396_1200587234.1435966681525" Content-Length: 14037 ------=_Part_1864396_1200587234.1435966681525 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, All: I've just installed OVS on my Xen host and I'm wondering if there's a recom= mended configuration for using bonded [pysical] interfaces with OVS? e.g., = My host system has six [physical] interfaces. I've combined those [physical= ] interfaces to create three bonded interfaces: 'bond0', 'bond1', and 'bond= 2'.=20 For the initial OVS implementation, I created three virtual bridges: 'EXT',= 'MGT', and 'SAN': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" Then I removed the IP address from the bonded interface 'bond2' (manually *= and* via configuration files) and connected it to the virtual bridge 'EXT': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" This works well enough but, after a reboot, the 'bond2' interface refuses = to pass any traffic to the [physical] gateway, XXX.YYY.237.1: > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > From XXX.YYY.237.65 icmp_seq=3D1 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937= ms > pipe 3 ...until I disconnect the bond (i.e., 'bond2') from the virtual switch and = re-attach it: > [root@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist add= -port EXT bond2 > > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 time=3D48.8 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2049ms > rtt min/avg/max/mdev =3D 47.650/51.073/56.724/4.033 ms =20 Should I destroy the 'bond2' interface and create the bond using OVS instea= d? Or is this configuration correct? TIA,Eric PretoriousPortland, OR REFERENCE: [root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/network-scripts/i= fcfg-{bond2,EXT} NETWORKING=3Dyes GATEWAY=3DXXX.YYY.237.1 HOSTNAME=3Dxen-2 DNS1=3D208.67.220.220 DNS2=3D208.67.222.222 ...DEVICE=3Dbond2 BOOTPROTO=3Dnone ONBOOT=3Dyes NM_CONTOLLED=3Dno USERCTL=3Dno BONDING_OPTS=3D'mode=3D1 miimon=3D100' ...DEVICE=3DEXT OVSBRIDGE=3DEXT TYPE=3Dovs DEVICETYPE=3DOVSPort IPADDR=3DXXX.YYY.237.65 NETMASK=3D255.255.255.0 BOOTPROTO=3Dstatic ONBOOT=3Dyes ------=_Part_1864396_1200587234.1435966681525 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello, All:

I've just installed OVS on my Xen host and I'm wondering if t= here's a recommended configuration for using bonded [pysical] interfaces wi= th OVS? e.g., My host system has six [physical] interfaces. I've combined t= hose [physical] interfaces to create three bonded interfaces: 'bond0', 'bon= d1', and 'bond2'.

For the initial OVS implementation, I created three virtual bridges: 'EXT= ', 'MGT', and 'SAN':

> [r= oot@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-4773-8bd9-582= a9ebbd01a
>     Bridge SAN
>         Port SAN
>           = ;  Interface SAN
>      = ;           type: interna= l
>     Bridge EXT
>&= nbsp;        Port EXT
>=              In= terface EXT
>       &nb= sp;         type: internal
>     Bridge MGT
>  = ;       Port MGT
> &nbs= p;           Interface MG= T
>         &= nbsp;       type: internal
>     ovs_version: "2.3.2"

<= /div>
Then I remove= d the IP address from the bonded interface 'bond2' (manually *and* via conf= iguration files) and connected it to the virtual bridge 'EXT':

> [root@xen-2 ~]# ovs-vsctl show
&= gt; 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a
>  &nbs= p;  Bridge SAN
>      &= nbsp;  Port SAN
>      =        Interface SAN
> =             &nb= sp;   type: internal
>     B= ridge EXT
>        = ; Port "bond2"
>       =       Interface "bond2"
> &n= bsp;       Port EXT
> &= nbsp;           Interface= EXT
>        &nbs= p;        type: internal
&= gt;     Bridge MGT
>   =       Port MGT
>   = ;          Interface MGT
>          &n= bsp;      type: internal
>     ovs_version: "2.3.2"
<= div class=3D"" id=3D"yui_3_16_0_1_1435963048963_16701" dir=3D"ltr">
This works well enou= gh but, after a reboot, the 'bond2' interface refuses to pass any traffic t= o the [physical] gateway, XXX.YYY.237.1:

> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
> PING XXX.Y= YY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> From XXX.= YYY.237.65 icmp_seq=3D1 Destination Host Unreachable
> Fro= m XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable
&g= t; From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable
>
> --- XXX.YYY.237.1 ping statistics ---
> 3 packets transmitted, 0 received, +3 errors, 100% packet loss,= time 2937ms
> pipe 3

...until I disc= onnect the bond (i.e., 'bond2') from the virtual switch and re-attach it:
> [root@xen-2 ~]# ovs-vsctl del-port = EXT bond2 && ovs-vsctl --may-exist add-port EXT bond2
>
> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
> PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 m= s
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 tim= e=3D48.8 ms
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 tt= l=3D64 time=3D47.6 ms
>
> --- XXX.YYY.237= .1 ping statistics ---
> 3 packets transmitted, 3 received= , 0% packet loss, time 2049ms
> rtt min/avg/max/mdev =3D 4= 7.650/51.073/56.724/4.033 ms
Should I destroy = the 'bond2' interface and create the bond using OVS instead? Or is this con= figuration correct?

TIA,
= Eric Pretorious
Portland, OR=

REFERENCE:

[root@xen-2 ~]# cat /= etc/sysconfig/network /etc/sysconfig/network-scripts/ifcfg-{bond2,EXT}
NETWORKING=3Dyes
GATEWAY=3DXXX.YYY.237.1
HOSTNAME=3Dxen-2
DNS1=3D208.67.220.220
DN= S2=3D208.67.222.222
...
DEVICE=3Dbond2
BOOTPROTO=3Dnone
ONBOOT=3Dyes
NM_CONTOLLED=3Dno
USERCT= L=3Dno
BONDING_OPTS=3D'mode=3D1 miimon=3D100'
.= ..
DEVICE=3DE= XT
OVSBRIDGE=3DEXT
TYPE=3Dovs
DEV= ICETYPE=3DOVSPort
IPADDR=3DXXX.YYY.237.65
NETMA= SK=3D255.255.255.0
BOOTPROTO=3Dstatic
ONBOOT=3D= yes
------=_Part_1864396_1200587234.1435966681525-- --===============2563986996574609649== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2563986996574609649==-- From xen-users-bounces@lists.xen.org Fri Jul 03 23:41:52 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAab-0000ny-J7; Fri, 03 Jul 2015 23:41:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAaa-0000nt-2b for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:41:48 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id EF/26-03895-BBD17955; Fri, 03 Jul 2015 23:41:47 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1435966904!22514080!1 X-Originating-IP: [98.138.90.46] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20342 invoked from network); 3 Jul 2015 23:41:45 -0000 Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (HELO nm30-vm1.bullet.mail.ne1.yahoo.com) (98.138.90.46) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 23:41:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435966904; bh=NRpuGFEFKD//IrNOuDjqH258vVhijgML5L+cpWWNkes=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=tY6LCsd/Dc3g4qInJ85gqUIHPwteA4h5i76wL8/WH9DbN4oxpHD132XeIsHzqftu76hgT0rjxJxgANaQ0ThOkudua1cZ/zCX0Fia19fjEkbNqDi88VWbOQKSXeWY/iOGW1UwvbOocdlQYqGuWDLperA7rigybXEbvy3NTHMtlZnWu7Xkr1RkICtN1xdg5K6jpDYg4VwJUiv2VoBzdEU/E+csp+yY4Sz6+mGiun8sMaB+x5/BQ483JKjpq3ftYf0PsfIyRQA9KFhQUd1Fs9yVdynuYf21I0OncthXfQl+gOHHZeTNcZMhfsUIHdUHmjTKolPs4RstblVe4SuF/uoELQ== Received: from [98.138.226.176] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:44 -0000 Received: from [98.138.226.167] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:43 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 979598.48487.bm@omp1068.mail.ne1.yahoo.com X-YMail-OSG: _k3ehU8VM1kyhC9gRvTYQEcOeA1SJ0U_62NJi5nUmuyPdjSq4m67O2iemhqrNIK fW8pInGUeK.umXVRm_qQPqA88KiTLsRhO.TPCbF4yLqGAuZHM9tZCMABilj2XOeBI4Yg8MPQKWqv nagSW2Q2EtEVYkPCU.N7HNCO4_aspL7Vom5_yLmC_S_6RlOlRLX6CtB04P1YTYlo1JguqKdRA.qO 7pPZnjf66_K2F6UczWWxjO5lFvcWsaIagKvf6Eq.3Z9XxB2utNgorDoE2bI1INf4IANeNp9YPWaT v6.89tjE8dDC3reZiweUtgVIRfVmAIz468hORNHvTMn2u7LB4G.FMPHNExi54DGJ0JZCwavEM8za MtUgzTK0.HDvwCZJ3rvZ3w5MS6MayJJzXDMsGOM61EWotaFR_0ePCxISfkglXpXIYqu.Yu3JYeGC h7N93bXJ7Z3RoIgtKhy8U0hzE.WYk9dptk65UWDlZgHB4.BsKMobcZRSLrlOUV3gX2J8mqkEb.Yf y3ud1M5ICZ_w- Received: by 98.138.105.192; Fri, 03 Jul 2015 23:41:43 +0000 Date: Fri, 3 Jul 2015 23:41:40 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <44954633.1868556.1435966900062.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> References: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 19236 Subject: Re: [Xen-users] Open vSwitch: Best Practices for Configuring a Bonded Interface? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2600598093055376000==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2600598093055376000== Content-Type: multipart/alternative; boundary="----=_Part_1868555_1353279488.1435966900053" Content-Length: 18747 ------=_Part_1868555_1353279488.1435966900053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW: I've provided a few more details and demonstrations here: https://www= .centos.org/forums/viewtopic.php?f=3D50&t=3D53219 Thanks, again! Eric PretoriousPortland, OR =20 From: Eric To: "Xen-users@lists.xen.org" =20 Sent: Friday, July 3, 2015 4:38 PM Subject: Open vSwitch: Best Practices for Configuring a Bonded Interface? =20 Hello, All: I've just installed OVS on my Xen host and I'm wondering if there's a recom= mended configuration for using bonded [pysical] interfaces with OVS? e.g., = My host system has six [physical] interfaces. I've combined those [physical= ] interfaces to create three bonded interfaces: 'bond0', 'bond1', and 'bond= 2'.=20 For the initial OVS implementation, I created three virtual bridges: 'EXT',= 'MGT', and 'SAN': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" Then I removed the IP address from the bonded interface 'bond2' (manually *= and* via configuration files) and connected it to the virtual bridge 'EXT': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" This works well enough but, after a reboot, the 'bond2' interface refuses = to pass any traffic to the [physical] gateway, XXX.YYY.237.1: > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > From XXX.YYY.237.65 icmp_seq=3D1 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937= ms > pipe 3 ...until I disconnect the bond (i.e., 'bond2') from the virtual switch and = re-attach it: > [root@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist add= -port EXT bond2 > > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 time=3D48.8 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2049ms > rtt min/avg/max/mdev =3D 47.650/51.073/56.724/4.033 ms =20 Should I destroy the 'bond2' interface and create the bond using OVS instea= d? Or is this configuration correct? TIA,Eric PretoriousPortland, OR REFERENCE: [root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/network-scripts/i= fcfg-{bond2,EXT} NETWORKING=3Dyes GATEWAY=3DXXX.YYY.237.1 HOSTNAME=3Dxen-2 DNS1=3D208.67.220.220 DNS2=3D208.67.222.222 ...DEVICE=3Dbond2 BOOTPROTO=3Dnone ONBOOT=3Dyes NM_CONTOLLED=3Dno USERCTL=3Dno BONDING_OPTS=3D'mode=3D1 miimon=3D100' ...DEVICE=3DEXT OVSBRIDGE=3DEXT TYPE=3Dovs DEVICETYPE=3DOVSPort IPADDR=3DXXX.YYY.237.65 NETMASK=3D255.255.255.0 BOOTPROTO=3Dstatic ONBOOT=3Dyes =20 ------=_Part_1868555_1353279488.1435966900053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW: I've provided a few more details and demonstratio= ns here: https://www.centos.org/f= orums/viewtopic.php?f=3D50&t=3D53219

Thanks, again!

Eric Pretorious
Portland, OR


From: Eric <epretorious@yahoo.com>
To: "Xen-users@lists.xen.org" <Xe= n-users@lists.xen.org>
Sent:<= /span> Friday, July 3, 2015 4:38 PM
Subject: Open vSwitch: Best Practices for Configuring a B= onded Interface?

Hello, All:

I've just installed OVS on my Xen host a= nd I'm wondering if there's a recommended configuration for using bonded [p= ysical] interfaces with OVS? e.g., My host system has six [physical] interf= aces. I've combined those [physical] interfaces to create three bonded inte= rfaces: 'bond0', 'bond1', and 'bond2'.

For the initial OVS implem= entation, I created three virtual bridges: 'EXT', 'MGT', and 'SAN':
> [roo= t@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-47= 73-8bd9-582a9ebbd01a
>    = ; Bridge SAN
>     &= nbsp;   Port SAN
>   = ;          Interface SAN
>        &= nbsp;        type: internal
>     Bridge EXT
>         Port EXT
>        &n= bsp;    Interface EXT
> &= nbsp;           &nbs= p;   type: internal
>  &n= bsp;  Bridge MGT
>   &nbs= p;     Port MGT
> &n= bsp;           Interface = MGT
>      &nbs= p;          type: internal
>  &nb= sp;  ovs_version: "2.3.2"

Then I removed the IP address from the bonded interface 'bond2' (manua= lly *and* via configuration files) and connected it to the virtual bridge '= EXT':

> [root@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a
>     Bridge SAN
>&nb= sp;        Port SAN
>          &nbs= p;  Interface SAN
>   &nb= sp;            = type: internal
>     Bri= dge EXT
>      =    Port "bond2"
>   =           Interface "bond2">       &nbs= p; Port EXT
>     &n= bsp;       Interface EXT
>          &nbs= p;      type: internal
= >     Bridge MGT
>&nbs= p;        Port MGT
>           = ;  Interface MGT
>   &nbs= p;             = type: internal
<= code class=3D"yiv7388875427">>     ovs_version: "2.3= .2"

This works well enough bu= t, after a reboot, the 'bond2' interface refuses to pass any traffic to the= [physical] gateway, XXX.YYY.237.1:

> [root@xen-2 ~]# ping = -c3 XXX.YYY.237.1
> PING XXX.YYY.237.1 (XXX.Y= YY.237.1) 56(84) bytes of data.
> From XXX.YY= Y.237.65 icmp_seq=3D1 Destination Host Unreachable
> From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable
> From XXX.YYY.237.65 icmp_seq=3D3 Destination Hos= t Unreachable
>
&g= t; --- XXX.YYY.237.1 ping statistics ---
> 3 = packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937ms> pipe 3

...until I disconnect the bond (i.e., 'bond2') from the virtua= l switch and re-attach it:

> [roo= t@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist a= dd-port EXT bond2
>
> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
&g= t; PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D= 56.7 ms
> 64 bytes from XXX.YYY.237.1: icmp_s= eq=3D2 ttl=3D64 time=3D48.8 ms
> 64 bytes fro= m XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms
>
> --- XXX.YYY.237.1 ping statistic= s ---
> 3 packets transmitted, 3 received, 0%= packet loss, time 2049ms
> rtt min/avg/max/m= dev =3D 47.650/51.073/56.724/4.033 ms
Should I destroy the 'bond2' = interface and create the bond using OVS instead? Or is this configuration c= orrect?

TIA,<= /code>
Eric Pr= etorious
= Portland, OR

= REFERENCE:

[root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/net= work-scripts/ifcfg-{bond2,EXT}
NETWORKING=3Dyes<= br class=3D"yiv7388875427">GATEWAY=3DXXX.YYY.237.1
HOSTNAME=3Dxen-2
DNS1=3D208.67.220.220
DNS2=3D208.67.222.222
...
D= EVICE=3Dbond2
BOOTPROTO=3Dnone
ONBOOT=3Dyes
NM_CONTOLLED=3Dno
USERCTL=3Dno
BONDING_OPTS=3D= 'mode=3D1 miimon=3D100'
...
DEVICE=3DEXT
OVSBRIDGE=3DEXT
TYPE=3DovsDEVICETYPE=3DOVSPort
I= PADDR=3DXXX.YYY.237.65
NETMASK=3D255.255.255.0BOOTPROTO=3Dstatic
ONB= OOT=3Dyes


------=_Part_1868555_1353279488.1435966900053-- --===============2600598093055376000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2600598093055376000==-- From xen-users-bounces@lists.xen.org Fri Jul 03 23:41:52 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 03 Jul 2015 23:41:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAab-0000ny-J7; Fri, 03 Jul 2015 23:41:49 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBAaa-0000nt-2b for Xen-users@lists.xen.org; Fri, 03 Jul 2015 23:41:48 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id EF/26-03895-BBD17955; Fri, 03 Jul 2015 23:41:47 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1435966904!22514080!1 X-Originating-IP: [98.138.90.46] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20342 invoked from network); 3 Jul 2015 23:41:45 -0000 Received: from nm30-vm1.bullet.mail.ne1.yahoo.com (HELO nm30-vm1.bullet.mail.ne1.yahoo.com) (98.138.90.46) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 3 Jul 2015 23:41:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435966904; bh=NRpuGFEFKD//IrNOuDjqH258vVhijgML5L+cpWWNkes=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=tY6LCsd/Dc3g4qInJ85gqUIHPwteA4h5i76wL8/WH9DbN4oxpHD132XeIsHzqftu76hgT0rjxJxgANaQ0ThOkudua1cZ/zCX0Fia19fjEkbNqDi88VWbOQKSXeWY/iOGW1UwvbOocdlQYqGuWDLperA7rigybXEbvy3NTHMtlZnWu7Xkr1RkICtN1xdg5K6jpDYg4VwJUiv2VoBzdEU/E+csp+yY4Sz6+mGiun8sMaB+x5/BQ483JKjpq3ftYf0PsfIyRQA9KFhQUd1Fs9yVdynuYf21I0OncthXfQl+gOHHZeTNcZMhfsUIHdUHmjTKolPs4RstblVe4SuF/uoELQ== Received: from [98.138.226.176] by nm30.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:44 -0000 Received: from [98.138.226.167] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:43 -0000 Received: from [127.0.0.1] by omp1068.mail.ne1.yahoo.com with NNFMP; 03 Jul 2015 23:41:43 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 979598.48487.bm@omp1068.mail.ne1.yahoo.com X-YMail-OSG: _k3ehU8VM1kyhC9gRvTYQEcOeA1SJ0U_62NJi5nUmuyPdjSq4m67O2iemhqrNIK fW8pInGUeK.umXVRm_qQPqA88KiTLsRhO.TPCbF4yLqGAuZHM9tZCMABilj2XOeBI4Yg8MPQKWqv nagSW2Q2EtEVYkPCU.N7HNCO4_aspL7Vom5_yLmC_S_6RlOlRLX6CtB04P1YTYlo1JguqKdRA.qO 7pPZnjf66_K2F6UczWWxjO5lFvcWsaIagKvf6Eq.3Z9XxB2utNgorDoE2bI1INf4IANeNp9YPWaT v6.89tjE8dDC3reZiweUtgVIRfVmAIz468hORNHvTMn2u7LB4G.FMPHNExi54DGJ0JZCwavEM8za MtUgzTK0.HDvwCZJ3rvZ3w5MS6MayJJzXDMsGOM61EWotaFR_0ePCxISfkglXpXIYqu.Yu3JYeGC h7N93bXJ7Z3RoIgtKhy8U0hzE.WYk9dptk65UWDlZgHB4.BsKMobcZRSLrlOUV3gX2J8mqkEb.Yf y3ud1M5ICZ_w- Received: by 98.138.105.192; Fri, 03 Jul 2015 23:41:43 +0000 Date: Fri, 3 Jul 2015 23:41:40 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <44954633.1868556.1435966900062.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> References: <54138966.1864397.1435966681532.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 19236 Subject: Re: [Xen-users] Open vSwitch: Best Practices for Configuring a Bonded Interface? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2600598093055376000==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2600598093055376000== Content-Type: multipart/alternative; boundary="----=_Part_1868555_1353279488.1435966900053" Content-Length: 18747 ------=_Part_1868555_1353279488.1435966900053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable FWIW: I've provided a few more details and demonstrations here: https://www= .centos.org/forums/viewtopic.php?f=3D50&t=3D53219 Thanks, again! Eric PretoriousPortland, OR =20 From: Eric To: "Xen-users@lists.xen.org" =20 Sent: Friday, July 3, 2015 4:38 PM Subject: Open vSwitch: Best Practices for Configuring a Bonded Interface? =20 Hello, All: I've just installed OVS on my Xen host and I'm wondering if there's a recom= mended configuration for using bonded [pysical] interfaces with OVS? e.g., = My host system has six [physical] interfaces. I've combined those [physical= ] interfaces to create three bonded interfaces: 'bond0', 'bond1', and 'bond= 2'.=20 For the initial OVS implementation, I created three virtual bridges: 'EXT',= 'MGT', and 'SAN': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" Then I removed the IP address from the bonded interface 'bond2' (manually *= and* via configuration files) and connected it to the virtual bridge 'EXT': > [root@xen-2 ~]# ovs-vsctl show > 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface SAN >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface "bond2" >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface EXT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 Bridge MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Port MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I= nterface MGT >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 type: internal >=C2=A0=C2=A0=C2=A0=C2=A0 ovs_version: "2.3.2" This works well enough but, after a reboot, the 'bond2' interface refuses = to pass any traffic to the [physical] gateway, XXX.YYY.237.1: > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > From XXX.YYY.237.65 icmp_seq=3D1 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable > From XXX.YYY.237.65 icmp_seq=3D3 Destination Host Unreachable > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937= ms > pipe 3 ...until I disconnect the bond (i.e., 'bond2') from the virtual switch and = re-attach it: > [root@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist add= -port EXT bond2 > > [root@xen-2 ~]# ping -c3 XXX.YYY.237.1 > PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data. > 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D56.7 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D2 ttl=3D64 time=3D48.8 ms > 64 bytes from XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms > > --- XXX.YYY.237.1 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2049ms > rtt min/avg/max/mdev =3D 47.650/51.073/56.724/4.033 ms =20 Should I destroy the 'bond2' interface and create the bond using OVS instea= d? Or is this configuration correct? TIA,Eric PretoriousPortland, OR REFERENCE: [root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/network-scripts/i= fcfg-{bond2,EXT} NETWORKING=3Dyes GATEWAY=3DXXX.YYY.237.1 HOSTNAME=3Dxen-2 DNS1=3D208.67.220.220 DNS2=3D208.67.222.222 ...DEVICE=3Dbond2 BOOTPROTO=3Dnone ONBOOT=3Dyes NM_CONTOLLED=3Dno USERCTL=3Dno BONDING_OPTS=3D'mode=3D1 miimon=3D100' ...DEVICE=3DEXT OVSBRIDGE=3DEXT TYPE=3Dovs DEVICETYPE=3DOVSPort IPADDR=3DXXX.YYY.237.65 NETMASK=3D255.255.255.0 BOOTPROTO=3Dstatic ONBOOT=3Dyes =20 ------=_Part_1868555_1353279488.1435966900053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW: I've provided a few more details and demonstratio= ns here: https://www.centos.org/f= orums/viewtopic.php?f=3D50&t=3D53219

Thanks, again!

Eric Pretorious
Portland, OR


From: Eric <epretorious@yahoo.com>
To: "Xen-users@lists.xen.org" <Xe= n-users@lists.xen.org>
Sent:<= /span> Friday, July 3, 2015 4:38 PM
Subject: Open vSwitch: Best Practices for Configuring a B= onded Interface?

Hello, All:

I've just installed OVS on my Xen host a= nd I'm wondering if there's a recommended configuration for using bonded [p= ysical] interfaces with OVS? e.g., My host system has six [physical] interf= aces. I've combined those [physical] interfaces to create three bonded inte= rfaces: 'bond0', 'bond1', and 'bond2'.

For the initial OVS implem= entation, I created three virtual bridges: 'EXT', 'MGT', and 'SAN':
> [roo= t@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-47= 73-8bd9-582a9ebbd01a
>    = ; Bridge SAN
>     &= nbsp;   Port SAN
>   = ;          Interface SAN
>        &= nbsp;        type: internal
>     Bridge EXT
>         Port EXT
>        &n= bsp;    Interface EXT
> &= nbsp;           &nbs= p;   type: internal
>  &n= bsp;  Bridge MGT
>   &nbs= p;     Port MGT
> &n= bsp;           Interface = MGT
>      &nbs= p;          type: internal
>  &nb= sp;  ovs_version: "2.3.2"

Then I removed the IP address from the bonded interface 'bond2' (manua= lly *and* via configuration files) and connected it to the virtual bridge '= EXT':

> [root@xen-2 ~]# ovs-vsctl show
> 0dfeba4c-bcae-4773-8bd9-582a9ebbd01a
>     Bridge SAN
>&nb= sp;        Port SAN
>          &nbs= p;  Interface SAN
>   &nb= sp;            = type: internal
>     Bri= dge EXT
>      =    Port "bond2"
>   =           Interface "bond2">       &nbs= p; Port EXT
>     &n= bsp;       Interface EXT
>          &nbs= p;      type: internal
= >     Bridge MGT
>&nbs= p;        Port MGT
>           = ;  Interface MGT
>   &nbs= p;             = type: internal
<= code class=3D"yiv7388875427">>     ovs_version: "2.3= .2"

This works well enough bu= t, after a reboot, the 'bond2' interface refuses to pass any traffic to the= [physical] gateway, XXX.YYY.237.1:

> [root@xen-2 ~]# ping = -c3 XXX.YYY.237.1
> PING XXX.YYY.237.1 (XXX.Y= YY.237.1) 56(84) bytes of data.
> From XXX.YY= Y.237.65 icmp_seq=3D1 Destination Host Unreachable
> From XXX.YYY.237.65 icmp_seq=3D2 Destination Host Unreachable
> From XXX.YYY.237.65 icmp_seq=3D3 Destination Hos= t Unreachable
>
&g= t; --- XXX.YYY.237.1 ping statistics ---
> 3 = packets transmitted, 0 received, +3 errors, 100% packet loss, time 2937ms> pipe 3

...until I disconnect the bond (i.e., 'bond2') from the virtua= l switch and re-attach it:

> [roo= t@xen-2 ~]# ovs-vsctl del-port EXT bond2 && ovs-vsctl --may-exist a= dd-port EXT bond2
>
> [root@xen-2 ~]# ping -c3 XXX.YYY.237.1
&g= t; PING XXX.YYY.237.1 (XXX.YYY.237.1) 56(84) bytes of data.
> 64 bytes from XXX.YYY.237.1: icmp_seq=3D1 ttl=3D64 time=3D= 56.7 ms
> 64 bytes from XXX.YYY.237.1: icmp_s= eq=3D2 ttl=3D64 time=3D48.8 ms
> 64 bytes fro= m XXX.YYY.237.1: icmp_seq=3D3 ttl=3D64 time=3D47.6 ms
>
> --- XXX.YYY.237.1 ping statistic= s ---
> 3 packets transmitted, 3 received, 0%= packet loss, time 2049ms
> rtt min/avg/max/m= dev =3D 47.650/51.073/56.724/4.033 ms
Should I destroy the 'bond2' = interface and create the bond using OVS instead? Or is this configuration c= orrect?

TIA,<= /code>
Eric Pr= etorious
= Portland, OR

= REFERENCE:

[root@xen-2 ~]# cat /etc/sysconfig/network /etc/sysconfig/net= work-scripts/ifcfg-{bond2,EXT}
NETWORKING=3Dyes<= br class=3D"yiv7388875427">GATEWAY=3DXXX.YYY.237.1
HOSTNAME=3Dxen-2
DNS1=3D208.67.220.220
DNS2=3D208.67.222.222
...
D= EVICE=3Dbond2
BOOTPROTO=3Dnone
ONBOOT=3Dyes
NM_CONTOLLED=3Dno
USERCTL=3Dno
BONDING_OPTS=3D= 'mode=3D1 miimon=3D100'
...
DEVICE=3DEXT
OVSBRIDGE=3DEXT
TYPE=3DovsDEVICETYPE=3DOVSPort
I= PADDR=3DXXX.YYY.237.65
NETMASK=3D255.255.255.0BOOTPROTO=3Dstatic
ONB= OOT=3Dyes


------=_Part_1868555_1353279488.1435966900053-- --===============2600598093055376000== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2600598093055376000==-- From xen-users-bounces@lists.xen.org Sat Jul 04 01:51:09 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 04 Jul 2015 01:51:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBCan-0008DD-0D; Sat, 04 Jul 2015 01:50:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBCal-0008D5-Rh for Xen-users@lists.xen.org; Sat, 04 Jul 2015 01:50:08 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 15/13-29123-FCB37955; Sat, 04 Jul 2015 01:50:07 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1435974604!29136618!1 X-Originating-IP: [98.138.91.180] X-SpamReason: No, hits=1.2 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_60_70,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2817 invoked from network); 4 Jul 2015 01:50:06 -0000 Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (HELO nm20-vm4.bullet.mail.ne1.yahoo.com) (98.138.91.180) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Jul 2015 01:50:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435974604; bh=fDRGhBMX3G2Vzr9ru3hVAOvjAyATCTEf5gxC5zfKJxs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=TS2rpTbaNrZayxpOlOeTgpjXD1aGBY2hJbhM0GcKMiWFHHt1iNchE7kWl2JVTs9AzlqkI5ByBWzbVCaaRFkLoBIyFx/Y14E2qaA4Nm+pNyIxeLJTd3NTUKlaqGvx8+GpT3OGJoZz2ueCMSATWwDaPT3tvhvIBe7rum/89l0nsZK9l/v6SfcQr9FKAE5aa/1xqOkxHTXB9axrm8LmZQlsuYiswk59bk7w64eTT3cK/3b5pwKcWFzM4d/316GuGlN0vJdD7DaNqYv17xbh+hQIRh/slqc8EXQotNdNXSn671QZ1bDJMtFOpHip/I30ad1rrLuMOUivv6KHa1YOFGfvBw== Received: from [98.138.101.131] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 Received: from [98.138.89.168] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 468275.70792.bm@omp1024.mail.ne1.yahoo.com X-YMail-OSG: bWJc4JsVM1nSH.sKwy67NgS0lVBOp2CpSWWRaKjE5DbmF7ZSwmZfQqNxdCQ.DIm RzqzkhQkH0M1b2HWJIbIft5cYj7Igp_fGF_ZePccuXU2FOXkYQq0GIKiZd4Zi0AI6NI267zoXFbZ MZNL0JDnqGknTY0lYXDd1FsA1Xuk67IK0g1IiC9ul_KgJvhXHLkHwMMJ_vTyHlXOPG1Mfsex4wQy 0JGC01VCYyyredbvXVaC2x0OE4RJqJfseEiHE_r_YMpNnk1gzESjD8dyApRbcgiVualD.YIUZece HuiyaR3jq5TgIXiSlHHegEB7qB_W67Pk0gkJB9glRm_fIa8IM17rVz7gCsvzXPTHudBzIKdRsc.t X1DWwA4BFcWwvoW6ljHbPhzxFu6DWXxFROh930v00rfPA9hD7IoX00qGzKIWffdxpRGmoUhnssCY BIraS18DiMNEghh_8jOKi5_U.SVuO4go9nGsjvjMoIUeFWdt3Di9WPcM960WMJFw62pcxXTM8cCR twb6lXUi_HxA- Received: by 98.138.105.196; Sat, 04 Jul 2015 01:50:04 +0000 Date: Sat, 4 Jul 2015 01:50:03 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <97007411.1948722.1435974603686.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> References: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 8560 Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3290656954161165358==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3290656954161165358== Content-Type: multipart/alternative; boundary="----=_Part_1948721_979468337.1435974603678" Content-Length: 8073 ------=_Part_1948721_979468337.1435974603678 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interestingly enough: When rebooting the system I'm able to view the output= again [on the serial-console server] beginning with the output of the xend= init script: > Stopping xend daemon: [=C2=A0 OK=C2=A0 ] > Stopping atd: [=C2=A0 OK=C2=A0 ] > Stopping sshd: [=C2=A0 OK=C2=A0 ] > Shutting down postfix: [=C2=A0 OK=C2=A0 ] > ... Hm. Eric PretoriousPortland, OR =20 From: Eric To: "Xen-users@lists.xen.org" =20 Sent: Friday, July 3, 2015 3:43 PM Subject: Connecting Dom0 to the Host's Serial Port? =20 Hello, All: I have a fairly simple question. Before I installed Xen on my CentOS 6.6 ho= st, I'd added some configuration to the Grub configuration file (/boot/grub= /menu.lst) to allow access via the serial-console server: > default=3D0 > timeout=3D5 > splashimage=3D(hd0,0)/grub/splash.xpm.gz > serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1 > terminal --timeout=3D5 serial console > ...> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=3Dtty= 0 console=3DttyS0,115200n8 This seemed to work well until I added the stanzas to load Xen: > title CentOS (3.10.68-11.el6.centos.alt.x86_64) >=C2=A0=C2=A0=C2=A0 root (hd0,0) >=C2=A0=C2=A0=C2=A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall = guest_loglvl=3Dall >=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ...= quiet console=3Dtty0 console=3DttyS0,115200n8 >=C2=A0=C2=A0=C2=A0 module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0. How can I grant Dom0 permanent access to the serial-console port of the hos= t [hardware]? TIA,Eric PretoriousPortland, OR =20 ------=_Part_1948721_979468337.1435974603678 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interestingly enough: Whe= n rebooting the system I'm able to view the output again [on the serial-con= sole server] beginning with the output of the xend init script:

> Stopping xend daemon: [&nbs= p; OK  ]
> Stopping atd: [  OK  ]
> Stopping sshd: [  OK  ]
> Shutting do= wn postfix: [  OK  ]
> ...

Hm.

Eric Pretorious
Portland, OR

From: E= ric <epretorious@yahoo.com>
To: "Xen-users@lists.xen.org" <Xen-users@lists.xen.org> <= br> Sent: Friday, Jul= y 3, 2015 3:43 PM
Subject:= Connecting Dom0 to the Host's Serial Port?
<= div id=3D"yui_3_16_0_1_1435963048963_24667" class=3D"y_msg_container">
<= div id=3D"yiv9808632120">
Hello= , All:

I have a fairly simple question. Before I installed Xen on my= CentOS 6.6 host, I'd added some configuration to the Grub configuration fi= le (/boot/grub/menu.lst) to allow access via the serial-console server:

> default= =3D0
> timeout=3D5
> splashimage=3D(hd0,0)/grub/splash.xpm.gz
&= gt; serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1<= br class=3D"yiv9808632120">> terminal --timeout=3D5 serial console
> ...
> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_6= 4 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8

This seemed to wo= rk well until I added the stanzas to load Xen:

> title CentOS (3.10.6= 8-11.el6.centos.alt.x86_64)
>  &nbs= p; root (hd0,0)
>    kernel /x= en.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall
>    module /vmlinuz-3.10.68-11.el6.ce= ntos.alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>    module /initramfs-3.10.68-11.el= 6.centos.alt.x86_64.img

Now I'm able to vie= w/interact with the host's BIOS; the Grub boot menu, and; I'm able to watch= the initial portion of the boot process. However, after the xend starts I'= m no longer able to view or to interact with Dom0.

How can I grant Dom0 = permanent access to the serial-console port of the host [hardware]?

TIA,=
= Eric Pretorious
Portland, OR


------=_Part_1948721_979468337.1435974603678-- --===============3290656954161165358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3290656954161165358==-- From xen-users-bounces@lists.xen.org Sat Jul 04 01:51:09 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 04 Jul 2015 01:51:09 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBCan-0008DD-0D; Sat, 04 Jul 2015 01:50:09 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBCal-0008D5-Rh for Xen-users@lists.xen.org; Sat, 04 Jul 2015 01:50:08 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 15/13-29123-FCB37955; Sat, 04 Jul 2015 01:50:07 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1435974604!29136618!1 X-Originating-IP: [98.138.91.180] X-SpamReason: No, hits=1.2 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_60_70,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2817 invoked from network); 4 Jul 2015 01:50:06 -0000 Received: from nm20-vm4.bullet.mail.ne1.yahoo.com (HELO nm20-vm4.bullet.mail.ne1.yahoo.com) (98.138.91.180) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Jul 2015 01:50:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1435974604; bh=fDRGhBMX3G2Vzr9ru3hVAOvjAyATCTEf5gxC5zfKJxs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=TS2rpTbaNrZayxpOlOeTgpjXD1aGBY2hJbhM0GcKMiWFHHt1iNchE7kWl2JVTs9AzlqkI5ByBWzbVCaaRFkLoBIyFx/Y14E2qaA4Nm+pNyIxeLJTd3NTUKlaqGvx8+GpT3OGJoZz2ueCMSATWwDaPT3tvhvIBe7rum/89l0nsZK9l/v6SfcQr9FKAE5aa/1xqOkxHTXB9axrm8LmZQlsuYiswk59bk7w64eTT3cK/3b5pwKcWFzM4d/316GuGlN0vJdD7DaNqYv17xbh+hQIRh/slqc8EXQotNdNXSn671QZ1bDJMtFOpHip/I30ad1rrLuMOUivv6KHa1YOFGfvBw== Received: from [98.138.101.131] by nm20.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 Received: from [98.138.89.168] by tm19.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 Received: from [127.0.0.1] by omp1024.mail.ne1.yahoo.com with NNFMP; 04 Jul 2015 01:50:04 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 468275.70792.bm@omp1024.mail.ne1.yahoo.com X-YMail-OSG: bWJc4JsVM1nSH.sKwy67NgS0lVBOp2CpSWWRaKjE5DbmF7ZSwmZfQqNxdCQ.DIm RzqzkhQkH0M1b2HWJIbIft5cYj7Igp_fGF_ZePccuXU2FOXkYQq0GIKiZd4Zi0AI6NI267zoXFbZ MZNL0JDnqGknTY0lYXDd1FsA1Xuk67IK0g1IiC9ul_KgJvhXHLkHwMMJ_vTyHlXOPG1Mfsex4wQy 0JGC01VCYyyredbvXVaC2x0OE4RJqJfseEiHE_r_YMpNnk1gzESjD8dyApRbcgiVualD.YIUZece HuiyaR3jq5TgIXiSlHHegEB7qB_W67Pk0gkJB9glRm_fIa8IM17rVz7gCsvzXPTHudBzIKdRsc.t X1DWwA4BFcWwvoW6ljHbPhzxFu6DWXxFROh930v00rfPA9hD7IoX00qGzKIWffdxpRGmoUhnssCY BIraS18DiMNEghh_8jOKi5_U.SVuO4go9nGsjvjMoIUeFWdt3Di9WPcM960WMJFw62pcxXTM8cCR twb6lXUi_HxA- Received: by 98.138.105.196; Sat, 04 Jul 2015 01:50:04 +0000 Date: Sat, 4 Jul 2015 01:50:03 +0000 (UTC) From: Eric To: "Xen-users@lists.xen.org" Message-ID: <97007411.1948722.1435974603686.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> References: <1195262313.1874609.1435963433986.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 8560 Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Eric List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3290656954161165358==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3290656954161165358== Content-Type: multipart/alternative; boundary="----=_Part_1948721_979468337.1435974603678" Content-Length: 8073 ------=_Part_1948721_979468337.1435974603678 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Interestingly enough: When rebooting the system I'm able to view the output= again [on the serial-console server] beginning with the output of the xend= init script: > Stopping xend daemon: [=C2=A0 OK=C2=A0 ] > Stopping atd: [=C2=A0 OK=C2=A0 ] > Stopping sshd: [=C2=A0 OK=C2=A0 ] > Shutting down postfix: [=C2=A0 OK=C2=A0 ] > ... Hm. Eric PretoriousPortland, OR =20 From: Eric To: "Xen-users@lists.xen.org" =20 Sent: Friday, July 3, 2015 3:43 PM Subject: Connecting Dom0 to the Host's Serial Port? =20 Hello, All: I have a fairly simple question. Before I installed Xen on my CentOS 6.6 ho= st, I'd added some configuration to the Grub configuration file (/boot/grub= /menu.lst) to allow access via the serial-console server: > default=3D0 > timeout=3D5 > splashimage=3D(hd0,0)/grub/splash.xpm.gz > serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1 > terminal --timeout=3D5 serial console > ...> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console=3Dtty= 0 console=3DttyS0,115200n8 This seemed to work well until I added the stanzas to load Xen: > title CentOS (3.10.68-11.el6.centos.alt.x86_64) >=C2=A0=C2=A0=C2=A0 root (hd0,0) >=C2=A0=C2=A0=C2=A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall = guest_loglvl=3Dall >=C2=A0=C2=A0=C2=A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ...= quiet console=3Dtty0 console=3DttyS0,115200n8 >=C2=A0=C2=A0=C2=A0 module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img Now I'm able to view/interact with the host's BIOS; the Grub boot menu, an= d; I'm able to watch the initial portion of the boot process. However, afte= r the xend starts I'm no longer able to view or to interact with Dom0. How can I grant Dom0 permanent access to the serial-console port of the hos= t [hardware]? TIA,Eric PretoriousPortland, OR =20 ------=_Part_1948721_979468337.1435974603678 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Interestingly enough: Whe= n rebooting the system I'm able to view the output again [on the serial-con= sole server] beginning with the output of the xend init script:

> Stopping xend daemon: [&nbs= p; OK  ]
> Stopping atd: [  OK  ]
> Stopping sshd: [  OK  ]
> Shutting do= wn postfix: [  OK  ]
> ...

Hm.

Eric Pretorious
Portland, OR

From: E= ric <epretorious@yahoo.com>
To: "Xen-users@lists.xen.org" <Xen-users@lists.xen.org> <= br> Sent: Friday, Jul= y 3, 2015 3:43 PM
Subject:= Connecting Dom0 to the Host's Serial Port?
<= div id=3D"yui_3_16_0_1_1435963048963_24667" class=3D"y_msg_container">
<= div id=3D"yiv9808632120">
Hello= , All:

I have a fairly simple question. Before I installed Xen on my= CentOS 6.6 host, I'd added some configuration to the Grub configuration fi= le (/boot/grub/menu.lst) to allow access via the serial-console server:

> default= =3D0
> timeout=3D5
> splashimage=3D(hd0,0)/grub/splash.xpm.gz
&= gt; serial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1<= br class=3D"yiv9808632120">> terminal --timeout=3D5 serial console
> ...
> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_6= 4 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8

This seemed to wo= rk well until I added the stanzas to load Xen:

> title CentOS (3.10.6= 8-11.el6.centos.alt.x86_64)
>  &nbs= p; root (hd0,0)
>    kernel /x= en.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall guest_loglvl=3Dall
>    module /vmlinuz-3.10.68-11.el6.ce= ntos.alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>    module /initramfs-3.10.68-11.el= 6.centos.alt.x86_64.img

Now I'm able to vie= w/interact with the host's BIOS; the Grub boot menu, and; I'm able to watch= the initial portion of the boot process. However, after the xend starts I'= m no longer able to view or to interact with Dom0.

How can I grant Dom0 = permanent access to the serial-console port of the host [hardware]?

TIA,=
= Eric Pretorious
Portland, OR


------=_Part_1948721_979468337.1435974603678-- --===============3290656954161165358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3290656954161165358==-- From xen-users-bounces@lists.xen.org Sat Jul 04 11:15:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 04 Jul 2015 11:15:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBLOs-0007UR-Dm; Sat, 04 Jul 2015 11:14:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBLOq-0007UM-QJ for xen-users@lists.xen.org; Sat, 04 Jul 2015 11:14:25 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 17/77-06739-F00C7955; Sat, 04 Jul 2015 11:14:23 +0000 X-Env-Sender: bernard.duf@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1436008460!23093399!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.2 required=7.0 tests=HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19749 invoked from network); 4 Jul 2015 11:14:20 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Jul 2015 11:14:20 -0000 Received: by wicgi11 with SMTP id gi11so117318896wic.0 for ; Sat, 04 Jul 2015 04:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=krdhYmELSnw5/qkIAC4CJp19uTsIjddVyw7lFlnPdPM=; b=R6MMlTqF1C+a7HDVgO9N0vcs0xx3nichYlU0r/SB01Jr4FNU9Zc9ApMPva3NBkKrjR mXGp5IgHl6Q5U/ELbJ4ACOTW0aU3f4ytjsF1K4IB/sGjLIbUVTwbRoDRpXGv42LWBx5K Cv7/XBFAwzr2gxVTA6cL30CDPgFNZq3RSQ1uP499bFDQMiaDCsbGl9sHY3VpDbIEzTP7 rsWCe1tWn2kTRxnzl5412eswNpdSDMHneuDbcMjsOHKIqegZ4ofCMo1e9AEnUCjD6yiS +/FgYWd0GEblDNVMaP9kfAy9Xr0oLvcVXC1Zups17jMg8rzAuOM2Sg+CyuC2eNVaJxjO s5pA== X-Received: by 10.180.186.99 with SMTP id fj3mr75284289wic.10.1436008459921; Sat, 04 Jul 2015 04:14:19 -0700 (PDT) Received: from macbook-pro.home (APoitiers-651-1-208-224.w2-6.abo.wanadoo.fr. [2.6.103.224]) by mx.google.com with ESMTPSA id x10sm17591458wjr.25.2015.07.04.04.14.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jul 2015 04:14:19 -0700 (PDT) From: Bernard Dufresne Message-Id: Date: Sat, 4 Jul 2015 13:14:16 +0200 To: xen-users@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Subject: [Xen-users] Nat for ipv4 & bridge for Ipv6 - Configuration? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4663169761795295549==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4663169761795295549== Content-Type: multipart/alternative; boundary="Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4" --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, i use Xen 4.4 on Debian 8, i wonder how i can create a NAT for Ipv4 = since i have one IPv4 ip & bridge for Ipv6 since i have plenty of them. On my dom0, i d like private Ipv4 ips & public Ipv6 ips. Thank you.=20 Please find below my configuration files that does not work for sure. = Notice the ipv6 ips here are all private ones for testing.=20 DomU /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8 iface eth0 inet6 static address fdde::cafe:0:2 netmask 96 gateway fdde::cafe:0:1 auto xenbr0 iface xenbr0 inet static address 192.168.0.1 netmask 255.255.255.0 pre-up brctl addbr xenbr0 pre-up ip -6 addr add fdde::cafe:0:3/96 dev xenbr0 pre-up ip -6 route add default via fdde::cafe:0:1 bridge_ports eth0 /etc/sysctl.conf net.ipv4.ip_forward=3D1 iptables: masquerade in place for Ipv4. Dom0 auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 8.8.8.8 iface eth0 inet6 static address fdde::cafe:0:4 netmask 96 gateway fdde::cafe:0:1= --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, i use Xen 4.4 on Debian 8, i wonder how i can create a = NAT for Ipv4 since i have one IPv4 ip & bridge for Ipv6 since i have = plenty of them.
On my dom0, i d like private Ipv4 ips = & public Ipv6 ips. Thank you. 

Please find below my configuration = files that does not work for sure. Notice the ipv6 ips here are all = private ones for testing. 


DomU = /etc/network/interfaces

auto lo
iface lo inet = loopback

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask = 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8

iface eth0 inet6 static
address fdde::cafe:0:2
netmask 96
gateway fdde::cafe:0:1

auto xenbr0
iface xenbr0 inet = static
address 192.168.0.1
netmask = 255.255.255.0
pre-up  brctl addbr = xenbr0
pre-up ip -6 addr add fdde::cafe:0:3/96 dev = xenbr0
pre-up ip -6 route add default via = fdde::cafe:0:1
bridge_ports eth0
/etc/sysctl.conf
net.ipv4.ip_forward=3D1

iptables:
masquerade in place for Ipv4.


Dom0

auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 8.8.8.8

iface eth0 inet6 static
address fdde::cafe:0:4
netmask 96
gateway = fdde::cafe:0:1
= --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4-- --===============4663169761795295549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4663169761795295549==-- From xen-users-bounces@lists.xen.org Sat Jul 04 11:15:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 04 Jul 2015 11:15:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBLOs-0007UR-Dm; Sat, 04 Jul 2015 11:14:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZBLOq-0007UM-QJ for xen-users@lists.xen.org; Sat, 04 Jul 2015 11:14:25 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 17/77-06739-F00C7955; Sat, 04 Jul 2015 11:14:23 +0000 X-Env-Sender: bernard.duf@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1436008460!23093399!1 X-Originating-IP: [209.85.212.177] X-SpamReason: No, hits=0.2 required=7.0 tests=HTML_MESSAGE, RCVD_ILLEGAL_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19749 invoked from network); 4 Jul 2015 11:14:20 -0000 Received: from mail-wi0-f177.google.com (HELO mail-wi0-f177.google.com) (209.85.212.177) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 4 Jul 2015 11:14:20 -0000 Received: by wicgi11 with SMTP id gi11so117318896wic.0 for ; Sat, 04 Jul 2015 04:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=krdhYmELSnw5/qkIAC4CJp19uTsIjddVyw7lFlnPdPM=; b=R6MMlTqF1C+a7HDVgO9N0vcs0xx3nichYlU0r/SB01Jr4FNU9Zc9ApMPva3NBkKrjR mXGp5IgHl6Q5U/ELbJ4ACOTW0aU3f4ytjsF1K4IB/sGjLIbUVTwbRoDRpXGv42LWBx5K Cv7/XBFAwzr2gxVTA6cL30CDPgFNZq3RSQ1uP499bFDQMiaDCsbGl9sHY3VpDbIEzTP7 rsWCe1tWn2kTRxnzl5412eswNpdSDMHneuDbcMjsOHKIqegZ4ofCMo1e9AEnUCjD6yiS +/FgYWd0GEblDNVMaP9kfAy9Xr0oLvcVXC1Zups17jMg8rzAuOM2Sg+CyuC2eNVaJxjO s5pA== X-Received: by 10.180.186.99 with SMTP id fj3mr75284289wic.10.1436008459921; Sat, 04 Jul 2015 04:14:19 -0700 (PDT) Received: from macbook-pro.home (APoitiers-651-1-208-224.w2-6.abo.wanadoo.fr. [2.6.103.224]) by mx.google.com with ESMTPSA id x10sm17591458wjr.25.2015.07.04.04.14.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Jul 2015 04:14:19 -0700 (PDT) From: Bernard Dufresne Message-Id: Date: Sat, 4 Jul 2015 13:14:16 +0200 To: xen-users@lists.xen.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) Subject: [Xen-users] Nat for ipv4 & bridge for Ipv6 - Configuration? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4663169761795295549==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4663169761795295549== Content-Type: multipart/alternative; boundary="Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4" --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, i use Xen 4.4 on Debian 8, i wonder how i can create a NAT for Ipv4 = since i have one IPv4 ip & bridge for Ipv6 since i have plenty of them. On my dom0, i d like private Ipv4 ips & public Ipv6 ips. Thank you.=20 Please find below my configuration files that does not work for sure. = Notice the ipv6 ips here are all private ones for testing.=20 DomU /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 8.8.8.8 iface eth0 inet6 static address fdde::cafe:0:2 netmask 96 gateway fdde::cafe:0:1 auto xenbr0 iface xenbr0 inet static address 192.168.0.1 netmask 255.255.255.0 pre-up brctl addbr xenbr0 pre-up ip -6 addr add fdde::cafe:0:3/96 dev xenbr0 pre-up ip -6 route add default via fdde::cafe:0:1 bridge_ports eth0 /etc/sysctl.conf net.ipv4.ip_forward=3D1 iptables: masquerade in place for Ipv4. Dom0 auto eth0 iface eth0 inet static address 192.168.0.2 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 8.8.8.8 iface eth0 inet6 static address fdde::cafe:0:4 netmask 96 gateway fdde::cafe:0:1= --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi, i use Xen 4.4 on Debian 8, i wonder how i can create a = NAT for Ipv4 since i have one IPv4 ip & bridge for Ipv6 since i have = plenty of them.
On my dom0, i d like private Ipv4 ips = & public Ipv6 ips. Thank you. 

Please find below my configuration = files that does not work for sure. Notice the ipv6 ips here are all = private ones for testing. 


DomU = /etc/network/interfaces

auto lo
iface lo inet = loopback

auto eth0
iface eth0 inet static
address 192.168.1.100
netmask = 255.255.255.0
gateway 192.168.1.1
dns-nameservers 8.8.8.8

iface eth0 inet6 static
address fdde::cafe:0:2
netmask 96
gateway fdde::cafe:0:1

auto xenbr0
iface xenbr0 inet = static
address 192.168.0.1
netmask = 255.255.255.0
pre-up  brctl addbr = xenbr0
pre-up ip -6 addr add fdde::cafe:0:3/96 dev = xenbr0
pre-up ip -6 route add default via = fdde::cafe:0:1
bridge_ports eth0
/etc/sysctl.conf
net.ipv4.ip_forward=3D1

iptables:
masquerade in place for Ipv4.


Dom0

auto eth0
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
gateway 192.168.0.1
dns-nameservers 8.8.8.8

iface eth0 inet6 static
address fdde::cafe:0:4
netmask 96
gateway = fdde::cafe:0:1
= --Apple-Mail=_79985E48-1533-4951-97C6-F1EAF32C1AE4-- --===============4663169761795295549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4663169761795295549==-- From xen-users-bounces@lists.xen.org Mon Jul 06 16:08:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 06 Jul 2015 16:08:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZC8vj-00071J-BE; Mon, 06 Jul 2015 16:07:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZC7KH-0006PE-IT for xen-users@lists.xen.org; Mon, 06 Jul 2015 14:24:53 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 29/56-21074-4BF8A955; Mon, 06 Jul 2015 14:24:52 +0000 X-Env-Sender: sanjaytr29@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1436192690!19214709!1 X-Originating-IP: [209.85.160.179] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27131 invoked from network); 6 Jul 2015 14:24:51 -0000 Received: from mail-yk0-f179.google.com (HELO mail-yk0-f179.google.com) (209.85.160.179) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Jul 2015 14:24:51 -0000 Received: by ykeo3 with SMTP id o3so28881233yke.0 for ; Mon, 06 Jul 2015 07:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=soU71TlqA7adpnEOLKvX/sjFi6W+6E82Kt1lHkHLV28=; b=Rp2Xr6AEPgw6cvN4Daa46lEsCDoTZvdyGZIItTYDThkdwF6qJkl6KDTPANhDRwPfxf injl2BGL5kADpP1jPP8ke2kMrELhYYGmV7cPJiIdeyrd8Gl3yr56qlbJzKL31ae337KC vswERB+9XuhnbC/3k8rBEh3k6rkdnoIHSdmqmrZ2dAlVvkKbRkLLJDXXcDuhM3e+DvwU 2dEyrUsnYK0HwUYAuBXHz4OVIY2S3w1Gpl/q2G1yUUclsVJwOTPQFEkztefKMjU6OT1I 5ZQhrX7CqV2rO/HAWZ5KElEptnFo2k7ghdOnfor1nHKwm4EXxRrftTBzsbED0f2mPXDp 7VHA== MIME-Version: 1.0 X-Received: by 10.13.202.209 with SMTP id m200mr41919121ywd.159.1436192690617; Mon, 06 Jul 2015 07:24:50 -0700 (PDT) Received: by 10.37.195.6 with HTTP; Mon, 6 Jul 2015 07:24:50 -0700 (PDT) Date: Mon, 6 Jul 2015 19:54:50 +0530 Message-ID: From: sanjay T R To: xen-users@lists.xen.org X-Mailman-Approved-At: Mon, 06 Jul 2015 16:07:38 +0000 Subject: [Xen-users] help PIIX4 IDE interface X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9103624559475063255==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9103624559475063255== Content-Type: multipart/alternative; boundary=001a114f1b642743ef051a35ab88 --001a114f1b642743ef051a35ab88 Content-Type: text/plain; charset=UTF-8 Hi, I am running Xen-4.4.1. Trying to bring up a Linux VM with PIIX4 IDE interface for some of my experiments but I get with only PIIX3 IDE interface with some PIIX4 support. Looking at the Xen code it looks like it supports PIIX4 IDE interface. Please let me know if this can be configured in some way. lspci on linux VM 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Thanks, Sanjay --001a114f1b642743ef051a35ab88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

I am running Xen-4.4.1. Trying to bring up a Linux V= M with PIIX4 IDE interface for some of my experiments but I get with only PIIX3 IDE interface with some PIIX4 support.

Looking at the Xen code it looks like it supports PI= IX4 IDE interface. Please let me know if this can be configured in some way.


lspci on linux VM

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA= [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PII= X3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/M= B PIIX4 ACPI (rev 03)


Thanks,

Sanjay

--001a114f1b642743ef051a35ab88-- --===============9103624559475063255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9103624559475063255==-- From xen-users-bounces@lists.xen.org Mon Jul 06 16:08:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 06 Jul 2015 16:08:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZC8vj-00071J-BE; Mon, 06 Jul 2015 16:07:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZC7KH-0006PE-IT for xen-users@lists.xen.org; Mon, 06 Jul 2015 14:24:53 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 29/56-21074-4BF8A955; Mon, 06 Jul 2015 14:24:52 +0000 X-Env-Sender: sanjaytr29@gmail.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1436192690!19214709!1 X-Originating-IP: [209.85.160.179] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27131 invoked from network); 6 Jul 2015 14:24:51 -0000 Received: from mail-yk0-f179.google.com (HELO mail-yk0-f179.google.com) (209.85.160.179) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 6 Jul 2015 14:24:51 -0000 Received: by ykeo3 with SMTP id o3so28881233yke.0 for ; Mon, 06 Jul 2015 07:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=soU71TlqA7adpnEOLKvX/sjFi6W+6E82Kt1lHkHLV28=; b=Rp2Xr6AEPgw6cvN4Daa46lEsCDoTZvdyGZIItTYDThkdwF6qJkl6KDTPANhDRwPfxf injl2BGL5kADpP1jPP8ke2kMrELhYYGmV7cPJiIdeyrd8Gl3yr56qlbJzKL31ae337KC vswERB+9XuhnbC/3k8rBEh3k6rkdnoIHSdmqmrZ2dAlVvkKbRkLLJDXXcDuhM3e+DvwU 2dEyrUsnYK0HwUYAuBXHz4OVIY2S3w1Gpl/q2G1yUUclsVJwOTPQFEkztefKMjU6OT1I 5ZQhrX7CqV2rO/HAWZ5KElEptnFo2k7ghdOnfor1nHKwm4EXxRrftTBzsbED0f2mPXDp 7VHA== MIME-Version: 1.0 X-Received: by 10.13.202.209 with SMTP id m200mr41919121ywd.159.1436192690617; Mon, 06 Jul 2015 07:24:50 -0700 (PDT) Received: by 10.37.195.6 with HTTP; Mon, 6 Jul 2015 07:24:50 -0700 (PDT) Date: Mon, 6 Jul 2015 19:54:50 +0530 Message-ID: From: sanjay T R To: xen-users@lists.xen.org X-Mailman-Approved-At: Mon, 06 Jul 2015 16:07:38 +0000 Subject: [Xen-users] help PIIX4 IDE interface X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9103624559475063255==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9103624559475063255== Content-Type: multipart/alternative; boundary=001a114f1b642743ef051a35ab88 --001a114f1b642743ef051a35ab88 Content-Type: text/plain; charset=UTF-8 Hi, I am running Xen-4.4.1. Trying to bring up a Linux VM with PIIX4 IDE interface for some of my experiments but I get with only PIIX3 IDE interface with some PIIX4 support. Looking at the Xen code it looks like it supports PIIX4 IDE interface. Please let me know if this can be configured in some way. lspci on linux VM 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) Thanks, Sanjay --001a114f1b642743ef051a35ab88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

I am running Xen-4.4.1. Trying to bring up a Linux V= M with PIIX4 IDE interface for some of my experiments but I get with only PIIX3 IDE interface with some PIIX4 support.

Looking at the Xen code it looks like it supports PI= IX4 IDE interface. Please let me know if this can be configured in some way.


lspci on linux VM

00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA= [Natoma/Triton II]
00:01.1 IDE interface: Intel Corporation 82371SB PII= X3 IDE [Natoma/Triton II]
00:01.3 Bridge: Intel Corporation 82371AB/EB/M= B PIIX4 ACPI (rev 03)


Thanks,

Sanjay

--001a114f1b642743ef051a35ab88-- --===============9103624559475063255== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9103624559475063255==-- From xen-users-bounces@lists.xen.org Mon Jul 06 18:22:10 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 06 Jul 2015 18:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCB0w-00008Y-Ac; Mon, 06 Jul 2015 18:21:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCB0v-00008T-Cw for xen-users@lists.xen.org; Mon, 06 Jul 2015 18:21:09 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id F0/12-01139-417CA955; Mon, 06 Jul 2015 18:21:08 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1436206866!15916034!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23143 invoked from network); 6 Jul 2015 18:21:08 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jul 2015 18:21:08 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t66IL4ti006233; Mon, 6 Jul 2015 13:21:04 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t66IL4Hd001670; Mon, 6 Jul 2015 13:21:04 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 6 Jul 2015 13:20:52 -0500 Message-ID: <559AB900.3050403@ti.com> Date: Mon, 6 Jul 2015 13:21:04 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> In-Reply-To: <5596645D.7030401@citrix.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/03/2015 06:30 AM, Julien Grall wrote: > Hi, > > On 02/07/15 17:04, Brandon Perez wrote: >> >> (d1) 6xen:grant_table: Grant tables using version 1 layout >> (d1) Grant table initialized >> (d1) 6xen:events: Using FIFO-based ABI >> (d1) 6Xen: initializing cpu0 >> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 > > It's hard to know what's going on with only these 5 lines. Is it the > full log of the domU? If not, can you send it? > > Usually, the next step is to bring up the other processor, although you > have only 1 vCPU in the device tree. > > Regards, > Hi Julien, Unfortunately, that is the full log of the domU messages that I get from "xl dmesg". That's part of the reason why I'm having a hard time tracking down this issue, because I'm getting so little information back from the guest. There's also the domU.log file that I attached in the prior email that has additional information. Do you have any advice what might be causing this issue just based on that information? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 06 18:22:10 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 06 Jul 2015 18:22:10 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCB0w-00008Y-Ac; Mon, 06 Jul 2015 18:21:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCB0v-00008T-Cw for xen-users@lists.xen.org; Mon, 06 Jul 2015 18:21:09 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id F0/12-01139-417CA955; Mon, 06 Jul 2015 18:21:08 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1436206866!15916034!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23143 invoked from network); 6 Jul 2015 18:21:08 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jul 2015 18:21:08 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t66IL4ti006233; Mon, 6 Jul 2015 13:21:04 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t66IL4Hd001670; Mon, 6 Jul 2015 13:21:04 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 6 Jul 2015 13:20:52 -0500 Message-ID: <559AB900.3050403@ti.com> Date: Mon, 6 Jul 2015 13:21:04 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> In-Reply-To: <5596645D.7030401@citrix.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/03/2015 06:30 AM, Julien Grall wrote: > Hi, > > On 02/07/15 17:04, Brandon Perez wrote: >> >> (d1) 6xen:grant_table: Grant tables using version 1 layout >> (d1) Grant table initialized >> (d1) 6xen:events: Using FIFO-based ABI >> (d1) 6Xen: initializing cpu0 >> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 > > It's hard to know what's going on with only these 5 lines. Is it the > full log of the domU? If not, can you send it? > > Usually, the next step is to bring up the other processor, although you > have only 1 vCPU in the device tree. > > Regards, > Hi Julien, Unfortunately, that is the full log of the domU messages that I get from "xl dmesg". That's part of the reason why I'm having a hard time tracking down this issue, because I'm getting so little information back from the guest. There's also the domU.log file that I attached in the prior email that has additional information. Do you have any advice what might be causing this issue just based on that information? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 12:27:22 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 12:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRxC-0001c2-94; Tue, 07 Jul 2015 12:26:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRx9-0001bO-Kl; Tue, 07 Jul 2015 12:26:23 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 56/58-00727-E65CB955; Tue, 07 Jul 2015 12:26:22 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-15.tower-31.messagelabs.com!1436271980!23315201!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26858 invoked from network); 7 Jul 2015 12:26:21 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-15.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 7 Jul 2015 12:26:21 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRwy-0001ic-AV; Tue, 07 Jul 2015 12:26:12 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1ZCRwx-0006ws-Qs; Tue, 07 Jul 2015 12:26:12 +0000 Date: Tue, 07 Jul 2015 12:26:11 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 137 (CVE-2015-3259) - xl command line config handling stack overflow X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-3259 / XSA-137 version 3 xl command line config handling stack overflow UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The xl command line utility mishandles long configuration values when passed as command line arguments, with a buffer overrun. VULNERABLE SYSTEMS ================== Systems built on top of xl which pass laundered or checked (but otherwise untrusted) configuration values onto xl's command line, without restricting their length, are vulnerable. We are not presently aware of any publicly distributed production software which exposes the xl vulnerability. However it is sufficiently simple to create such an arrangement that it might be done locally in an attempt to grant partial management access to particular domains. Systems using the libxl library directly, without using xl, are not vulnerable. Systems using toolstacks other than xl are not vulnerable. Systems where only fully trusted input is ever presented to the xl command line are not vulnerable. The vulnerability exists on x86 and ARM. The vulnerability was introduced in Xen 4.1 and affects all subsequent Xen releases. IMPACT ====== A semi-trusted guest administrator or controller, who is intended to be able to partially control the configuration settings for a domain, can escalate their privileges to that of the whole host. MITIGATION ========== Limiting the length of untrusted configuration settings will avoid the vulnerability. (The total length of all command-line configuration settings, including some interposed newlines and trailing nul, must be less than 1024.) CREDITS ======= This issue was discovered by Donghai Zhu of Alibab. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa137.patch Xen 4.2.x and later $ sha256sum xsa137*.patch 0272c443575c88b53445c89ef84f0cd98a03944d3303f06c66c33ef0037d97b9 xsa137.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVm8UeAAoJEIP+FMlX6CvZmnEH/1Tq+nP7STM4yE56JJsqUikV HmKbJuCy6yApsMQ7JrPjbs3yo826OQl3BVyZBicfgk6B2Cx78QgbF+XGK6B/9sfz DP5bMwz9S4n5u7K4bMkppx+6p2nG06hkzfdwzGbCC3nKiW9chYo4NdPtcQRA4d2d LnSN7JGJjxAFq22a3KKlb5AILr6x/+PYPan/jolf39rXmU1Lcg0fsMFuLm8fK1MQ burOoCphm8Xd0UOgNaH2BGCAjYoFuxKC7n12u9poCFQpnyKsYI7YGvLI2X6NgHOZ PRRSsuWqf0g7huzM/UkvPthCJzxmPWPqrLoBVOuspAOFVcqwqDmdKKSjcppEV+Q= =rvRm -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa137.patch" Content-Disposition: attachment; filename="xsa137.patch" Content-Transfer-Encoding: base64 RnJvbSA1OTNmZTUyZmFhMWI4NTU2N2E3ZWMyMGM2OWQ4Y2ZiYzczNjhhZTVi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8 aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KRGF0ZTogTW9uLCAxNSBKdW4g MjAxNSAxNDo1MDo0MiArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIHhsOiBTYW5l IGhhbmRsaW5nIG9mIGV4dHJhIGNvbmZpZyBmaWxlIGFyZ3VtZW50cwoKVmFy aW91cyB4bCBzdWItY29tbWFuZHMgdGFrZSBhZGRpdGlvbmFsIHBhcmFtZXRl cnMgY29udGFpbmluZyA9IGFzCmFkZGl0aW9uYWwgY29uZmlnIGZyYWdtZW50 cy4KClRoZSBoYW5kbGluZyBvZiB0aGVzZSBjb25maWcgZnJhZ21lbnRzIGhh cyBhIG51bWJlciBvZiBidWdzOgoKIDEuIFVzZSBvZiBhIHN0YXRpYyAxMDI0 LWJ5dGUgYnVmZmVyLiAgKElmIHRydW5jYXRpb24gd291bGQgb2NjdXIsCiAg ICB3aXRoIHNlbWktdHJ1c3RlZCBpbnB1dCwgYSBzZWN1cml0eSByaXNrIGFy aXNlcyBkdWUgdG8gcXVvdGVzCiAgICBiZWluZyBsb3N0LikKCiAyLiBNaXNo YW5kbGluZyBvZiB0aGUgcmV0dXJuIHZhbHVlIGZyb20gc25wcmludGYsIHNv IHRoYXQgaWYKICAgIHRydW5jYXRpb24gb2NjdXJzLCB0aGUgdG8td3JpdGUg cG9pbnRlciBpcyB1cGRhdGVkIHdpdGggdGhlCiAgICB3YW50ZWQtdG8td3Jp dGUgbGVuZ3RoLCByZXN1bHRpbmcgaW4gc3RhY2sgY29ycnVwdGlvbi4gIChU aGlzIGlzCiAgICBYU0EtMTM3LikKCiAzLiBDbG9uZS1hbmQtaGFjayBvZiB0 aGUgY29kZSBmb3IgY29uc3RydWN0aW5nIHRoZSBhcHBlbmRlZAogICAgY29u ZmlnIGZpbGUuCgpUaGVzZSBhcmUgZml4ZWQgaGVyZSwgYnkgaW50cm9kdWNp bmcgYSBuZXcgZnVuY3Rpb24KYHN0cmluZ19yZWFsbG9jX2FwcGVuZCcgYW5k IHVzaW5nIGl0IGV2ZXJ5d2hlcmUuICBUaGUgYGV4dHJhX2luZm8nCmJ1ZmZl cnMgYXJlIHJlcGxhY2VkIGJ5IHBvaW50ZXJzLCB3aGljaCBzdGFydCBvZmYg TlVMTCBhbmQgYXJlCmV4cGxpY2l0bHkgZnJlZWQgb24gYWxsIHJldHVybiBw YXRocy4KClRoZSBzZXBhcmF0ZSB2YXJpYWJsZSB3aGljaCB3aWxsIGJlY29t ZSBkb21faW5mby5leHRyYV9jb25maWcgaXMKYWJvbGlzaGVkICh3aGljaCBp bnZvbHZlcyBtb3ZpbmcgdGhlIGNsZWFyaW5nIG9mIGRvbV9pbmZvKS4KCkFk ZGl0aW9uYWwgYnVncyBJIG9ic2VydmUsIG5vdCBmaXhlZCBoZXJlOgoKIDQu IFRoZSBmdW5jdGlvbnMgd2hpY2ggbm93IGNhbGwgc3RyaW5nX3JlYWxsb2Nf YXBwZW5kIHVzZSBhZC1ob2MKICAgIGVycm9yIHJldHVybnMsIHdpdGggbXVs dGlwbGUgY2FsbHMgdG8gYHJldHVybicuICBUaGlzIGN1cnJlbnRseQogICAg bmVjZXNzaXRhdGVzIG11bHRpcGxlIG5ldyBjYWxscyB0byBgZnJlZScuCgog NS4gTWFueSBvZiB0aGUgcGF0aHMgaW4geGwgY2FsbCBleGl0KC1yYykgd2hl cmUgcmMgaXMgYSBsaWJ4bCBzdGF0dXMKICAgIGNvZGUuICBUaGlzIGlzIGEg cmlkaWN1bG91cyBleGl0IHN0YXR1cyBgY29udmVudGlvbicuCgogNi4gVGhl IGxvb3BzIGZvciBoYW5kbGluZyBleHRyYSBjb25maWcgZGF0YSBhcmUgY2xv bmUtYW5kLWhhY2tzLgoKIDcuIE9uY2UgdGhlIGV4dHJhIGNvbmZpZyBidWZm ZXIgaXMgYWNjdW11bGF0ZWQsIGl0IG11c3QgYmUgY29tYmluZWQKICAgIHdp dGggdGhlIGFwcHJvcHJpYXRlIG1haW4gY29uZmlnIGZpbGUuICBUaGUgY29k ZSB0byBkbyB0aGlzCiAgICBjb21iaW5pbmcgaXMgY2xvbmUtYW5kLWhhY2tl ZCB0b28uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8SWFuLkphY2tz b25AZXUuY2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gSmFja3NvbiA8SWFu LkphY2tzb25AZXUuY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBDYW1wYmVs bCA8aWFuLGNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQp2MjogVXNlIFNTSVpF X01BWCwgbm90IElOVF9NQVguCiAgICBDaGVjayAqYWNjdW11bGF0ZSBmb3Ig TlVMTCwgbm90IGFjY3VtdWxhdGUuCiAgICBNb3ZlIG1lbXNldCBvZiBkb21f aW5mby4KLS0tCiB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgfCAgIDY0ICsr KysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0K IDEgZmlsZSBjaGFuZ2VkLCA0MCBpbnNlcnRpb25zKCspLCAyNCBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMg Yi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKaW5kZXggYzg1ODA2OC4uYzAx YTg1MSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCisr KyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtMTUxLDcgKzE1MSw3 IEBAIHN0cnVjdCBkb21haW5fY3JlYXRlIHsKICAgICBpbnQgY29uc29sZV9h dXRvY29ubmVjdDsKICAgICBpbnQgY2hlY2twb2ludGVkX3N0cmVhbTsKICAg ICBjb25zdCBjaGFyICpjb25maWdfZmlsZTsKLSAgICBjb25zdCBjaGFyICpl eHRyYV9jb25maWc7IC8qIGV4dHJhIGNvbmZpZyBzdHJpbmcgKi8KKyAgICBj aGFyICpleHRyYV9jb25maWc7IC8qIGV4dHJhIGNvbmZpZyBzdHJpbmcgKi8K ICAgICBjb25zdCBjaGFyICpyZXN0b3JlX2ZpbGU7CiAgICAgaW50IG1pZ3Jh dGVfZmQ7IC8qIC0xIG1lYW5zIG5vbmUgKi8KICAgICBjaGFyICoqbWlncmF0 aW9uX2RvbW5hbWVfcjsgLyogZnJvbSBtYWxsb2MgKi8KQEAgLTQ4MDUsMTEg KzQ4MDUsMjUgQEAgaW50IG1haW5fdm1fbGlzdChpbnQgYXJnYywgY2hhciAq KmFyZ3YpCiAgICAgcmV0dXJuIDA7CiB9CiAKK3N0YXRpYyB2b2lkIHN0cmlu Z19yZWFsbG9jX2FwcGVuZChjaGFyICoqYWNjdW11bGF0ZSwgY29uc3QgY2hh ciAqbW9yZSkKK3sKKyAgICAvKiBBcHBlbmRzIG1vcmUgdG8gYWNjdW11bGF0 ZS4gIEFjY3VtdWxhdGUgaXMgZWl0aGVyIE5VTEwsIG9yCisgICAgICogcG9p bnRzIChhbHdheXMpIHRvIGEgbWFsbG9jJ2QgbnVsLXRlcm1pbmF0ZWQgc3Ry aW5nLiAqLworCisgICAgc2l6ZV90IG9sZGxlbiA9ICphY2N1bXVsYXRlID8g c3RybGVuKCphY2N1bXVsYXRlKSA6IDA7CisgICAgc2l6ZV90IG1vcmVsZW4g PSBzdHJsZW4obW9yZSkgKyAxLypudWwqLzsKKyAgICBpZiAob2xkbGVuID4g U1NJWkVfTUFYIHx8IG1vcmVsZW4gPiBTU0laRV9NQVggLSBvbGRsZW4pIHsK KyAgICAgICAgZnByaW50ZihzdGRlcnIsIkFkZGl0aW9uYWwgY29uZmlnIGRh dGEgZmFyIHRvbyBsYXJnZVxuIik7CisgICAgICAgIGV4aXQoLUVSUk9SX0ZB SUwpOworICAgIH0KKworICAgICphY2N1bXVsYXRlID0geHJlYWxsb2MoKmFj Y3VtdWxhdGUsIG9sZGxlbiArIG1vcmVsZW4pOworICAgIG1lbWNweSgqYWNj dW11bGF0ZSArIG9sZGxlbiwgbW9yZSwgbW9yZWxlbik7Cit9CisKIGludCBt YWluX2NyZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiB7CiAgICAgY29u c3QgY2hhciAqZmlsZW5hbWUgPSBOVUxMOwotICAgIGNoYXIgKnA7Ci0gICAg Y2hhciBleHRyYV9jb25maWdbMTAyNF07CiAgICAgc3RydWN0IGRvbWFpbl9j cmVhdGUgZG9tX2luZm87CiAgICAgaW50IHBhdXNlZCA9IDAsIGRlYnVnID0g MCwgZGFlbW9uaXplID0gMSwgY29uc29sZV9hdXRvY29ubmVjdCA9IDAsCiAg ICAgICAgIHF1aWV0ID0gMCwgbW9uaXRvciA9IDEsIHZuYyA9IDAsIHZuY2F1 dG9wYXNzID0gMDsKQEAgLTQ4MjQsNiArNDgzOCw4IEBAIGludCBtYWluX2Ny ZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIHswLCAwLCAw LCAwfQogICAgIH07CiAKKyAgICBkb21faW5mby5leHRyYV9jb25maWcgPSBO VUxMOworCiAgICAgaWYgKGFyZ3ZbMV0gJiYgYXJndlsxXVswXSAhPSAnLScg JiYgIXN0cmNocihhcmd2WzFdLCAnPScpKSB7CiAgICAgICAgIGZpbGVuYW1l ID0gYXJndlsxXTsKICAgICAgICAgYXJnYy0tOyBhcmd2Kys7CkBAIC00ODYz LDIwICs0ODc5LDIxIEBAIGludCBtYWluX2NyZWF0ZShpbnQgYXJnYywgY2hh ciAqKmFyZ3YpCiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIGV4dHJh X2NvbmZpZ1swXSA9ICdcMCc7Ci0gICAgZm9yIChwID0gZXh0cmFfY29uZmln OyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgeworICAgIG1lbXNldCgmZG9t X2luZm8sIDAsIHNpemVvZihkb21faW5mbykpOworCisgICAgZm9yICg7IG9w dGluZCA8IGFyZ2M7IG9wdGluZCsrKSB7CiAgICAgICAgIGlmIChzdHJjaHIo YXJndltvcHRpbmRdLCAnPScpICE9IE5VTEwpIHsKLSAgICAgICAgICAgIHAg Kz0gc25wcmludGYocCwgc2l6ZW9mKGV4dHJhX2NvbmZpZykgLSAocCAtIGV4 dHJhX2NvbmZpZyksCi0gICAgICAgICAgICAgICAgIiVzXG4iLCBhcmd2W29w dGluZF0pOworICAgICAgICAgICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZk b21faW5mby5leHRyYV9jb25maWcsIGFyZ3Zbb3B0aW5kXSk7CisgICAgICAg ICAgICBzdHJpbmdfcmVhbGxvY19hcHBlbmQoJmRvbV9pbmZvLmV4dHJhX2Nv bmZpZywgIlxuIik7CiAgICAgICAgIH0gZWxzZSBpZiAoIWZpbGVuYW1lKSB7 CiAgICAgICAgICAgICBmaWxlbmFtZSA9IGFyZ3Zbb3B0aW5kXTsKICAgICAg ICAgfSBlbHNlIHsKICAgICAgICAgICAgIGhlbHAoImNyZWF0ZSIpOworICAg ICAgICAgICAgZnJlZShkb21faW5mby5leHRyYV9jb25maWcpOwogICAgICAg ICAgICAgcmV0dXJuIDI7CiAgICAgICAgIH0KICAgICB9CiAKLSAgICBtZW1z ZXQoJmRvbV9pbmZvLCAwLCBzaXplb2YoZG9tX2luZm8pKTsKICAgICBkb21f aW5mby5kZWJ1ZyA9IGRlYnVnOwogICAgIGRvbV9pbmZvLmRhZW1vbml6ZSA9 IGRhZW1vbml6ZTsKICAgICBkb21faW5mby5tb25pdG9yID0gbW9uaXRvcjsK QEAgLTQ4ODQsMTYgKzQ5MDEsMTggQEAgaW50IG1haW5fY3JlYXRlKGludCBh cmdjLCBjaGFyICoqYXJndikKICAgICBkb21faW5mby5kcnlydW4gPSBkcnly dW5fb25seTsKICAgICBkb21faW5mby5xdWlldCA9IHF1aWV0OwogICAgIGRv bV9pbmZvLmNvbmZpZ19maWxlID0gZmlsZW5hbWU7Ci0gICAgZG9tX2luZm8u ZXh0cmFfY29uZmlnID0gZXh0cmFfY29uZmlnOwogICAgIGRvbV9pbmZvLm1p Z3JhdGVfZmQgPSAtMTsKICAgICBkb21faW5mby52bmMgPSB2bmM7CiAgICAg ZG9tX2luZm8udm5jYXV0b3Bhc3MgPSB2bmNhdXRvcGFzczsKICAgICBkb21f aW5mby5jb25zb2xlX2F1dG9jb25uZWN0ID0gY29uc29sZV9hdXRvY29ubmVj dDsKIAogICAgIHJjID0gY3JlYXRlX2RvbWFpbigmZG9tX2luZm8pOwotICAg IGlmIChyYyA8IDApCisgICAgaWYgKHJjIDwgMCkgeworICAgICAgICBmcmVl KGRvbV9pbmZvLmV4dHJhX2NvbmZpZyk7CiAgICAgICAgIHJldHVybiAtcmM7 CisgICAgfQogCisgICAgZnJlZShkb21faW5mby5leHRyYV9jb25maWcpOwog ICAgIHJldHVybiAwOwogfQogCkBAIC00OTAxLDggKzQ5MjAsNyBAQCBpbnQg bWFpbl9jb25maWdfdXBkYXRlKGludCBhcmdjLCBjaGFyICoqYXJndikKIHsK ICAgICB1aW50MzJfdCBkb21pZDsKICAgICBjb25zdCBjaGFyICpmaWxlbmFt ZSA9IE5VTEw7Ci0gICAgY2hhciAqcDsKLSAgICBjaGFyIGV4dHJhX2NvbmZp Z1sxMDI0XTsKKyAgICBjaGFyICpleHRyYV9jb25maWcgPSBOVUxMOwogICAg IHZvaWQgKmNvbmZpZ19kYXRhID0gMDsKICAgICBpbnQgY29uZmlnX2xlbiA9 IDA7CiAgICAgbGlieGxfZG9tYWluX2NvbmZpZyBkX2NvbmZpZzsKQEAgLTQ5 NDAsMTUgKzQ5NTgsMTUgQEAgaW50IG1haW5fY29uZmlnX3VwZGF0ZShpbnQg YXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIGJyZWFrOwogICAgIH0KIAot ICAgIGV4dHJhX2NvbmZpZ1swXSA9ICdcMCc7Ci0gICAgZm9yIChwID0gZXh0 cmFfY29uZmlnOyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgeworICAgIGZv ciAoOyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgewogICAgICAgICBpZiAo c3RyY2hyKGFyZ3Zbb3B0aW5kXSwgJz0nKSAhPSBOVUxMKSB7Ci0gICAgICAg ICAgICBwICs9IHNucHJpbnRmKHAsIHNpemVvZihleHRyYV9jb25maWcpIC0g KHAgLSBleHRyYV9jb25maWcpLAotICAgICAgICAgICAgICAgICIlc1xuIiwg YXJndltvcHRpbmRdKTsKKyAgICAgICAgICAgIHN0cmluZ19yZWFsbG9jX2Fw cGVuZCgmZXh0cmFfY29uZmlnLCBhcmd2W29wdGluZF0pOworICAgICAgICAg ICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25maWcsICJcbiIp OwogICAgICAgICB9IGVsc2UgaWYgKCFmaWxlbmFtZSkgewogICAgICAgICAg ICAgZmlsZW5hbWUgPSBhcmd2W29wdGluZF07CiAgICAgICAgIH0gZWxzZSB7 CiAgICAgICAgICAgICBoZWxwKCJjcmVhdGUiKTsKKyAgICAgICAgICAgIGZy ZWUoZXh0cmFfY29uZmlnKTsKICAgICAgICAgICAgIHJldHVybiAyOwogICAg ICAgICB9CiAgICAgfQpAQCAtNDk1Nyw3ICs0OTc1LDggQEAgaW50IG1haW5f Y29uZmlnX3VwZGF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAg IHJjID0gbGlieGxfcmVhZF9maWxlX2NvbnRlbnRzKGN0eCwgZmlsZW5hbWUs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZjb25m aWdfZGF0YSwgJmNvbmZpZ19sZW4pOwogICAgICAgICBpZiAocmMpIHsgZnBy aW50ZihzdGRlcnIsICJGYWlsZWQgdG8gcmVhZCBjb25maWcgZmlsZTogJXM6 ICVzXG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsZW5hbWUs IHN0cmVycm9yKGVycm5vKSk7IHJldHVybiBFUlJPUl9GQUlMOyB9CisgICAg ICAgICAgICAgICAgICAgICAgICAgICBmaWxlbmFtZSwgc3RyZXJyb3IoZXJy bm8pKTsKKyAgICAgICAgICAgICAgICAgIGZyZWUoZXh0cmFfY29uZmlnKTsg cmV0dXJuIEVSUk9SX0ZBSUw7IH0KICAgICAgICAgaWYgKHN0cmxlbihleHRy YV9jb25maWcpKSB7CiAgICAgICAgICAgICBpZiAoY29uZmlnX2xlbiA+IElO VF9NQVggLSAoc3RybGVuKGV4dHJhX2NvbmZpZykgKyAyICsgMSkpIHsKICAg ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkZhaWxlZCB0byBhdHRh Y2ggZXh0cmEgY29uZmlncmF0aW9uXG4iKTsKQEAgLTQ5OTgsNyArNTAxNyw3 IEBAIGludCBtYWluX2NvbmZpZ191cGRhdGUoaW50IGFyZ2MsIGNoYXIgKiph cmd2KQogICAgIGxpYnhsX2RvbWFpbl9jb25maWdfZGlzcG9zZSgmZF9jb25m aWcpOwogCiAgICAgZnJlZShjb25maWdfZGF0YSk7Ci0KKyAgICBmcmVlKGV4 dHJhX2NvbmZpZyk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTcyNTUsNyAr NzI3NCw3IEBAIGludCBtYWluX2NwdXBvb2xjcmVhdGUoaW50IGFyZ2MsIGNo YXIgKiphcmd2KQogewogICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lID0gTlVM TCwgKmNvbmZpZ19zcmM9TlVMTDsKICAgICBjb25zdCBjaGFyICpwOwotICAg IGNoYXIgZXh0cmFfY29uZmlnWzEwMjRdOworICAgIGNoYXIgKmV4dHJhX2Nv bmZpZyA9IE5VTEw7CiAgICAgaW50IG9wdDsKICAgICBzdGF0aWMgc3RydWN0 IG9wdGlvbiBvcHRzW10gPSB7CiAgICAgICAgIHsiZGVmY29uZmlnIiwgMSwg MCwgJ2YnfSwKQEAgLTcyODksMTMgKzczMDgsMTAgQEAgaW50IG1haW5fY3B1 cG9vbGNyZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIGJy ZWFrOwogICAgIH0KIAotICAgIG1lbXNldChleHRyYV9jb25maWcsIDAsIHNp emVvZihleHRyYV9jb25maWcpKTsKICAgICB3aGlsZSAob3B0aW5kIDwgYXJn YykgewogICAgICAgICBpZiAoKHAgPSBzdHJjaHIoYXJndltvcHRpbmRdLCAn PScpKSkgewotICAgICAgICAgICAgaWYgKHN0cmxlbihleHRyYV9jb25maWcp ICsgMSArIHN0cmxlbihhcmd2W29wdGluZF0pIDwgc2l6ZW9mKGV4dHJhX2Nv bmZpZykpIHsKLSAgICAgICAgICAgICAgICBzdHJjYXQoZXh0cmFfY29uZmln LCAiXG4iKTsKLSAgICAgICAgICAgICAgICBzdHJjYXQoZXh0cmFfY29uZmln LCBhcmd2W29wdGluZF0pOwotICAgICAgICAgICAgfQorICAgICAgICAgICAg c3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25maWcsICJcbiIpOwor ICAgICAgICAgICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25m aWcsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIH0gZWxzZSBpZiAoIWZpbGVu YW1lKSB7CiAgICAgICAgICAgICBmaWxlbmFtZSA9IGFyZ3Zbb3B0aW5kXTsK ICAgICAgICAgfSBlbHNlIHsKLS0gCjEuNy4xMC40Cgo= --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Tue Jul 07 12:27:22 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 12:27:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRxC-0001c2-94; Tue, 07 Jul 2015 12:26:26 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRx9-0001bO-Kl; Tue, 07 Jul 2015 12:26:23 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 56/58-00727-E65CB955; Tue, 07 Jul 2015 12:26:22 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-15.tower-31.messagelabs.com!1436271980!23315201!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26858 invoked from network); 7 Jul 2015 12:26:21 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-15.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 7 Jul 2015 12:26:21 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCRwy-0001ic-AV; Tue, 07 Jul 2015 12:26:12 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1ZCRwx-0006ws-Qs; Tue, 07 Jul 2015 12:26:12 +0000 Date: Tue, 07 Jul 2015 12:26:11 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 137 (CVE-2015-3259) - xl command line config handling stack overflow X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-3259 / XSA-137 version 3 xl command line config handling stack overflow UPDATES IN VERSION 3 ==================== Public release. ISSUE DESCRIPTION ================= The xl command line utility mishandles long configuration values when passed as command line arguments, with a buffer overrun. VULNERABLE SYSTEMS ================== Systems built on top of xl which pass laundered or checked (but otherwise untrusted) configuration values onto xl's command line, without restricting their length, are vulnerable. We are not presently aware of any publicly distributed production software which exposes the xl vulnerability. However it is sufficiently simple to create such an arrangement that it might be done locally in an attempt to grant partial management access to particular domains. Systems using the libxl library directly, without using xl, are not vulnerable. Systems using toolstacks other than xl are not vulnerable. Systems where only fully trusted input is ever presented to the xl command line are not vulnerable. The vulnerability exists on x86 and ARM. The vulnerability was introduced in Xen 4.1 and affects all subsequent Xen releases. IMPACT ====== A semi-trusted guest administrator or controller, who is intended to be able to partially control the configuration settings for a domain, can escalate their privileges to that of the whole host. MITIGATION ========== Limiting the length of untrusted configuration settings will avoid the vulnerability. (The total length of all command-line configuration settings, including some interposed newlines and trailing nul, must be less than 1024.) CREDITS ======= This issue was discovered by Donghai Zhu of Alibab. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa137.patch Xen 4.2.x and later $ sha256sum xsa137*.patch 0272c443575c88b53445c89ef84f0cd98a03944d3303f06c66c33ef0037d97b9 xsa137.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of the patches and/or mitigations described above (or others which are substantially similar) is permitted during the embargo, even on public-facing systems with untrusted guest users and administrators. But: Distribution of updated software is prohibited (except to other members of the predisclosure list). Predisclosure list members who wish to deploy significantly different patches and/or mitigations, please contact the Xen Project Security Team. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVm8UeAAoJEIP+FMlX6CvZmnEH/1Tq+nP7STM4yE56JJsqUikV HmKbJuCy6yApsMQ7JrPjbs3yo826OQl3BVyZBicfgk6B2Cx78QgbF+XGK6B/9sfz DP5bMwz9S4n5u7K4bMkppx+6p2nG06hkzfdwzGbCC3nKiW9chYo4NdPtcQRA4d2d LnSN7JGJjxAFq22a3KKlb5AILr6x/+PYPan/jolf39rXmU1Lcg0fsMFuLm8fK1MQ burOoCphm8Xd0UOgNaH2BGCAjYoFuxKC7n12u9poCFQpnyKsYI7YGvLI2X6NgHOZ PRRSsuWqf0g7huzM/UkvPthCJzxmPWPqrLoBVOuspAOFVcqwqDmdKKSjcppEV+Q= =rvRm -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa137.patch" Content-Disposition: attachment; filename="xsa137.patch" Content-Transfer-Encoding: base64 RnJvbSA1OTNmZTUyZmFhMWI4NTU2N2E3ZWMyMGM2OWQ4Y2ZiYzczNjhhZTVi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8 aWFuLmphY2tzb25AZXUuY2l0cml4LmNvbT4KRGF0ZTogTW9uLCAxNSBKdW4g MjAxNSAxNDo1MDo0MiArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIHhsOiBTYW5l IGhhbmRsaW5nIG9mIGV4dHJhIGNvbmZpZyBmaWxlIGFyZ3VtZW50cwoKVmFy aW91cyB4bCBzdWItY29tbWFuZHMgdGFrZSBhZGRpdGlvbmFsIHBhcmFtZXRl cnMgY29udGFpbmluZyA9IGFzCmFkZGl0aW9uYWwgY29uZmlnIGZyYWdtZW50 cy4KClRoZSBoYW5kbGluZyBvZiB0aGVzZSBjb25maWcgZnJhZ21lbnRzIGhh cyBhIG51bWJlciBvZiBidWdzOgoKIDEuIFVzZSBvZiBhIHN0YXRpYyAxMDI0 LWJ5dGUgYnVmZmVyLiAgKElmIHRydW5jYXRpb24gd291bGQgb2NjdXIsCiAg ICB3aXRoIHNlbWktdHJ1c3RlZCBpbnB1dCwgYSBzZWN1cml0eSByaXNrIGFy aXNlcyBkdWUgdG8gcXVvdGVzCiAgICBiZWluZyBsb3N0LikKCiAyLiBNaXNo YW5kbGluZyBvZiB0aGUgcmV0dXJuIHZhbHVlIGZyb20gc25wcmludGYsIHNv IHRoYXQgaWYKICAgIHRydW5jYXRpb24gb2NjdXJzLCB0aGUgdG8td3JpdGUg cG9pbnRlciBpcyB1cGRhdGVkIHdpdGggdGhlCiAgICB3YW50ZWQtdG8td3Jp dGUgbGVuZ3RoLCByZXN1bHRpbmcgaW4gc3RhY2sgY29ycnVwdGlvbi4gIChU aGlzIGlzCiAgICBYU0EtMTM3LikKCiAzLiBDbG9uZS1hbmQtaGFjayBvZiB0 aGUgY29kZSBmb3IgY29uc3RydWN0aW5nIHRoZSBhcHBlbmRlZAogICAgY29u ZmlnIGZpbGUuCgpUaGVzZSBhcmUgZml4ZWQgaGVyZSwgYnkgaW50cm9kdWNp bmcgYSBuZXcgZnVuY3Rpb24KYHN0cmluZ19yZWFsbG9jX2FwcGVuZCcgYW5k IHVzaW5nIGl0IGV2ZXJ5d2hlcmUuICBUaGUgYGV4dHJhX2luZm8nCmJ1ZmZl cnMgYXJlIHJlcGxhY2VkIGJ5IHBvaW50ZXJzLCB3aGljaCBzdGFydCBvZmYg TlVMTCBhbmQgYXJlCmV4cGxpY2l0bHkgZnJlZWQgb24gYWxsIHJldHVybiBw YXRocy4KClRoZSBzZXBhcmF0ZSB2YXJpYWJsZSB3aGljaCB3aWxsIGJlY29t ZSBkb21faW5mby5leHRyYV9jb25maWcgaXMKYWJvbGlzaGVkICh3aGljaCBp bnZvbHZlcyBtb3ZpbmcgdGhlIGNsZWFyaW5nIG9mIGRvbV9pbmZvKS4KCkFk ZGl0aW9uYWwgYnVncyBJIG9ic2VydmUsIG5vdCBmaXhlZCBoZXJlOgoKIDQu IFRoZSBmdW5jdGlvbnMgd2hpY2ggbm93IGNhbGwgc3RyaW5nX3JlYWxsb2Nf YXBwZW5kIHVzZSBhZC1ob2MKICAgIGVycm9yIHJldHVybnMsIHdpdGggbXVs dGlwbGUgY2FsbHMgdG8gYHJldHVybicuICBUaGlzIGN1cnJlbnRseQogICAg bmVjZXNzaXRhdGVzIG11bHRpcGxlIG5ldyBjYWxscyB0byBgZnJlZScuCgog NS4gTWFueSBvZiB0aGUgcGF0aHMgaW4geGwgY2FsbCBleGl0KC1yYykgd2hl cmUgcmMgaXMgYSBsaWJ4bCBzdGF0dXMKICAgIGNvZGUuICBUaGlzIGlzIGEg cmlkaWN1bG91cyBleGl0IHN0YXR1cyBgY29udmVudGlvbicuCgogNi4gVGhl IGxvb3BzIGZvciBoYW5kbGluZyBleHRyYSBjb25maWcgZGF0YSBhcmUgY2xv bmUtYW5kLWhhY2tzLgoKIDcuIE9uY2UgdGhlIGV4dHJhIGNvbmZpZyBidWZm ZXIgaXMgYWNjdW11bGF0ZWQsIGl0IG11c3QgYmUgY29tYmluZWQKICAgIHdp dGggdGhlIGFwcHJvcHJpYXRlIG1haW4gY29uZmlnIGZpbGUuICBUaGUgY29k ZSB0byBkbyB0aGlzCiAgICBjb21iaW5pbmcgaXMgY2xvbmUtYW5kLWhhY2tl ZCB0b28uCgpTaWduZWQtb2ZmLWJ5OiBJYW4gSmFja3NvbiA8SWFuLkphY2tz b25AZXUuY2l0cml4LmNvbT4KVGVzdGVkLWJ5OiBJYW4gSmFja3NvbiA8SWFu LkphY2tzb25AZXUuY2l0cml4LmNvbT4KQWNrZWQtYnk6IElhbiBDYW1wYmVs bCA8aWFuLGNhbXBiZWxsQGNpdHJpeC5jb20+Ci0tLQp2MjogVXNlIFNTSVpF X01BWCwgbm90IElOVF9NQVguCiAgICBDaGVjayAqYWNjdW11bGF0ZSBmb3Ig TlVMTCwgbm90IGFjY3VtdWxhdGUuCiAgICBNb3ZlIG1lbXNldCBvZiBkb21f aW5mby4KLS0tCiB0b29scy9saWJ4bC94bF9jbWRpbXBsLmMgfCAgIDY0ICsr KysrKysrKysrKysrKysrKysrKysrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0K IDEgZmlsZSBjaGFuZ2VkLCA0MCBpbnNlcnRpb25zKCspLCAyNCBkZWxldGlv bnMoLSkKCmRpZmYgLS1naXQgYS90b29scy9saWJ4bC94bF9jbWRpbXBsLmMg Yi90b29scy9saWJ4bC94bF9jbWRpbXBsLmMKaW5kZXggYzg1ODA2OC4uYzAx YTg1MSAxMDA2NDQKLS0tIGEvdG9vbHMvbGlieGwveGxfY21kaW1wbC5jCisr KyBiL3Rvb2xzL2xpYnhsL3hsX2NtZGltcGwuYwpAQCAtMTUxLDcgKzE1MSw3 IEBAIHN0cnVjdCBkb21haW5fY3JlYXRlIHsKICAgICBpbnQgY29uc29sZV9h dXRvY29ubmVjdDsKICAgICBpbnQgY2hlY2twb2ludGVkX3N0cmVhbTsKICAg ICBjb25zdCBjaGFyICpjb25maWdfZmlsZTsKLSAgICBjb25zdCBjaGFyICpl eHRyYV9jb25maWc7IC8qIGV4dHJhIGNvbmZpZyBzdHJpbmcgKi8KKyAgICBj aGFyICpleHRyYV9jb25maWc7IC8qIGV4dHJhIGNvbmZpZyBzdHJpbmcgKi8K ICAgICBjb25zdCBjaGFyICpyZXN0b3JlX2ZpbGU7CiAgICAgaW50IG1pZ3Jh dGVfZmQ7IC8qIC0xIG1lYW5zIG5vbmUgKi8KICAgICBjaGFyICoqbWlncmF0 aW9uX2RvbW5hbWVfcjsgLyogZnJvbSBtYWxsb2MgKi8KQEAgLTQ4MDUsMTEg KzQ4MDUsMjUgQEAgaW50IG1haW5fdm1fbGlzdChpbnQgYXJnYywgY2hhciAq KmFyZ3YpCiAgICAgcmV0dXJuIDA7CiB9CiAKK3N0YXRpYyB2b2lkIHN0cmlu Z19yZWFsbG9jX2FwcGVuZChjaGFyICoqYWNjdW11bGF0ZSwgY29uc3QgY2hh ciAqbW9yZSkKK3sKKyAgICAvKiBBcHBlbmRzIG1vcmUgdG8gYWNjdW11bGF0 ZS4gIEFjY3VtdWxhdGUgaXMgZWl0aGVyIE5VTEwsIG9yCisgICAgICogcG9p bnRzIChhbHdheXMpIHRvIGEgbWFsbG9jJ2QgbnVsLXRlcm1pbmF0ZWQgc3Ry aW5nLiAqLworCisgICAgc2l6ZV90IG9sZGxlbiA9ICphY2N1bXVsYXRlID8g c3RybGVuKCphY2N1bXVsYXRlKSA6IDA7CisgICAgc2l6ZV90IG1vcmVsZW4g PSBzdHJsZW4obW9yZSkgKyAxLypudWwqLzsKKyAgICBpZiAob2xkbGVuID4g U1NJWkVfTUFYIHx8IG1vcmVsZW4gPiBTU0laRV9NQVggLSBvbGRsZW4pIHsK KyAgICAgICAgZnByaW50ZihzdGRlcnIsIkFkZGl0aW9uYWwgY29uZmlnIGRh dGEgZmFyIHRvbyBsYXJnZVxuIik7CisgICAgICAgIGV4aXQoLUVSUk9SX0ZB SUwpOworICAgIH0KKworICAgICphY2N1bXVsYXRlID0geHJlYWxsb2MoKmFj Y3VtdWxhdGUsIG9sZGxlbiArIG1vcmVsZW4pOworICAgIG1lbWNweSgqYWNj dW11bGF0ZSArIG9sZGxlbiwgbW9yZSwgbW9yZWxlbik7Cit9CisKIGludCBt YWluX2NyZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiB7CiAgICAgY29u c3QgY2hhciAqZmlsZW5hbWUgPSBOVUxMOwotICAgIGNoYXIgKnA7Ci0gICAg Y2hhciBleHRyYV9jb25maWdbMTAyNF07CiAgICAgc3RydWN0IGRvbWFpbl9j cmVhdGUgZG9tX2luZm87CiAgICAgaW50IHBhdXNlZCA9IDAsIGRlYnVnID0g MCwgZGFlbW9uaXplID0gMSwgY29uc29sZV9hdXRvY29ubmVjdCA9IDAsCiAg ICAgICAgIHF1aWV0ID0gMCwgbW9uaXRvciA9IDEsIHZuYyA9IDAsIHZuY2F1 dG9wYXNzID0gMDsKQEAgLTQ4MjQsNiArNDgzOCw4IEBAIGludCBtYWluX2Ny ZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIHswLCAwLCAw LCAwfQogICAgIH07CiAKKyAgICBkb21faW5mby5leHRyYV9jb25maWcgPSBO VUxMOworCiAgICAgaWYgKGFyZ3ZbMV0gJiYgYXJndlsxXVswXSAhPSAnLScg JiYgIXN0cmNocihhcmd2WzFdLCAnPScpKSB7CiAgICAgICAgIGZpbGVuYW1l ID0gYXJndlsxXTsKICAgICAgICAgYXJnYy0tOyBhcmd2Kys7CkBAIC00ODYz LDIwICs0ODc5LDIxIEBAIGludCBtYWluX2NyZWF0ZShpbnQgYXJnYywgY2hh ciAqKmFyZ3YpCiAgICAgICAgIGJyZWFrOwogICAgIH0KIAotICAgIGV4dHJh X2NvbmZpZ1swXSA9ICdcMCc7Ci0gICAgZm9yIChwID0gZXh0cmFfY29uZmln OyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgeworICAgIG1lbXNldCgmZG9t X2luZm8sIDAsIHNpemVvZihkb21faW5mbykpOworCisgICAgZm9yICg7IG9w dGluZCA8IGFyZ2M7IG9wdGluZCsrKSB7CiAgICAgICAgIGlmIChzdHJjaHIo YXJndltvcHRpbmRdLCAnPScpICE9IE5VTEwpIHsKLSAgICAgICAgICAgIHAg Kz0gc25wcmludGYocCwgc2l6ZW9mKGV4dHJhX2NvbmZpZykgLSAocCAtIGV4 dHJhX2NvbmZpZyksCi0gICAgICAgICAgICAgICAgIiVzXG4iLCBhcmd2W29w dGluZF0pOworICAgICAgICAgICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZk b21faW5mby5leHRyYV9jb25maWcsIGFyZ3Zbb3B0aW5kXSk7CisgICAgICAg ICAgICBzdHJpbmdfcmVhbGxvY19hcHBlbmQoJmRvbV9pbmZvLmV4dHJhX2Nv bmZpZywgIlxuIik7CiAgICAgICAgIH0gZWxzZSBpZiAoIWZpbGVuYW1lKSB7 CiAgICAgICAgICAgICBmaWxlbmFtZSA9IGFyZ3Zbb3B0aW5kXTsKICAgICAg ICAgfSBlbHNlIHsKICAgICAgICAgICAgIGhlbHAoImNyZWF0ZSIpOworICAg ICAgICAgICAgZnJlZShkb21faW5mby5leHRyYV9jb25maWcpOwogICAgICAg ICAgICAgcmV0dXJuIDI7CiAgICAgICAgIH0KICAgICB9CiAKLSAgICBtZW1z ZXQoJmRvbV9pbmZvLCAwLCBzaXplb2YoZG9tX2luZm8pKTsKICAgICBkb21f aW5mby5kZWJ1ZyA9IGRlYnVnOwogICAgIGRvbV9pbmZvLmRhZW1vbml6ZSA9 IGRhZW1vbml6ZTsKICAgICBkb21faW5mby5tb25pdG9yID0gbW9uaXRvcjsK QEAgLTQ4ODQsMTYgKzQ5MDEsMTggQEAgaW50IG1haW5fY3JlYXRlKGludCBh cmdjLCBjaGFyICoqYXJndikKICAgICBkb21faW5mby5kcnlydW4gPSBkcnly dW5fb25seTsKICAgICBkb21faW5mby5xdWlldCA9IHF1aWV0OwogICAgIGRv bV9pbmZvLmNvbmZpZ19maWxlID0gZmlsZW5hbWU7Ci0gICAgZG9tX2luZm8u ZXh0cmFfY29uZmlnID0gZXh0cmFfY29uZmlnOwogICAgIGRvbV9pbmZvLm1p Z3JhdGVfZmQgPSAtMTsKICAgICBkb21faW5mby52bmMgPSB2bmM7CiAgICAg ZG9tX2luZm8udm5jYXV0b3Bhc3MgPSB2bmNhdXRvcGFzczsKICAgICBkb21f aW5mby5jb25zb2xlX2F1dG9jb25uZWN0ID0gY29uc29sZV9hdXRvY29ubmVj dDsKIAogICAgIHJjID0gY3JlYXRlX2RvbWFpbigmZG9tX2luZm8pOwotICAg IGlmIChyYyA8IDApCisgICAgaWYgKHJjIDwgMCkgeworICAgICAgICBmcmVl KGRvbV9pbmZvLmV4dHJhX2NvbmZpZyk7CiAgICAgICAgIHJldHVybiAtcmM7 CisgICAgfQogCisgICAgZnJlZShkb21faW5mby5leHRyYV9jb25maWcpOwog ICAgIHJldHVybiAwOwogfQogCkBAIC00OTAxLDggKzQ5MjAsNyBAQCBpbnQg bWFpbl9jb25maWdfdXBkYXRlKGludCBhcmdjLCBjaGFyICoqYXJndikKIHsK ICAgICB1aW50MzJfdCBkb21pZDsKICAgICBjb25zdCBjaGFyICpmaWxlbmFt ZSA9IE5VTEw7Ci0gICAgY2hhciAqcDsKLSAgICBjaGFyIGV4dHJhX2NvbmZp Z1sxMDI0XTsKKyAgICBjaGFyICpleHRyYV9jb25maWcgPSBOVUxMOwogICAg IHZvaWQgKmNvbmZpZ19kYXRhID0gMDsKICAgICBpbnQgY29uZmlnX2xlbiA9 IDA7CiAgICAgbGlieGxfZG9tYWluX2NvbmZpZyBkX2NvbmZpZzsKQEAgLTQ5 NDAsMTUgKzQ5NTgsMTUgQEAgaW50IG1haW5fY29uZmlnX3VwZGF0ZShpbnQg YXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIGJyZWFrOwogICAgIH0KIAot ICAgIGV4dHJhX2NvbmZpZ1swXSA9ICdcMCc7Ci0gICAgZm9yIChwID0gZXh0 cmFfY29uZmlnOyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgeworICAgIGZv ciAoOyBvcHRpbmQgPCBhcmdjOyBvcHRpbmQrKykgewogICAgICAgICBpZiAo c3RyY2hyKGFyZ3Zbb3B0aW5kXSwgJz0nKSAhPSBOVUxMKSB7Ci0gICAgICAg ICAgICBwICs9IHNucHJpbnRmKHAsIHNpemVvZihleHRyYV9jb25maWcpIC0g KHAgLSBleHRyYV9jb25maWcpLAotICAgICAgICAgICAgICAgICIlc1xuIiwg YXJndltvcHRpbmRdKTsKKyAgICAgICAgICAgIHN0cmluZ19yZWFsbG9jX2Fw cGVuZCgmZXh0cmFfY29uZmlnLCBhcmd2W29wdGluZF0pOworICAgICAgICAg ICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25maWcsICJcbiIp OwogICAgICAgICB9IGVsc2UgaWYgKCFmaWxlbmFtZSkgewogICAgICAgICAg ICAgZmlsZW5hbWUgPSBhcmd2W29wdGluZF07CiAgICAgICAgIH0gZWxzZSB7 CiAgICAgICAgICAgICBoZWxwKCJjcmVhdGUiKTsKKyAgICAgICAgICAgIGZy ZWUoZXh0cmFfY29uZmlnKTsKICAgICAgICAgICAgIHJldHVybiAyOwogICAg ICAgICB9CiAgICAgfQpAQCAtNDk1Nyw3ICs0OTc1LDggQEAgaW50IG1haW5f Y29uZmlnX3VwZGF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAg IHJjID0gbGlieGxfcmVhZF9maWxlX2NvbnRlbnRzKGN0eCwgZmlsZW5hbWUs CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZjb25m aWdfZGF0YSwgJmNvbmZpZ19sZW4pOwogICAgICAgICBpZiAocmMpIHsgZnBy aW50ZihzdGRlcnIsICJGYWlsZWQgdG8gcmVhZCBjb25maWcgZmlsZTogJXM6 ICVzXG4iLAotICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsZW5hbWUs IHN0cmVycm9yKGVycm5vKSk7IHJldHVybiBFUlJPUl9GQUlMOyB9CisgICAg ICAgICAgICAgICAgICAgICAgICAgICBmaWxlbmFtZSwgc3RyZXJyb3IoZXJy bm8pKTsKKyAgICAgICAgICAgICAgICAgIGZyZWUoZXh0cmFfY29uZmlnKTsg cmV0dXJuIEVSUk9SX0ZBSUw7IH0KICAgICAgICAgaWYgKHN0cmxlbihleHRy YV9jb25maWcpKSB7CiAgICAgICAgICAgICBpZiAoY29uZmlnX2xlbiA+IElO VF9NQVggLSAoc3RybGVuKGV4dHJhX2NvbmZpZykgKyAyICsgMSkpIHsKICAg ICAgICAgICAgICAgICBmcHJpbnRmKHN0ZGVyciwgIkZhaWxlZCB0byBhdHRh Y2ggZXh0cmEgY29uZmlncmF0aW9uXG4iKTsKQEAgLTQ5OTgsNyArNTAxNyw3 IEBAIGludCBtYWluX2NvbmZpZ191cGRhdGUoaW50IGFyZ2MsIGNoYXIgKiph cmd2KQogICAgIGxpYnhsX2RvbWFpbl9jb25maWdfZGlzcG9zZSgmZF9jb25m aWcpOwogCiAgICAgZnJlZShjb25maWdfZGF0YSk7Ci0KKyAgICBmcmVlKGV4 dHJhX2NvbmZpZyk7CiAgICAgcmV0dXJuIDA7CiB9CiAKQEAgLTcyNTUsNyAr NzI3NCw3IEBAIGludCBtYWluX2NwdXBvb2xjcmVhdGUoaW50IGFyZ2MsIGNo YXIgKiphcmd2KQogewogICAgIGNvbnN0IGNoYXIgKmZpbGVuYW1lID0gTlVM TCwgKmNvbmZpZ19zcmM9TlVMTDsKICAgICBjb25zdCBjaGFyICpwOwotICAg IGNoYXIgZXh0cmFfY29uZmlnWzEwMjRdOworICAgIGNoYXIgKmV4dHJhX2Nv bmZpZyA9IE5VTEw7CiAgICAgaW50IG9wdDsKICAgICBzdGF0aWMgc3RydWN0 IG9wdGlvbiBvcHRzW10gPSB7CiAgICAgICAgIHsiZGVmY29uZmlnIiwgMSwg MCwgJ2YnfSwKQEAgLTcyODksMTMgKzczMDgsMTAgQEAgaW50IG1haW5fY3B1 cG9vbGNyZWF0ZShpbnQgYXJnYywgY2hhciAqKmFyZ3YpCiAgICAgICAgIGJy ZWFrOwogICAgIH0KIAotICAgIG1lbXNldChleHRyYV9jb25maWcsIDAsIHNp emVvZihleHRyYV9jb25maWcpKTsKICAgICB3aGlsZSAob3B0aW5kIDwgYXJn YykgewogICAgICAgICBpZiAoKHAgPSBzdHJjaHIoYXJndltvcHRpbmRdLCAn PScpKSkgewotICAgICAgICAgICAgaWYgKHN0cmxlbihleHRyYV9jb25maWcp ICsgMSArIHN0cmxlbihhcmd2W29wdGluZF0pIDwgc2l6ZW9mKGV4dHJhX2Nv bmZpZykpIHsKLSAgICAgICAgICAgICAgICBzdHJjYXQoZXh0cmFfY29uZmln LCAiXG4iKTsKLSAgICAgICAgICAgICAgICBzdHJjYXQoZXh0cmFfY29uZmln LCBhcmd2W29wdGluZF0pOwotICAgICAgICAgICAgfQorICAgICAgICAgICAg c3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25maWcsICJcbiIpOwor ICAgICAgICAgICAgc3RyaW5nX3JlYWxsb2NfYXBwZW5kKCZleHRyYV9jb25m aWcsIGFyZ3Zbb3B0aW5kXSk7CiAgICAgICAgIH0gZWxzZSBpZiAoIWZpbGVu YW1lKSB7CiAgICAgICAgICAgICBmaWxlbmFtZSA9IGFyZ3Zbb3B0aW5kXTsK ICAgICAgICAgfSBlbHNlIHsKLS0gCjEuNy4xMC40Cgo= --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Tue Jul 07 13:56:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 13:56:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTKu-0000VB-Qh; Tue, 07 Jul 2015 13:55:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTKt-0000Uw-U8 for xen-users@lists.xen.org; Tue, 07 Jul 2015 13:55:00 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 6B/23-15949-33ADB955; Tue, 07 Jul 2015 13:54:59 +0000 X-Env-Sender: prvs=62306e0f2=julien.grall@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1436277295!11917135!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24830 invoked from network); 7 Jul 2015 13:54:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2015 13:54:58 -0000 X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208";a="281743112" Message-ID: <559BD9EF.4060902@citrix.com> Date: Tue, 7 Jul 2015 14:53:51 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> In-Reply-To: <559AB900.3050403@ti.com> X-DLP: MIA2 Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 06/07/15 18:21, Brandon Perez wrote: > On 07/03/2015 06:30 AM, Julien Grall wrote: >> Hi, >> >> On 02/07/15 17:04, Brandon Perez wrote: >>> >>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>> (d1) Grant table initialized >>> (d1) 6xen:events: Using FIFO-based ABI >>> (d1) 6Xen: initializing cpu0 >>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >> >> It's hard to know what's going on with only these 5 lines. Is it the >> full log of the domU? If not, can you send it? >> >> Usually, the next step is to bring up the other processor, although you >> have only 1 vCPU in the device tree. >> >> Regards, >> > > Hi Julien, > > Unfortunately, that is the full log of the domU messages that I get > from "xl dmesg". That's part of the reason why I'm having a hard time > tracking down this issue, because I'm getting so little information back > from the guest. > > There's also the domU.log file that I attached in the prior email > that has additional information. > > Do you have any advice what might be causing this issue just based on > that information? Not really. Can you try patch in [0]? It should print more on the console compare to the one you applied from [1]. You may also want to add ignore_loglevel on kernel guest command line. Regards, [0] https://patches.linaro.org/39687/ [1] http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 13:56:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 13:56:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTKu-0000VB-Qh; Tue, 07 Jul 2015 13:55:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTKt-0000Uw-U8 for xen-users@lists.xen.org; Tue, 07 Jul 2015 13:55:00 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 6B/23-15949-33ADB955; Tue, 07 Jul 2015 13:54:59 +0000 X-Env-Sender: prvs=62306e0f2=julien.grall@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1436277295!11917135!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24830 invoked from network); 7 Jul 2015 13:54:58 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2015 13:54:58 -0000 X-IronPort-AV: E=Sophos;i="5.15,423,1432598400"; d="scan'208";a="281743112" Message-ID: <559BD9EF.4060902@citrix.com> Date: Tue, 7 Jul 2015 14:53:51 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> In-Reply-To: <559AB900.3050403@ti.com> X-DLP: MIA2 Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 06/07/15 18:21, Brandon Perez wrote: > On 07/03/2015 06:30 AM, Julien Grall wrote: >> Hi, >> >> On 02/07/15 17:04, Brandon Perez wrote: >>> >>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>> (d1) Grant table initialized >>> (d1) 6xen:events: Using FIFO-based ABI >>> (d1) 6Xen: initializing cpu0 >>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >> >> It's hard to know what's going on with only these 5 lines. Is it the >> full log of the domU? If not, can you send it? >> >> Usually, the next step is to bring up the other processor, although you >> have only 1 vCPU in the device tree. >> >> Regards, >> > > Hi Julien, > > Unfortunately, that is the full log of the domU messages that I get > from "xl dmesg". That's part of the reason why I'm having a hard time > tracking down this issue, because I'm getting so little information back > from the guest. > > There's also the domU.log file that I attached in the prior email > that has additional information. > > Do you have any advice what might be causing this issue just based on > that information? Not really. Can you try patch in [0]? It should print more on the console compare to the one you applied from [1]. You may also want to add ignore_loglevel on kernel guest command line. Regards, [0] https://patches.linaro.org/39687/ [1] http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 14:37:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 14:37:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTyV-0004qJ-Id; Tue, 07 Jul 2015 14:35:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTyU-0004qB-89 for xen-users@lists.xen.org; Tue, 07 Jul 2015 14:35:54 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 49/6E-21300-9C3EB955; Tue, 07 Jul 2015 14:35:53 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436279751!29993597!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4408 invoked from network); 7 Jul 2015 14:35:52 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 14:35:52 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67EZmTg029642; Tue, 7 Jul 2015 09:35:48 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67EZmCe028378; Tue, 7 Jul 2015 09:35:48 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 09:35:34 -0500 Message-ID: <559BD5B5.70308@ti.com> Date: Tue, 7 Jul 2015 09:35:49 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> In-Reply-To: <559BD9EF.4060902@citrix.com> Content-Type: multipart/mixed; boundary="------------050309060601090009080305" X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------050309060601090009080305 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 07/07/2015 09:53 AM, Julien Grall wrote: > Hi, > > On 06/07/15 18:21, Brandon Perez wrote: >> On 07/03/2015 06:30 AM, Julien Grall wrote: >>> Hi, >>> >>> On 02/07/15 17:04, Brandon Perez wrote: >>>> >>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>> (d1) Grant table initialized >>>> (d1) 6xen:events: Using FIFO-based ABI >>>> (d1) 6Xen: initializing cpu0 >>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>> >>> It's hard to know what's going on with only these 5 lines. Is it the >>> full log of the domU? If not, can you send it? >>> >>> Usually, the next step is to bring up the other processor, although you >>> have only 1 vCPU in the device tree. >>> >>> Regards, >>> >> >> Hi Julien, >> >> Unfortunately, that is the full log of the domU messages that I get >> from "xl dmesg". That's part of the reason why I'm having a hard time >> tracking down this issue, because I'm getting so little information back >> from the guest. >> >> There's also the domU.log file that I attached in the prior email >> that has additional information. >> >> Do you have any advice what might be causing this issue just based on >> that information? > > Not really. Can you try patch in [0]? It should print more on the > console compare to the one you applied from [1]. > > You may also want to add ignore_loglevel on kernel guest command line. > > Regards, > > [0] https://patches.linaro.org/39687/ > [1] > http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb > Hi Julien, I added applied patch [0], and I've attached the logging output that I got with that patch. Nothing in the log really jumps out at me, and the kernel seems to be booting fine until it freezes up for some reason. Is it possible that I'm not setting up the DomU's filesystem correctly? I'm currently using a 800 Mb image on the Dom0 filesystem that's formatted as ext3. Do I need to mount this somewhere on Dom0's filesystem before running "xl create"? I could see this as a potential reason for the guest domain to freeze up. Brandon --------------050309060601090009080305 Content-Type: text/x-log; name="guest_dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="guest_dmesg.log" (d1) Entered the kernel (d1) 6Booting Linux on physical CPU 0x0 (d1) 5Linux version 3.14.31-dirty (brandonlocal@brandonlocal-PORTEGE-R830) (gcc version 4.6.3 (UbuntuS (d1) MP PREEMPT Tue Jul 7 09:20:42 EDT 2015 (d1) 6CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c7387d (d1) 6CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache (d1) 6Machine model: XENVM-4.6 (d1) 6debug: ignoring loglevel setting. (d1) 6cma: CMA: reserved 24 MiB at 46400000 (d1) 6Memory policy: Data cache writealloc (d1) 7On node 0 totalpages: 32768 (d1) 7free_area_init_node: node 0, pgdat c088b140, node_mem_map c7eee000 (d1) 7 Normal zone: 256 pages used for memmap (d1) 7 Normal zone: 0 pages reserved (d1) 7 Normal zone: 32768 pages, LIFO batch:7 (d1) 6psci: probing function IDs from device-tree (d1) 6PERCPU: Embedded 8 pages/cpu @c7ee3000 s9728 r8192 d14848 u32768 (d1) 7pcpu-alloc: s9728 r8192 d14848 u32768 alloc=8*4096 (d1) 7pcpu-alloc: (d1) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 (d1) 5Kernel command line: console=hvc0 root=/dev/xvda rw earlyprintk=xen debug ignore_loglevel (d1) 6PID hash table entries: 512 (order: -1, 2048 bytes) (d1) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) (d1) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) (d1) Memory: 96252K/131072K available (6087K kernel code, 338K rwdata, 1972K rodata, 313K init, 270K e (d1) m) (d1) 5Virtual kernel memory layout: (d1) vector : 0xffff0000 - 0xffff1000 ( 4 kB) (d1) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) (d1) vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) (d1) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) (d1) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) (d1) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) (d1) .text : 0xc0008000 - 0xc07e7064 (8061 kB) (d1) .init : 0xc07e8000 - 0xc0836600 ( 314 kB) (d1) .data : 0xc0838000 - 0xc088ca20 ( 339 kB) (d1) .bss : 0xc088ca2c - 0xc08d02c4 ( 271 kB) (d1) 6Preemptible hierarchical RCU implementation. (d1) 6 RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. (d1) 6RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 (d1) 6NR_IRQS:16 nr_irqs:16 16 (d1) 6Architected cp15 timer(s) running at 6.14MHz (virt). (d1) 6sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 2794592043008ns (d1) 6Switching to timer-based delay loop (d1) 6Console: colour dummy device 80x30 (d1) 6Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=) (d1) 6pid_max: default: 32768 minimum: 301 (d1) 6Security Framework initialized (d1) 6Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) (d1) 6Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) (d1) 6CPU: Testing write buffer coherency: ok (d1) 3/cpus/cpu@0 missing clock-frequency property (d1) 6CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 (d1) 6Xen 4.6 support found, events_irq=31 gnttab_frame=0x0000000038000000 (d1) 6xen:grant_table: Grant tables using version 1 layout (d1) Grant table initialized (d1) 6xen:events: Using FIFO-based ABI (d1) 6Xen: initializing cpu0 (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 --------------050309060601090009080305 Content-Type: text/x-log; name="xl-domU.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl-domU.log" Waiting for domain domU (domid 2) to die [pid 2476] Domain 2 has been destroyed. --------------050309060601090009080305 Content-Type: text/plain; charset="UTF-8"; name="domU.cfg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="domU.cfg" kernel = "/root/zImage" memory = 128 name = "domU" vcpus = 1 disk = ['phy:/dev/loop0,xvda,w'] serial = "hvc0" extra = "console=hvc0 root=/dev/xvda rw earlyprintk=xen debug ignore_loglevel" --------------050309060601090009080305 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------050309060601090009080305-- From xen-users-bounces@lists.xen.org Tue Jul 07 14:37:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 14:37:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTyV-0004qJ-Id; Tue, 07 Jul 2015 14:35:55 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCTyU-0004qB-89 for xen-users@lists.xen.org; Tue, 07 Jul 2015 14:35:54 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 49/6E-21300-9C3EB955; Tue, 07 Jul 2015 14:35:53 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436279751!29993597!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4408 invoked from network); 7 Jul 2015 14:35:52 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 14:35:52 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67EZmTg029642; Tue, 7 Jul 2015 09:35:48 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67EZmCe028378; Tue, 7 Jul 2015 09:35:48 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 09:35:34 -0500 Message-ID: <559BD5B5.70308@ti.com> Date: Tue, 7 Jul 2015 09:35:49 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> In-Reply-To: <559BD9EF.4060902@citrix.com> Content-Type: multipart/mixed; boundary="------------050309060601090009080305" X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------050309060601090009080305 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit On 07/07/2015 09:53 AM, Julien Grall wrote: > Hi, > > On 06/07/15 18:21, Brandon Perez wrote: >> On 07/03/2015 06:30 AM, Julien Grall wrote: >>> Hi, >>> >>> On 02/07/15 17:04, Brandon Perez wrote: >>>> >>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>> (d1) Grant table initialized >>>> (d1) 6xen:events: Using FIFO-based ABI >>>> (d1) 6Xen: initializing cpu0 >>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>> >>> It's hard to know what's going on with only these 5 lines. Is it the >>> full log of the domU? If not, can you send it? >>> >>> Usually, the next step is to bring up the other processor, although you >>> have only 1 vCPU in the device tree. >>> >>> Regards, >>> >> >> Hi Julien, >> >> Unfortunately, that is the full log of the domU messages that I get >> from "xl dmesg". That's part of the reason why I'm having a hard time >> tracking down this issue, because I'm getting so little information back >> from the guest. >> >> There's also the domU.log file that I attached in the prior email >> that has additional information. >> >> Do you have any advice what might be causing this issue just based on >> that information? > > Not really. Can you try patch in [0]? It should print more on the > console compare to the one you applied from [1]. > > You may also want to add ignore_loglevel on kernel guest command line. > > Regards, > > [0] https://patches.linaro.org/39687/ > [1] > http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb > Hi Julien, I added applied patch [0], and I've attached the logging output that I got with that patch. Nothing in the log really jumps out at me, and the kernel seems to be booting fine until it freezes up for some reason. Is it possible that I'm not setting up the DomU's filesystem correctly? I'm currently using a 800 Mb image on the Dom0 filesystem that's formatted as ext3. Do I need to mount this somewhere on Dom0's filesystem before running "xl create"? I could see this as a potential reason for the guest domain to freeze up. Brandon --------------050309060601090009080305 Content-Type: text/x-log; name="guest_dmesg.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="guest_dmesg.log" (d1) Entered the kernel (d1) 6Booting Linux on physical CPU 0x0 (d1) 5Linux version 3.14.31-dirty (brandonlocal@brandonlocal-PORTEGE-R830) (gcc version 4.6.3 (UbuntuS (d1) MP PREEMPT Tue Jul 7 09:20:42 EDT 2015 (d1) 6CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c7387d (d1) 6CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache (d1) 6Machine model: XENVM-4.6 (d1) 6debug: ignoring loglevel setting. (d1) 6cma: CMA: reserved 24 MiB at 46400000 (d1) 6Memory policy: Data cache writealloc (d1) 7On node 0 totalpages: 32768 (d1) 7free_area_init_node: node 0, pgdat c088b140, node_mem_map c7eee000 (d1) 7 Normal zone: 256 pages used for memmap (d1) 7 Normal zone: 0 pages reserved (d1) 7 Normal zone: 32768 pages, LIFO batch:7 (d1) 6psci: probing function IDs from device-tree (d1) 6PERCPU: Embedded 8 pages/cpu @c7ee3000 s9728 r8192 d14848 u32768 (d1) 7pcpu-alloc: s9728 r8192 d14848 u32768 alloc=8*4096 (d1) 7pcpu-alloc: (d1) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 (d1) 5Kernel command line: console=hvc0 root=/dev/xvda rw earlyprintk=xen debug ignore_loglevel (d1) 6PID hash table entries: 512 (order: -1, 2048 bytes) (d1) 6Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) (d1) 6Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) (d1) Memory: 96252K/131072K available (6087K kernel code, 338K rwdata, 1972K rodata, 313K init, 270K e (d1) m) (d1) 5Virtual kernel memory layout: (d1) vector : 0xffff0000 - 0xffff1000 ( 4 kB) (d1) fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB) (d1) vmalloc : 0xc8800000 - 0xff000000 ( 872 MB) (d1) lowmem : 0xc0000000 - 0xc8000000 ( 128 MB) (d1) pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB) (d1) modules : 0xbf000000 - 0xbfe00000 ( 14 MB) (d1) .text : 0xc0008000 - 0xc07e7064 (8061 kB) (d1) .init : 0xc07e8000 - 0xc0836600 ( 314 kB) (d1) .data : 0xc0838000 - 0xc088ca20 ( 339 kB) (d1) .bss : 0xc088ca2c - 0xc08d02c4 ( 271 kB) (d1) 6Preemptible hierarchical RCU implementation. (d1) 6 RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. (d1) 6RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 (d1) 6NR_IRQS:16 nr_irqs:16 16 (d1) 6Architected cp15 timer(s) running at 6.14MHz (virt). (d1) 6sched_clock: 56 bits at 6MHz, resolution 162ns, wraps every 2794592043008ns (d1) 6Switching to timer-based delay loop (d1) 6Console: colour dummy device 80x30 (d1) 6Calibrating delay loop (skipped), value calculated using timer frequency.. 12.29 BogoMIPS (lpj=) (d1) 6pid_max: default: 32768 minimum: 301 (d1) 6Security Framework initialized (d1) 6Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) (d1) 6Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) (d1) 6CPU: Testing write buffer coherency: ok (d1) 3/cpus/cpu@0 missing clock-frequency property (d1) 6CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 (d1) 6Xen 4.6 support found, events_irq=31 gnttab_frame=0x0000000038000000 (d1) 6xen:grant_table: Grant tables using version 1 layout (d1) Grant table initialized (d1) 6xen:events: Using FIFO-based ABI (d1) 6Xen: initializing cpu0 (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 --------------050309060601090009080305 Content-Type: text/x-log; name="xl-domU.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xl-domU.log" Waiting for domain domU (domid 2) to die [pid 2476] Domain 2 has been destroyed. --------------050309060601090009080305 Content-Type: text/plain; charset="UTF-8"; name="domU.cfg" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="domU.cfg" kernel = "/root/zImage" memory = 128 name = "domU" vcpus = 1 disk = ['phy:/dev/loop0,xvda,w'] serial = "hvc0" extra = "console=hvc0 root=/dev/xvda rw earlyprintk=xen debug ignore_loglevel" --------------050309060601090009080305 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------050309060601090009080305-- From xen-users-bounces@lists.xen.org Tue Jul 07 15:50:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 15:50:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCV8F-0000MH-Km; Tue, 07 Jul 2015 15:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCV8D-0000Lo-P8 for Xen-users@lists.xen.org; Tue, 07 Jul 2015 15:50:02 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id BF/C0-05081-925FB955; Tue, 07 Jul 2015 15:50:01 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1436284198!19569097!1 X-Originating-IP: [98.138.229.120] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8671 invoked from network); 7 Jul 2015 15:49:59 -0000 Received: from nm36-vm8.bullet.mail.ne1.yahoo.com (HELO nm36-vm8.bullet.mail.ne1.yahoo.com) (98.138.229.120) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2015 15:49:59 -0000 Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:49:58 -0000 Received: from [98.138.100.103] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 Received: from [98.138.88.238] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 75305.90513.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 65330 invoked by uid 60001); 7 Jul 2015 15:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1436284029; bh=pZMN/onv4na/51v6cmjaJaw9JEk4horjen8Vo1SrT9I=; h=Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dbE+UssO5wqEQO0aQO0taa9qOV3FzFB5CVyytS6NiXKLXZhwwmpGXAoKYGMdPeIgLnZR7pB6C2FdFbyQcFm1Fobpl4zwWx+gSxfvmhz6IR3BmXwrxKnxMT0BzfNpNuG07g6oTMR2UnQZZxla5Q9ufizQsrWIZRnqBjBBdBRZtAE= X-YMail-OSG: DdMt_MAVM1nFA3gqIblHQjkQxJtJdPtB0oK1idHCnO4kXHP BX0GPtDN7FumazCA.kgAvMM1qP7KKEoA7fyRTQ.xZFUeI2tQCIVUfTm1amur hDZIdEPNXwiiWbNQv6InIIqPc.Y321h7W16hWulexdVqnMn.8MxsfCgIM1n5 UmH8s7rRMdjygwIDFOesD9J8tJxpTh0v2ndy5cIvTKqBGIkdY8vKT94oFds5 EbGIhWgimxsyfYECX6T3eoxR81p3STTBN8Pl.X7eQ6VcvNrnsjS3UfOWsSKP dfRHTwU15SvMfgtIkeKqxZZq91gEE5xS4GQZi5OO_C_31bsh17FEsMfP.6er smixLTv7BsUXBNh.jwIPcUC32Lzn85S.o65Brz794UOPLeebaJcWxL8l542w n4z.D1F0XUwm8fDefh8SXhwUhYtC0N96LxiI1qZnM.JVV9PSGKAnng9dD.Gf kKC_telIU1LM3tnMlSBzCszQjrOaI7G5b4bYQCtX7RpbXWebSNfxkF1dRcmZ 9bdnwzjvHGDf43tRF8SoXwRhxPAW3KPmwujZM.azu_YgzE0vASTtzwVKnAYT 9YG345BaSChvmz9UCNQ0- Received: from [50.139.49.118] by web310202.mail.ne1.yahoo.com via HTTP; Tue, 07 Jul 2015 08:47:08 PDT X-Rocket-MIMEInfo: 002.001, CgpGcm9tOiJTYXJhaCBOZXdtYW4iIDxzcm5AcHJnbXIuY29tPgpEYXRlOkZyaSwgSnVsIDMsIDIwMTUgYXQgNDowOCBQTQpTdWJqZWN0OlJlOiBbWGVuLXVzZXJzXSBDb25uZWN0aW5nIERvbTAgdG8gdGhlIEhvc3QncyBTZXJpYWwgUG9ydD8KCk9uIDA3LzAzLzIwMTUgMDM6NDMgUE0sIEVyaWMgd3JvdGU6CgoKPiBIZWxsbywgQWxsOgo.IAo.IEkgaGF2ZSBhIGZhaXJseSBzaW1wbGUgcXVlc3Rpb24uIEJlZm9yZSBJIGluc3RhbGxlZCBYZW4gb24gbXkgQ2VudE9TIDYuNiBob3N0LCBJJ2QgYWRkZWQgc29tZSABMAEBAQE- X-Mailer: YahooMailAndroidMobile/4.9.2 YahooMailWebService/0.8.203.802 Message-ID: <1436284028.49278.YahooMailAndroidMobile@web310202.mail.ne1.yahoo.com> Date: Tue, 7 Jul 2015 08:47:08 -0700 From: Eric To: Sarah Newman , "Xen-users@lists.xen.org" In-Reply-To: <559715CF.7010805@prgmr.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4027676381771101923==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4027676381771101923== Content-Type: multipart/alternative; boundary="-28653412-968517250-1436284028=:49278" ---28653412-968517250-1436284028=:49278 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AFrom:"Sarah Newman" =0ADate:Fri, Jul 3, 2015 at 4:08 P= M=0ASubject:Re: [Xen-users] Connecting Dom0 to the Host's Serial Port?=0A= =0AOn 07/03/2015 03:43 PM, Eric wrote:=0A=0A=0A> Hello, All:=0A> =0A> I hav= e a fairly simple question. Before I installed Xen on my CentOS 6.6 host, I= 'd added some configuration to the Grub configuration file=0A> (/boot/grub/= menu.lst) to allow access via the serial-console server:=0A> =0A>> default= =3D0=0A>> timeout=3D5=0A>> splashimage=3D(hd0,0)/grub/splash.xpm.gz=0A>> se= rial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1=0A>> t= erminal --timeout=3D5 serial console=0A>> ...=0A>> kernel /vmlinuz-2.6.32-5= 04.1.3.el6.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8=0A> = =0A> This seemed to work well until I added the stanzas to load Xen:=0A> = =0A>> title CentOS (3.10.68-11.el6.centos.alt.x86_64)=0A>>=A0 =A0 root (hd0= ,0)=0A>>=A0 =A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall gues= t_loglvl=3Dall=0A>>=A0 =A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64= ro ... quiet console=3Dtty0 console=3DttyS0,115200n8=0A>>=A0 =A0 module /i= nitramfs-3.10.68-11.el6.centos.alt.x86_64.img=0A> =0A> Now I'm able to view= /interact with the host's BIOS; the Grub boot menu, and; I'm able to watch = the initial portion of the boot process. However, after=0A> the xend starts= I'm no longer able to view or to interact with Dom0.=0A> =0A> How can I gr= ant Dom0 permanent access to the serial-console port of the host [hardware]= ?=0A=0A=0A=0Ayou probably want=0A=A0=A0=A0 kernel /boot/xen.gz com1=3D11520= 0,8n1 console=3Dcom1=0A=A0=A0=A0 module /boot/vmlinuz-3.10.68-11.el6.centos= .alt.x86_64 console=3Dhvc0=0A=0A=0AThank you, Sarah!=0A=0A=0AEric Pretoriou= s=0A=0APortland, OR=0A=0A ---28653412-968517250-1436284028=:49278 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


From:"Sarah Newman= " <srn@prgmr.com>
Date:Fri, Jul 3, 2015 at 4:08 PM
Su= bject:Re: [Xen-users] Connecting Dom0 to the Host's Serial Port?
On= 07/03/2015 03:43 PM, Eric wrote:

> Hello, All:
> =
> I have a fairly simple question. Before I installed= Xen on my CentOS 6.6 host, I'd added some configuration to the Grub config= uration file
> (/boot/grub/menu.lst) to allow access via the serial-console server:
>
>> default=3D0
>> timeout=3D5
>> splashimage=3D(hd0,0)/grub= /splash.xpm.gz
>> serial --unit=3D1 --speed=3D11520= 0 --word=3D8 --parity=3Dno --stop=3D1
>> terminal -= -timeout=3D5 serial console
>> ...
>> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console= =3Dtty0 console=3DttyS0,115200n8
>
= > This seemed to work well until I added the stanzas to load Xen:
>
>> title CentOS (3.10.68-11.el6.c= entos.alt.x86_64)
>>    root (hd0,0)
>>    kernel /xen.gz dom0_mem=3D1024M,max:102= 4M loglvl=3Dall guest_loglvl=3Dall
>>    = module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>&g= t;    module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img
>
> Now I'm able to view/interact wi= th the host's BIOS; the Grub boot menu, and; I'm able to watch the initial = portion of the boot process. However, after
> the xend= starts I'm no longer able to view or to interact with Dom0.
>
> How can I grant Dom0 permanent access to t= he serial-console port of the host [hardware]?


you probably want
    kerne= l /boot/xen.gz com1=3D115200,8n1 console=3Dcom1
 &nb= sp;  module /boot/vmlinuz-3.10.68-11.el6.centos.alt.x86_64 console=3Dh= vc0

Thank you, Sarah!

Eric Pretorious
Portland, OR
=
---28653412-968517250-1436284028=:49278-- --===============4027676381771101923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4027676381771101923==-- From xen-users-bounces@lists.xen.org Tue Jul 07 15:50:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 15:50:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCV8F-0000MH-Km; Tue, 07 Jul 2015 15:50:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCV8D-0000Lo-P8 for Xen-users@lists.xen.org; Tue, 07 Jul 2015 15:50:02 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id BF/C0-05081-925FB955; Tue, 07 Jul 2015 15:50:01 +0000 X-Env-Sender: epretorious@yahoo.com X-Msg-Ref: server-7.tower-206.messagelabs.com!1436284198!19569097!1 X-Originating-IP: [98.138.229.120] X-SpamReason: No, hits=0.1 required=7.0 tests=HTML_50_60,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8671 invoked from network); 7 Jul 2015 15:49:59 -0000 Received: from nm36-vm8.bullet.mail.ne1.yahoo.com (HELO nm36-vm8.bullet.mail.ne1.yahoo.com) (98.138.229.120) by server-7.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 7 Jul 2015 15:49:59 -0000 Received: from [127.0.0.1] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:49:58 -0000 Received: from [98.138.100.103] by nm36.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 Received: from [98.138.88.238] by tm102.bullet.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 07 Jul 2015 15:47:09 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 75305.90513.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 65330 invoked by uid 60001); 7 Jul 2015 15:47:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1436284029; bh=pZMN/onv4na/51v6cmjaJaw9JEk4horjen8Vo1SrT9I=; h=Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dbE+UssO5wqEQO0aQO0taa9qOV3FzFB5CVyytS6NiXKLXZhwwmpGXAoKYGMdPeIgLnZR7pB6C2FdFbyQcFm1Fobpl4zwWx+gSxfvmhz6IR3BmXwrxKnxMT0BzfNpNuG07g6oTMR2UnQZZxla5Q9ufizQsrWIZRnqBjBBdBRZtAE= X-YMail-OSG: DdMt_MAVM1nFA3gqIblHQjkQxJtJdPtB0oK1idHCnO4kXHP BX0GPtDN7FumazCA.kgAvMM1qP7KKEoA7fyRTQ.xZFUeI2tQCIVUfTm1amur hDZIdEPNXwiiWbNQv6InIIqPc.Y321h7W16hWulexdVqnMn.8MxsfCgIM1n5 UmH8s7rRMdjygwIDFOesD9J8tJxpTh0v2ndy5cIvTKqBGIkdY8vKT94oFds5 EbGIhWgimxsyfYECX6T3eoxR81p3STTBN8Pl.X7eQ6VcvNrnsjS3UfOWsSKP dfRHTwU15SvMfgtIkeKqxZZq91gEE5xS4GQZi5OO_C_31bsh17FEsMfP.6er smixLTv7BsUXBNh.jwIPcUC32Lzn85S.o65Brz794UOPLeebaJcWxL8l542w n4z.D1F0XUwm8fDefh8SXhwUhYtC0N96LxiI1qZnM.JVV9PSGKAnng9dD.Gf kKC_telIU1LM3tnMlSBzCszQjrOaI7G5b4bYQCtX7RpbXWebSNfxkF1dRcmZ 9bdnwzjvHGDf43tRF8SoXwRhxPAW3KPmwujZM.azu_YgzE0vASTtzwVKnAYT 9YG345BaSChvmz9UCNQ0- Received: from [50.139.49.118] by web310202.mail.ne1.yahoo.com via HTTP; Tue, 07 Jul 2015 08:47:08 PDT X-Rocket-MIMEInfo: 002.001, CgpGcm9tOiJTYXJhaCBOZXdtYW4iIDxzcm5AcHJnbXIuY29tPgpEYXRlOkZyaSwgSnVsIDMsIDIwMTUgYXQgNDowOCBQTQpTdWJqZWN0OlJlOiBbWGVuLXVzZXJzXSBDb25uZWN0aW5nIERvbTAgdG8gdGhlIEhvc3QncyBTZXJpYWwgUG9ydD8KCk9uIDA3LzAzLzIwMTUgMDM6NDMgUE0sIEVyaWMgd3JvdGU6CgoKPiBIZWxsbywgQWxsOgo.IAo.IEkgaGF2ZSBhIGZhaXJseSBzaW1wbGUgcXVlc3Rpb24uIEJlZm9yZSBJIGluc3RhbGxlZCBYZW4gb24gbXkgQ2VudE9TIDYuNiBob3N0LCBJJ2QgYWRkZWQgc29tZSABMAEBAQE- X-Mailer: YahooMailAndroidMobile/4.9.2 YahooMailWebService/0.8.203.802 Message-ID: <1436284028.49278.YahooMailAndroidMobile@web310202.mail.ne1.yahoo.com> Date: Tue, 7 Jul 2015 08:47:08 -0700 From: Eric To: Sarah Newman , "Xen-users@lists.xen.org" In-Reply-To: <559715CF.7010805@prgmr.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Connecting Dom0 to the Host's Serial Port? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4027676381771101923==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4027676381771101923== Content-Type: multipart/alternative; boundary="-28653412-968517250-1436284028=:49278" ---28653412-968517250-1436284028=:49278 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0AFrom:"Sarah Newman" =0ADate:Fri, Jul 3, 2015 at 4:08 P= M=0ASubject:Re: [Xen-users] Connecting Dom0 to the Host's Serial Port?=0A= =0AOn 07/03/2015 03:43 PM, Eric wrote:=0A=0A=0A> Hello, All:=0A> =0A> I hav= e a fairly simple question. Before I installed Xen on my CentOS 6.6 host, I= 'd added some configuration to the Grub configuration file=0A> (/boot/grub/= menu.lst) to allow access via the serial-console server:=0A> =0A>> default= =3D0=0A>> timeout=3D5=0A>> splashimage=3D(hd0,0)/grub/splash.xpm.gz=0A>> se= rial --unit=3D1 --speed=3D115200 --word=3D8 --parity=3Dno --stop=3D1=0A>> t= erminal --timeout=3D5 serial console=0A>> ...=0A>> kernel /vmlinuz-2.6.32-5= 04.1.3.el6.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8=0A> = =0A> This seemed to work well until I added the stanzas to load Xen:=0A> = =0A>> title CentOS (3.10.68-11.el6.centos.alt.x86_64)=0A>>=A0 =A0 root (hd0= ,0)=0A>>=A0 =A0 kernel /xen.gz dom0_mem=3D1024M,max:1024M loglvl=3Dall gues= t_loglvl=3Dall=0A>>=A0 =A0 module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64= ro ... quiet console=3Dtty0 console=3DttyS0,115200n8=0A>>=A0 =A0 module /i= nitramfs-3.10.68-11.el6.centos.alt.x86_64.img=0A> =0A> Now I'm able to view= /interact with the host's BIOS; the Grub boot menu, and; I'm able to watch = the initial portion of the boot process. However, after=0A> the xend starts= I'm no longer able to view or to interact with Dom0.=0A> =0A> How can I gr= ant Dom0 permanent access to the serial-console port of the host [hardware]= ?=0A=0A=0A=0Ayou probably want=0A=A0=A0=A0 kernel /boot/xen.gz com1=3D11520= 0,8n1 console=3Dcom1=0A=A0=A0=A0 module /boot/vmlinuz-3.10.68-11.el6.centos= .alt.x86_64 console=3Dhvc0=0A=0A=0AThank you, Sarah!=0A=0A=0AEric Pretoriou= s=0A=0APortland, OR=0A=0A ---28653412-968517250-1436284028=:49278 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


From:"Sarah Newman= " <srn@prgmr.com>
Date:Fri, Jul 3, 2015 at 4:08 PM
Su= bject:Re: [Xen-users] Connecting Dom0 to the Host's Serial Port?
On= 07/03/2015 03:43 PM, Eric wrote:

> Hello, All:
> =
> I have a fairly simple question. Before I installed= Xen on my CentOS 6.6 host, I'd added some configuration to the Grub config= uration file
> (/boot/grub/menu.lst) to allow access via the serial-console server:
>
>> default=3D0
>> timeout=3D5
>> splashimage=3D(hd0,0)/grub= /splash.xpm.gz
>> serial --unit=3D1 --speed=3D11520= 0 --word=3D8 --parity=3Dno --stop=3D1
>> terminal -= -timeout=3D5 serial console
>> ...
>> kernel /vmlinuz-2.6.32-504.1.3.el6.x86_64 ro ... quiet console= =3Dtty0 console=3DttyS0,115200n8
>
= > This seemed to work well until I added the stanzas to load Xen:
>
>> title CentOS (3.10.68-11.el6.c= entos.alt.x86_64)
>>    root (hd0,0)
>>    kernel /xen.gz dom0_mem=3D1024M,max:102= 4M loglvl=3Dall guest_loglvl=3Dall
>>    = module /vmlinuz-3.10.68-11.el6.centos.alt.x86_64 ro ... quiet console=3Dtty0 console=3DttyS0,115200n8
>&g= t;    module /initramfs-3.10.68-11.el6.centos.alt.x86_64.img
>
> Now I'm able to view/interact wi= th the host's BIOS; the Grub boot menu, and; I'm able to watch the initial = portion of the boot process. However, after
> the xend= starts I'm no longer able to view or to interact with Dom0.
>
> How can I grant Dom0 permanent access to t= he serial-console port of the host [hardware]?


you probably want
    kerne= l /boot/xen.gz com1=3D115200,8n1 console=3Dcom1
 &nb= sp;  module /boot/vmlinuz-3.10.68-11.el6.centos.alt.x86_64 console=3Dh= vc0

Thank you, Sarah!

Eric Pretorious
Portland, OR
=
---28653412-968517250-1436284028=:49278-- --===============4027676381771101923== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4027676381771101923==-- From xen-users-bounces@lists.xen.org Tue Jul 07 20:31:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 20:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCZVn-0006Fv-J1; Tue, 07 Jul 2015 20:30:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCZVl-0006Fe-JU for xen-users@lists.xen.org; Tue, 07 Jul 2015 20:30:37 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id DA/93-30151-CE63C955; Tue, 07 Jul 2015 20:30:36 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1436301032!30073593!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7686 invoked from network); 7 Jul 2015 20:30:33 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 20:30:33 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67KUSLh029248; Tue, 7 Jul 2015 15:30:28 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67KUSuT024980; Tue, 7 Jul 2015 15:30:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 15:30:15 -0500 Message-ID: <559C28D5.3040203@ti.com> Date: Tue, 7 Jul 2015 15:30:29 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> In-Reply-To: <559BD5B5.70308@ti.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/07/2015 09:35 AM, Brandon Perez wrote: > On 07/07/2015 09:53 AM, Julien Grall wrote: >> Hi, >> >> On 06/07/15 18:21, Brandon Perez wrote: >>> On 07/03/2015 06:30 AM, Julien Grall wrote: >>>> Hi, >>>> >>>> On 02/07/15 17:04, Brandon Perez wrote: >>>>> >>>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>>> (d1) Grant table initialized >>>>> (d1) 6xen:events: Using FIFO-based ABI >>>>> (d1) 6Xen: initializing cpu0 >>>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>>> >>>> It's hard to know what's going on with only these 5 lines. Is it the >>>> full log of the domU? If not, can you send it? >>>> >>>> Usually, the next step is to bring up the other processor, although you >>>> have only 1 vCPU in the device tree. >>>> >>>> Regards, >>>> >>> >>> Hi Julien, >>> >>> Unfortunately, that is the full log of the domU messages that I get >>> from "xl dmesg". That's part of the reason why I'm having a hard time >>> tracking down this issue, because I'm getting so little information back >>> from the guest. >>> >>> There's also the domU.log file that I attached in the prior email >>> that has additional information. >>> >>> Do you have any advice what might be causing this issue just >>> based on >>> that information? >> >> Not really. Can you try patch in [0]? It should print more on the >> console compare to the one you applied from [1]. >> >> You may also want to add ignore_loglevel on kernel guest command line. >> >> Regards, >> >> [0] https://patches.linaro.org/39687/ >> [1] >> http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb >> >> > > Hi Julien, > > I added applied patch [0], and I've attached the logging output that > I got with that patch. Nothing in the log really jumps out at me, and > the kernel seems to be booting fine until it freezes up for some reason. > > Is it possible that I'm not setting up the DomU's filesystem > correctly? I'm currently using a 800 Mb image on the Dom0 filesystem > that's formatted as ext3. Do I need to mount this somewhere on Dom0's > filesystem before running "xl create"? I could see this as a potential > reason for the guest domain to freeze up. > > Brandon I've done some digging to figuring out exactly where the domU kernel is getting stuck during boot. It's happening during a pre-SMP init call, specifically spawn_ksoftirqd(). The boot is getting stuck specifically in the function smpboot_unpark_thread(). The backtrace of this is (these are all 3.14 kernel files): smpboot_unpark_thread(): kernel/smpboot.c: 218 smpboot_register_percpu_thread(): kernel/smpboot.c: 289 spawn_ksoftirqd(): kernel/softirq.c: 756 do_one_initcall(): init/main.c: 704 do_pre_smp_initcalls(): init/main.c: 806 kernel_init_freeable(): init/main.c: 915 I was wondering if this is an issue that you guys may have seen before. If not, do you have any advice? It seems to be related somehow to scheduling and/or acquiring locks related to that. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 20:31:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 20:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCZVn-0006Fv-J1; Tue, 07 Jul 2015 20:30:39 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCZVl-0006Fe-JU for xen-users@lists.xen.org; Tue, 07 Jul 2015 20:30:37 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id DA/93-30151-CE63C955; Tue, 07 Jul 2015 20:30:36 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1436301032!30073593!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7686 invoked from network); 7 Jul 2015 20:30:33 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-7.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 20:30:33 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67KUSLh029248; Tue, 7 Jul 2015 15:30:28 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67KUSuT024980; Tue, 7 Jul 2015 15:30:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 15:30:15 -0500 Message-ID: <559C28D5.3040203@ti.com> Date: Tue, 7 Jul 2015 15:30:29 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> In-Reply-To: <559BD5B5.70308@ti.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/07/2015 09:35 AM, Brandon Perez wrote: > On 07/07/2015 09:53 AM, Julien Grall wrote: >> Hi, >> >> On 06/07/15 18:21, Brandon Perez wrote: >>> On 07/03/2015 06:30 AM, Julien Grall wrote: >>>> Hi, >>>> >>>> On 02/07/15 17:04, Brandon Perez wrote: >>>>> >>>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>>> (d1) Grant table initialized >>>>> (d1) 6xen:events: Using FIFO-based ABI >>>>> (d1) 6Xen: initializing cpu0 >>>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>>> >>>> It's hard to know what's going on with only these 5 lines. Is it the >>>> full log of the domU? If not, can you send it? >>>> >>>> Usually, the next step is to bring up the other processor, although you >>>> have only 1 vCPU in the device tree. >>>> >>>> Regards, >>>> >>> >>> Hi Julien, >>> >>> Unfortunately, that is the full log of the domU messages that I get >>> from "xl dmesg". That's part of the reason why I'm having a hard time >>> tracking down this issue, because I'm getting so little information back >>> from the guest. >>> >>> There's also the domU.log file that I attached in the prior email >>> that has additional information. >>> >>> Do you have any advice what might be causing this issue just >>> based on >>> that information? >> >> Not really. Can you try patch in [0]? It should print more on the >> console compare to the one you applied from [1]. >> >> You may also want to add ignore_loglevel on kernel guest command line. >> >> Regards, >> >> [0] https://patches.linaro.org/39687/ >> [1] >> http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb >> >> > > Hi Julien, > > I added applied patch [0], and I've attached the logging output that > I got with that patch. Nothing in the log really jumps out at me, and > the kernel seems to be booting fine until it freezes up for some reason. > > Is it possible that I'm not setting up the DomU's filesystem > correctly? I'm currently using a 800 Mb image on the Dom0 filesystem > that's formatted as ext3. Do I need to mount this somewhere on Dom0's > filesystem before running "xl create"? I could see this as a potential > reason for the guest domain to freeze up. > > Brandon I've done some digging to figuring out exactly where the domU kernel is getting stuck during boot. It's happening during a pre-SMP init call, specifically spawn_ksoftirqd(). The boot is getting stuck specifically in the function smpboot_unpark_thread(). The backtrace of this is (these are all 3.14 kernel files): smpboot_unpark_thread(): kernel/smpboot.c: 218 smpboot_register_percpu_thread(): kernel/smpboot.c: 289 spawn_ksoftirqd(): kernel/softirq.c: 756 do_one_initcall(): init/main.c: 704 do_pre_smp_initcalls(): init/main.c: 806 kernel_init_freeable(): init/main.c: 915 I was wondering if this is an issue that you guys may have seen before. If not, do you have any advice? It seems to be related somehow to scheduling and/or acquiring locks related to that. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 21:58:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 21:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCarW-0003KO-UP; Tue, 07 Jul 2015 21:57:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCarV-0003KF-AU for xen-users@lists.xen.org; Tue, 07 Jul 2015 21:57:09 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id FE/5C-31650-43B4C955; Tue, 07 Jul 2015 21:57:08 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1436306226!18691739!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22498 invoked from network); 7 Jul 2015 21:57:07 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 21:57:07 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67Lv2pb030405; Tue, 7 Jul 2015 16:57:03 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67Lv2TF014398; Tue, 7 Jul 2015 16:57:02 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 16:56:49 -0500 Message-ID: <559C3D1F.3040300@ti.com> Date: Tue, 7 Jul 2015 16:57:03 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> In-Reply-To: <559C28D5.3040203@ti.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/07/2015 03:30 PM, Brandon Perez wrote: > On 07/07/2015 09:35 AM, Brandon Perez wrote: >> On 07/07/2015 09:53 AM, Julien Grall wrote: >>> Hi, >>> >>> On 06/07/15 18:21, Brandon Perez wrote: >>>> On 07/03/2015 06:30 AM, Julien Grall wrote: >>>>> Hi, >>>>> >>>>> On 02/07/15 17:04, Brandon Perez wrote: >>>>>> >>>>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>>>> (d1) Grant table initialized >>>>>> (d1) 6xen:events: Using FIFO-based ABI >>>>>> (d1) 6Xen: initializing cpu0 >>>>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>>>> >>>>> It's hard to know what's going on with only these 5 lines. Is it the >>>>> full log of the domU? If not, can you send it? >>>>> >>>>> Usually, the next step is to bring up the other processor, although >>>>> you >>>>> have only 1 vCPU in the device tree. >>>>> >>>>> Regards, >>>>> >>>> >>>> Hi Julien, >>>> >>>> Unfortunately, that is the full log of the domU messages that I >>>> get >>>> from "xl dmesg". That's part of the reason why I'm having a hard time >>>> tracking down this issue, because I'm getting so little information >>>> back >>>> from the guest. >>>> >>>> There's also the domU.log file that I attached in the prior email >>>> that has additional information. >>>> >>>> Do you have any advice what might be causing this issue just >>>> based on >>>> that information? >>> >>> Not really. Can you try patch in [0]? It should print more on the >>> console compare to the one you applied from [1]. >>> >>> You may also want to add ignore_loglevel on kernel guest command line. >>> >>> Regards, >>> >>> [0] https://patches.linaro.org/39687/ >>> [1] >>> http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb >>> >>> >>> >> >> Hi Julien, >> >> I added applied patch [0], and I've attached the logging output that >> I got with that patch. Nothing in the log really jumps out at me, and >> the kernel seems to be booting fine until it freezes up for some reason. >> >> Is it possible that I'm not setting up the DomU's filesystem >> correctly? I'm currently using a 800 Mb image on the Dom0 filesystem >> that's formatted as ext3. Do I need to mount this somewhere on Dom0's >> filesystem before running "xl create"? I could see this as a potential >> reason for the guest domain to freeze up. >> >> Brandon > > I've done some digging to figuring out exactly where the domU kernel > is getting stuck during boot. It's happening during a pre-SMP init call, > specifically spawn_ksoftirqd(). The boot is getting stuck specifically > in the function smpboot_unpark_thread(). > > The backtrace of this is (these are all 3.14 kernel files): > smpboot_unpark_thread(): kernel/smpboot.c: 218 > smpboot_register_percpu_thread(): kernel/smpboot.c: 289 > spawn_ksoftirqd(): kernel/softirq.c: 756 > do_one_initcall(): init/main.c: 704 > do_pre_smp_initcalls(): init/main.c: 806 > kernel_init_freeable(): init/main.c: 915 > > I was wondering if this is an issue that you guys may have seen before. > If not, do you have any advice? It seems to be related somehow to > scheduling and/or acquiring locks related to that. > > Brandon > > > > I've done some additional digging to figure out exactly where the code is getting stuck. The kernel is getting stuck while waiting to be woken up from an hrtimer, which it uses to sleep for a period of time. My guess is either this must be related to how threads are being scheduled on the CPU, or it must be resulting from the timer IRQ not being delivered to the guest domain. Here's the full backtrace: schedule(): kernel/sched/core.c: 2769 schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 schedule_hrtimeout(): kernel/hrtimer.c: 1928 wait_task_inactive(): kernel/sched/core.c: 1230 __kthread_bind(): kernel/kthread.c: 333 __kthread_unpark(): kernel/kthread.c: 397 kthread_unpark(): kernel/kthread.c: 422 smpboot_unpark_thread(): kernel/smpboot.c: 226 smpboot_register_percpu_thread(): kernel/smpboot.c: 289 spawn_ksoftirqd(): kernel/softirq.c: 756 do_one_initcall(): init/main.c: 704 do_pre_smp_initcalls(): init/main.c: 806 kernel_init_freeable(): init/main.c: 915 Have you guys seen an issue similar to this before? Or do you have any advice based on where the DomU kernel is getting stuck? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 07 21:58:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 07 Jul 2015 21:58:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCarW-0003KO-UP; Tue, 07 Jul 2015 21:57:10 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCarV-0003KF-AU for xen-users@lists.xen.org; Tue, 07 Jul 2015 21:57:09 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id FE/5C-31650-43B4C955; Tue, 07 Jul 2015 21:57:08 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1436306226!18691739!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22498 invoked from network); 7 Jul 2015 21:57:07 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2015 21:57:07 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t67Lv2pb030405; Tue, 7 Jul 2015 16:57:03 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t67Lv2TF014398; Tue, 7 Jul 2015 16:57:02 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Tue, 7 Jul 2015 16:56:49 -0500 Message-ID: <559C3D1F.3040300@ti.com> Date: Tue, 7 Jul 2015 16:57:03 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> In-Reply-To: <559C28D5.3040203@ti.com> X-Originating-IP: [128.247.93.131] Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/07/2015 03:30 PM, Brandon Perez wrote: > On 07/07/2015 09:35 AM, Brandon Perez wrote: >> On 07/07/2015 09:53 AM, Julien Grall wrote: >>> Hi, >>> >>> On 06/07/15 18:21, Brandon Perez wrote: >>>> On 07/03/2015 06:30 AM, Julien Grall wrote: >>>>> Hi, >>>>> >>>>> On 02/07/15 17:04, Brandon Perez wrote: >>>>>> >>>>>> (d1) 6xen:grant_table: Grant tables using version 1 layout >>>>>> (d1) Grant table initialized >>>>>> (d1) 6xen:events: Using FIFO-based ABI >>>>>> (d1) 6Xen: initializing cpu0 >>>>>> (d1) 6Setting up static identity map for 0x405f7c28 - 0x405f7c80 >>>>> >>>>> It's hard to know what's going on with only these 5 lines. Is it the >>>>> full log of the domU? If not, can you send it? >>>>> >>>>> Usually, the next step is to bring up the other processor, although >>>>> you >>>>> have only 1 vCPU in the device tree. >>>>> >>>>> Regards, >>>>> >>>> >>>> Hi Julien, >>>> >>>> Unfortunately, that is the full log of the domU messages that I >>>> get >>>> from "xl dmesg". That's part of the reason why I'm having a hard time >>>> tracking down this issue, because I'm getting so little information >>>> back >>>> from the guest. >>>> >>>> There's also the domU.log file that I attached in the prior email >>>> that has additional information. >>>> >>>> Do you have any advice what might be causing this issue just >>>> based on >>>> that information? >>> >>> Not really. Can you try patch in [0]? It should print more on the >>> console compare to the one you applied from [1]. >>> >>> You may also want to add ignore_loglevel on kernel guest command line. >>> >>> Regards, >>> >>> [0] https://patches.linaro.org/39687/ >>> [1] >>> http://xenbits.xen.org/gitweb/?p=people/ianc/linux.git;a=commitdiff;h=476bff35f03de10392826672cfd0d9e2c40ea7eb >>> >>> >>> >> >> Hi Julien, >> >> I added applied patch [0], and I've attached the logging output that >> I got with that patch. Nothing in the log really jumps out at me, and >> the kernel seems to be booting fine until it freezes up for some reason. >> >> Is it possible that I'm not setting up the DomU's filesystem >> correctly? I'm currently using a 800 Mb image on the Dom0 filesystem >> that's formatted as ext3. Do I need to mount this somewhere on Dom0's >> filesystem before running "xl create"? I could see this as a potential >> reason for the guest domain to freeze up. >> >> Brandon > > I've done some digging to figuring out exactly where the domU kernel > is getting stuck during boot. It's happening during a pre-SMP init call, > specifically spawn_ksoftirqd(). The boot is getting stuck specifically > in the function smpboot_unpark_thread(). > > The backtrace of this is (these are all 3.14 kernel files): > smpboot_unpark_thread(): kernel/smpboot.c: 218 > smpboot_register_percpu_thread(): kernel/smpboot.c: 289 > spawn_ksoftirqd(): kernel/softirq.c: 756 > do_one_initcall(): init/main.c: 704 > do_pre_smp_initcalls(): init/main.c: 806 > kernel_init_freeable(): init/main.c: 915 > > I was wondering if this is an issue that you guys may have seen before. > If not, do you have any advice? It seems to be related somehow to > scheduling and/or acquiring locks related to that. > > Brandon > > > > I've done some additional digging to figure out exactly where the code is getting stuck. The kernel is getting stuck while waiting to be woken up from an hrtimer, which it uses to sleep for a period of time. My guess is either this must be related to how threads are being scheduled on the CPU, or it must be resulting from the timer IRQ not being delivered to the guest domain. Here's the full backtrace: schedule(): kernel/sched/core.c: 2769 schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 schedule_hrtimeout(): kernel/hrtimer.c: 1928 wait_task_inactive(): kernel/sched/core.c: 1230 __kthread_bind(): kernel/kthread.c: 333 __kthread_unpark(): kernel/kthread.c: 397 kthread_unpark(): kernel/kthread.c: 422 smpboot_unpark_thread(): kernel/smpboot.c: 226 smpboot_register_percpu_thread(): kernel/smpboot.c: 289 spawn_ksoftirqd(): kernel/softirq.c: 756 do_one_initcall(): init/main.c: 704 do_pre_smp_initcalls(): init/main.c: 806 kernel_init_freeable(): init/main.c: 915 Have you guys seen an issue similar to this before? Or do you have any advice based on where the DomU kernel is getting stuck? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 08:31:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 08:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCkkD-0002Iq-Aj; Wed, 08 Jul 2015 08:30:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCkkB-0002Il-W2 for xen-users@lists.xen.org; Wed, 08 Jul 2015 08:30:16 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id EF/FA-29123-69FDC955; Wed, 08 Jul 2015 08:30:14 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1436344212!30146802!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3184 invoked from network); 8 Jul 2015 08:30:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 08:30:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,430,1432598400"; d="scan'208";a="282063688" Message-ID: <1436344210.25646.274.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 09:30:10 +0100 In-Reply-To: <559C3D1F.3040300@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-07 at 16:57 -0400, Brandon Perez wrote: > I've done some additional digging to figure out exactly where the > code is getting stuck. The kernel is getting stuck while waiting to be > woken up from an hrtimer, which it uses to sleep for a period of time. > > My guess is either this must be related to how threads are being > scheduled on the CPU, or it must be resulting from the timer IRQ not > being delivered to the guest domain. My bet would be either missing the timer interrupt, or missing interrupts generally. Does your platform set the CNTFRQ register in the firmware or does it use the device-tree clock-frequency node? If it is the latter then perhaps Julien's patch "xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node" (commit 59ccb33c40c in the development branch) would help? Looks like you are using a slightly older version of the development branch. Ian. > > Here's the full backtrace: > schedule(): kernel/sched/core.c: 2769 > schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 > schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 > schedule_hrtimeout(): kernel/hrtimer.c: 1928 > wait_task_inactive(): kernel/sched/core.c: 1230 > __kthread_bind(): kernel/kthread.c: 333 > __kthread_unpark(): kernel/kthread.c: 397 > kthread_unpark(): kernel/kthread.c: 422 > smpboot_unpark_thread(): kernel/smpboot.c: 226 > smpboot_register_percpu_thread(): kernel/smpboot.c: 289 > spawn_ksoftirqd(): kernel/softirq.c: 756 > do_one_initcall(): init/main.c: 704 > do_pre_smp_initcalls(): init/main.c: 806 > kernel_init_freeable(): init/main.c: 915 > > Have you guys seen an issue similar to this before? Or do you have > any advice based on where the DomU kernel is getting stuck? > > Brandon > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 08:31:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 08:31:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCkkD-0002Iq-Aj; Wed, 08 Jul 2015 08:30:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCkkB-0002Il-W2 for xen-users@lists.xen.org; Wed, 08 Jul 2015 08:30:16 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id EF/FA-29123-69FDC955; Wed, 08 Jul 2015 08:30:14 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1436344212!30146802!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3184 invoked from network); 8 Jul 2015 08:30:14 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 08:30:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,430,1432598400"; d="scan'208";a="282063688" Message-ID: <1436344210.25646.274.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 09:30:10 +0100 In-Reply-To: <559C3D1F.3040300@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-07 at 16:57 -0400, Brandon Perez wrote: > I've done some additional digging to figure out exactly where the > code is getting stuck. The kernel is getting stuck while waiting to be > woken up from an hrtimer, which it uses to sleep for a period of time. > > My guess is either this must be related to how threads are being > scheduled on the CPU, or it must be resulting from the timer IRQ not > being delivered to the guest domain. My bet would be either missing the timer interrupt, or missing interrupts generally. Does your platform set the CNTFRQ register in the firmware or does it use the device-tree clock-frequency node? If it is the latter then perhaps Julien's patch "xen/arm: Propagate clock-frequency to DOMU if present in the DT timer node" (commit 59ccb33c40c in the development branch) would help? Looks like you are using a slightly older version of the development branch. Ian. > > Here's the full backtrace: > schedule(): kernel/sched/core.c: 2769 > schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 > schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 > schedule_hrtimeout(): kernel/hrtimer.c: 1928 > wait_task_inactive(): kernel/sched/core.c: 1230 > __kthread_bind(): kernel/kthread.c: 333 > __kthread_unpark(): kernel/kthread.c: 397 > kthread_unpark(): kernel/kthread.c: 422 > smpboot_unpark_thread(): kernel/smpboot.c: 226 > smpboot_register_percpu_thread(): kernel/smpboot.c: 289 > spawn_ksoftirqd(): kernel/softirq.c: 756 > do_one_initcall(): init/main.c: 704 > do_pre_smp_initcalls(): init/main.c: 806 > kernel_init_freeable(): init/main.c: 915 > > Have you guys seen an issue similar to this before? Or do you have > any advice based on where the DomU kernel is getting stuck? > > Brandon > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:30:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:30:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqLi-0008Cv-JO; Wed, 08 Jul 2015 14:29:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqLh-0008Ck-0q for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:29:21 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 3C/DF-13517-0C33D955; Wed, 08 Jul 2015 14:29:20 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1436365758!23908582!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9441 invoked from network); 8 Jul 2015 14:29:19 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:29:19 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68ETEDV000823; Wed, 8 Jul 2015 09:29:14 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68ETEHE020339; Wed, 8 Jul 2015 09:29:14 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:28:59 -0500 Message-ID: <559D25AC.5080706@ti.com> Date: Wed, 8 Jul 2015 09:29:16 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> In-Reply-To: <1436344210.25646.274.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 04:30 AM, Ian Campbell wrote: > On Tue, 2015-07-07 at 16:57 -0400, Brandon Perez wrote: >> I've done some additional digging to figure out exactly where the >> code is getting stuck. The kernel is getting stuck while waiting to be >> woken up from an hrtimer, which it uses to sleep for a period of time. >> >> My guess is either this must be related to how threads are being >> scheduled on the CPU, or it must be resulting from the timer IRQ not >> being delivered to the guest domain. > > My bet would be either missing the timer interrupt, or missing > interrupts generally. > > Does your platform set the CNTFRQ register in the firmware or does it > use the device-tree clock-frequency node? If it is the latter then > perhaps Julien's patch "xen/arm: Propagate clock-frequency to DOMU if > present in the DT timer node" (commit 59ccb33c40c in the development > branch) would help? Looks like you are using a slightly older version of > the development branch. > > Ian. > >> >> Here's the full backtrace: >> schedule(): kernel/sched/core.c: 2769 >> schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 >> schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 >> schedule_hrtimeout(): kernel/hrtimer.c: 1928 >> wait_task_inactive(): kernel/sched/core.c: 1230 >> __kthread_bind(): kernel/kthread.c: 333 >> __kthread_unpark(): kernel/kthread.c: 397 >> kthread_unpark(): kernel/kthread.c: 422 >> smpboot_unpark_thread(): kernel/smpboot.c: 226 >> smpboot_register_percpu_thread(): kernel/smpboot.c: 289 >> spawn_ksoftirqd(): kernel/softirq.c: 756 >> do_one_initcall(): init/main.c: 704 >> do_pre_smp_initcalls(): init/main.c: 806 >> kernel_init_freeable(): init/main.c: 915 >> >> Have you guys seen an issue similar to this before? Or do you have >> any advice based on where the DomU kernel is getting stuck? >> >> Brandon >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > Hi Ian, My platform sets the CNTFRQ register during boot-up, so it doesn't come from the device tree. Might this be causing issues later for DomU, or are those issues present only the device tree node is used to set the CNTFRQ register? Any ideas on what else may be leading to this issue? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:30:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:30:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqLi-0008Cv-JO; Wed, 08 Jul 2015 14:29:22 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqLh-0008Ck-0q for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:29:21 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id 3C/DF-13517-0C33D955; Wed, 08 Jul 2015 14:29:20 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1436365758!23908582!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9441 invoked from network); 8 Jul 2015 14:29:19 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-11.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:29:19 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68ETEDV000823; Wed, 8 Jul 2015 09:29:14 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68ETEHE020339; Wed, 8 Jul 2015 09:29:14 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:28:59 -0500 Message-ID: <559D25AC.5080706@ti.com> Date: Wed, 8 Jul 2015 09:29:16 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> In-Reply-To: <1436344210.25646.274.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 04:30 AM, Ian Campbell wrote: > On Tue, 2015-07-07 at 16:57 -0400, Brandon Perez wrote: >> I've done some additional digging to figure out exactly where the >> code is getting stuck. The kernel is getting stuck while waiting to be >> woken up from an hrtimer, which it uses to sleep for a period of time. >> >> My guess is either this must be related to how threads are being >> scheduled on the CPU, or it must be resulting from the timer IRQ not >> being delivered to the guest domain. > > My bet would be either missing the timer interrupt, or missing > interrupts generally. > > Does your platform set the CNTFRQ register in the firmware or does it > use the device-tree clock-frequency node? If it is the latter then > perhaps Julien's patch "xen/arm: Propagate clock-frequency to DOMU if > present in the DT timer node" (commit 59ccb33c40c in the development > branch) would help? Looks like you are using a slightly older version of > the development branch. > > Ian. > >> >> Here's the full backtrace: >> schedule(): kernel/sched/core.c: 2769 >> schedule_hrtimeout_range_clock(): kernel/hrtimer.c: 1857 >> schedule_hrtimeout_range(): kernel/hrtimer.c: 1898 >> schedule_hrtimeout(): kernel/hrtimer.c: 1928 >> wait_task_inactive(): kernel/sched/core.c: 1230 >> __kthread_bind(): kernel/kthread.c: 333 >> __kthread_unpark(): kernel/kthread.c: 397 >> kthread_unpark(): kernel/kthread.c: 422 >> smpboot_unpark_thread(): kernel/smpboot.c: 226 >> smpboot_register_percpu_thread(): kernel/smpboot.c: 289 >> spawn_ksoftirqd(): kernel/softirq.c: 756 >> do_one_initcall(): init/main.c: 704 >> do_pre_smp_initcalls(): init/main.c: 806 >> kernel_init_freeable(): init/main.c: 915 >> >> Have you guys seen an issue similar to this before? Or do you have >> any advice based on where the DomU kernel is getting stuck? >> >> Brandon >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > Hi Ian, My platform sets the CNTFRQ register during boot-up, so it doesn't come from the device tree. Might this be causing issues later for DomU, or are those issues present only the device tree node is used to set the CNTFRQ register? Any ideas on what else may be leading to this issue? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:41:11 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:41:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqWt-0001oP-Oy; Wed, 08 Jul 2015 14:40:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqWs-0001oF-GW for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:40:54 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 5F/1E-21325-5763D955; Wed, 08 Jul 2015 14:40:53 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1436366451!12219962!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4324 invoked from network); 8 Jul 2015 14:40:53 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 14:40:53 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282180037" Message-ID: <1436366449.23508.59.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 15:40:49 +0100 In-Reply-To: <559D25AC.5080706@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 09:29 -0400, Brandon Perez wrote: > My platform sets the CNTFRQ register during boot-up, so it doesn't > come from the device tree. Might this be causing issues later for DomU, > or are those issues present only the device tree node is used to set the > CNTFRQ register? If the h/w CNTFRQ register is correct on all physical cpus (not just the boot one, worth double checking that) then there is no need to have anything in the device tree. So assuming you are letting xl generate the guest dtb (instead of say appending it) you should be ok in this regard. > Any ideas on what else may be leading to this issue? Next on my list would be the boot is working but the console is b0rked, but you have console=hvc0 so that looks good. You do have the HVC stuff enabled in the guest kernel's .config, right? Pressing Ctrl-o on a xen guest console is the equivalent of the magic sysrq key, you might find pressing some of those might show what is going on. Otherwise I'm completely stumped. It's probably worth going back to the data sheet and making sure everything matches in the DTS, in particular for virtulisation extension related things which might not be used by native Linux (e,g, the vtimer interrupt SPI number etc), but really that's getting a bit desperate. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:41:11 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:41:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqWt-0001oP-Oy; Wed, 08 Jul 2015 14:40:55 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqWs-0001oF-GW for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:40:54 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id 5F/1E-21325-5763D955; Wed, 08 Jul 2015 14:40:53 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1436366451!12219962!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4324 invoked from network); 8 Jul 2015 14:40:53 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 14:40:53 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282180037" Message-ID: <1436366449.23508.59.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 15:40:49 +0100 In-Reply-To: <559D25AC.5080706@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 09:29 -0400, Brandon Perez wrote: > My platform sets the CNTFRQ register during boot-up, so it doesn't > come from the device tree. Might this be causing issues later for DomU, > or are those issues present only the device tree node is used to set the > CNTFRQ register? If the h/w CNTFRQ register is correct on all physical cpus (not just the boot one, worth double checking that) then there is no need to have anything in the device tree. So assuming you are letting xl generate the guest dtb (instead of say appending it) you should be ok in this regard. > Any ideas on what else may be leading to this issue? Next on my list would be the boot is working but the console is b0rked, but you have console=hvc0 so that looks good. You do have the HVC stuff enabled in the guest kernel's .config, right? Pressing Ctrl-o on a xen guest console is the equivalent of the magic sysrq key, you might find pressing some of those might show what is going on. Otherwise I'm completely stumped. It's probably worth going back to the data sheet and making sure everything matches in the DTS, in particular for virtulisation extension related things which might not be used by native Linux (e,g, the vtimer interrupt SPI number etc), but really that's getting a bit desperate. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:43:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqZL-00028i-6m; Wed, 08 Jul 2015 14:43:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqZJ-00028I-Ee for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:43:25 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id DC/1E-13047-C073D955; Wed, 08 Jul 2015 14:43:24 +0000 X-Env-Sender: prvs=624d3fcf7=julien.grall@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1436366602!29283550!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2079 invoked from network); 8 Jul 2015 14:43:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 14:43:24 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282181076" Message-ID: <559D36DA.2030908@citrix.com> Date: Wed, 8 Jul 2015 15:42:34 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> In-Reply-To: <559D25AC.5080706@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 08/07/15 14:29, Brandon Perez wrote: > Any ideas on what else may be leading to this issue? By any chance, do you append a device tree to the guest kernel? Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:43:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:43:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqZL-00028i-6m; Wed, 08 Jul 2015 14:43:27 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqZJ-00028I-Ee for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:43:25 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id DC/1E-13047-C073D955; Wed, 08 Jul 2015 14:43:24 +0000 X-Env-Sender: prvs=624d3fcf7=julien.grall@citrix.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1436366602!29283550!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2079 invoked from network); 8 Jul 2015 14:43:24 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 14:43:24 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282181076" Message-ID: <559D36DA.2030908@citrix.com> Date: Wed, 8 Jul 2015 15:42:34 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> In-Reply-To: <559D25AC.5080706@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 08/07/15 14:29, Brandon Perez wrote: > Any ideas on what else may be leading to this issue? By any chance, do you append a device tree to the guest kernel? Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:55:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:55:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqkH-0003lR-K5; Wed, 08 Jul 2015 14:54:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqkG-0003lL-D9 for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:54:44 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id BF/D6-10437-3B93D955; Wed, 08 Jul 2015 14:54:43 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436367281!23955105!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30224 invoked from network); 8 Jul 2015 14:54:43 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:54:43 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68EsaOK012956; Wed, 8 Jul 2015 09:54:36 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68Esafs004536; Wed, 8 Jul 2015 09:54:36 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:54:21 -0500 Message-ID: <559D2B9E.50405@ti.com> Date: Wed, 8 Jul 2015 09:54:38 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> In-Reply-To: <1436366449.23508.59.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 10:40 AM, Ian Campbell wrote: > > If the h/w CNTFRQ register is correct on all physical cpus (not just the > boot one, worth double checking that) then there is no need to have > anything in the device tree. So assuming you are letting xl generate the > guest dtb (instead of say appending it) you should be ok in this regard. > The specific device that I'm using only has one physical CPU, so the CNTFRQ register is definitely correctly initialized, as Dom0 is making it though its boot. I'm not doing anything special with regards to the device tree, so I assume that means xl should be generating it. The specific device that I'm using only has one physical CPU, so the CNTFRQ register is definitely correctly initialized, as Dom0 is making it though its boot. I'm not doing anything special with regards to the device tree, so I assume that means xl should be generating it. > > Next on my list would be the boot is working but the console is b0rked, > but you have console=hvc0 so that looks good. You do have the HVC stuff > enabled in the guest kernel's .config, right? > I'm using the same zImage as the Dom0 kernel, so the configuration settings are the same. I doubled checked, and all of the virtual console configuration settings are enabled. > Pressing Ctrl-o on a xen guest console is the equivalent of the magic > sysrq key, you might find pressing some of those might show what is > going on. > If I press the sysrq key combinations, while attached to the guest with "xl console", Dom0 responds with the appropriate message, but the DomU guest does not acknowledge the sysrq keys. > Otherwise I'm completely stumped. It's probably worth going back to the > data sheet and making sure everything matches in the DTS, in particular > for virtulisation extension related things which might not be used by > native Linux (e,g, the vtimer interrupt SPI number etc), but really > that's getting a bit desperate. > > Ian. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:55:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:55:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqkH-0003lR-K5; Wed, 08 Jul 2015 14:54:45 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqkG-0003lL-D9 for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:54:44 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id BF/D6-10437-3B93D955; Wed, 08 Jul 2015 14:54:43 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436367281!23955105!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30224 invoked from network); 8 Jul 2015 14:54:43 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:54:43 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68EsaOK012956; Wed, 8 Jul 2015 09:54:36 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68Esafs004536; Wed, 8 Jul 2015 09:54:36 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:54:21 -0500 Message-ID: <559D2B9E.50405@ti.com> Date: Wed, 8 Jul 2015 09:54:38 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> In-Reply-To: <1436366449.23508.59.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 10:40 AM, Ian Campbell wrote: > > If the h/w CNTFRQ register is correct on all physical cpus (not just the > boot one, worth double checking that) then there is no need to have > anything in the device tree. So assuming you are letting xl generate the > guest dtb (instead of say appending it) you should be ok in this regard. > The specific device that I'm using only has one physical CPU, so the CNTFRQ register is definitely correctly initialized, as Dom0 is making it though its boot. I'm not doing anything special with regards to the device tree, so I assume that means xl should be generating it. The specific device that I'm using only has one physical CPU, so the CNTFRQ register is definitely correctly initialized, as Dom0 is making it though its boot. I'm not doing anything special with regards to the device tree, so I assume that means xl should be generating it. > > Next on my list would be the boot is working but the console is b0rked, > but you have console=hvc0 so that looks good. You do have the HVC stuff > enabled in the guest kernel's .config, right? > I'm using the same zImage as the Dom0 kernel, so the configuration settings are the same. I doubled checked, and all of the virtual console configuration settings are enabled. > Pressing Ctrl-o on a xen guest console is the equivalent of the magic > sysrq key, you might find pressing some of those might show what is > going on. > If I press the sysrq key combinations, while attached to the guest with "xl console", Dom0 responds with the appropriate message, but the DomU guest does not acknowledge the sysrq keys. > Otherwise I'm completely stumped. It's probably worth going back to the > data sheet and making sure everything matches in the DTS, in particular > for virtulisation extension related things which might not be used by > native Linux (e,g, the vtimer interrupt SPI number etc), but really > that's getting a bit desperate. > > Ian. > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:56:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:56:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqlu-0003t0-Jf; Wed, 08 Jul 2015 14:56:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqlt-0003sf-7g for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:56:25 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 6A/05-13047-81A3D955; Wed, 08 Jul 2015 14:56:24 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1436367382!22780995!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26592 invoked from network); 8 Jul 2015 14:56:23 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:56:23 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68EuKZO003656; Wed, 8 Jul 2015 09:56:20 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68EuJBI014629; Wed, 8 Jul 2015 09:56:20 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:56:05 -0500 Message-ID: <559D2C06.10008@ti.com> Date: Wed, 8 Jul 2015 09:56:22 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <559D36DA.2030908@citrix.com> In-Reply-To: <559D36DA.2030908@citrix.com> X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 10:42 AM, Julien Grall wrote: > On 08/07/15 14:29, Brandon Perez wrote: >> Any ideas on what else may be leading to this issue? > > By any chance, do you append a device tree to the guest kernel? > > Regards, > I don't believe so, unless the device tree is appended by default. I simply use the configuration file I attached in my original email and use "xl create", with the same zImage as the Dom0 kernel. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 14:56:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 14:56:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqlu-0003t0-Jf; Wed, 08 Jul 2015 14:56:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqlt-0003sf-7g for xen-users@lists.xen.org; Wed, 08 Jul 2015 14:56:25 +0000 Received: from [193.109.254.147] by server-6.bemta-14.messagelabs.com id 6A/05-13047-81A3D955; Wed, 08 Jul 2015 14:56:24 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1436367382!22780995!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26592 invoked from network); 8 Jul 2015 14:56:23 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-16.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 14:56:23 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68EuKZO003656; Wed, 8 Jul 2015 09:56:20 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68EuJBI014629; Wed, 8 Jul 2015 09:56:20 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 09:56:05 -0500 Message-ID: <559D2C06.10008@ti.com> Date: Wed, 8 Jul 2015 09:56:22 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <559D36DA.2030908@citrix.com> In-Reply-To: <559D36DA.2030908@citrix.com> X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 10:42 AM, Julien Grall wrote: > On 08/07/15 14:29, Brandon Perez wrote: >> Any ideas on what else may be leading to this issue? > > By any chance, do you append a device tree to the guest kernel? > > Regards, > I don't believe so, unless the device tree is appended by default. I simply use the configuration file I attached in my original email and use "xl create", with the same zImage as the Dom0 kernel. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:01:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:01:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqqQ-0004u7-10; Wed, 08 Jul 2015 15:01:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqqO-0004tw-LY for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:01:04 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id FC/93-29123-03B3D955; Wed, 08 Jul 2015 15:01:04 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436367661!30390906!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28015 invoked from network); 8 Jul 2015 15:01:03 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 15:01:03 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282189520" Message-ID: <1436367656.23508.65.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 16:00:56 +0100 In-Reply-To: <559D2B9E.50405@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: > > Pressing Ctrl-o on a xen guest console is the equivalent of the magic > > sysrq key, you might find pressing some of those might show what is > > going on. > > > > If I press the sysrq key combinations, while attached to the guest > with "xl console", Dom0 responds with the appropriate message, but the > DomU guest does not acknowledge the sysrq keys. If you are logged in via the dom0 console to run xl console to get the guest console then I think dom0 will eat the Ctrl-o. Not sure if something like Ctrl-o Ctrl-o will work. "xl sysrq " should do the same sort of thing I think. Ian. > > Otherwise I'm completely stumped. It's probably worth going back to the > > data sheet and making sure everything matches in the DTS, in particular > > for virtulisation extension related things which might not be used by > > native Linux (e,g, the vtimer interrupt SPI number etc), but really > > that's getting a bit desperate. > > > > Ian. > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:01:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:01:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqqQ-0004u7-10; Wed, 08 Jul 2015 15:01:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqqO-0004tw-LY for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:01:04 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id FC/93-29123-03B3D955; Wed, 08 Jul 2015 15:01:04 +0000 X-Env-Sender: prvs=624374659=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436367661!30390906!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28015 invoked from network); 8 Jul 2015 15:01:03 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 15:01:03 -0000 X-IronPort-AV: E=Sophos;i="5.15,431,1432598400"; d="scan'208";a="282189520" Message-ID: <1436367656.23508.65.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 8 Jul 2015 16:00:56 +0100 In-Reply-To: <559D2B9E.50405@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: > > Pressing Ctrl-o on a xen guest console is the equivalent of the magic > > sysrq key, you might find pressing some of those might show what is > > going on. > > > > If I press the sysrq key combinations, while attached to the guest > with "xl console", Dom0 responds with the appropriate message, but the > DomU guest does not acknowledge the sysrq keys. If you are logged in via the dom0 console to run xl console to get the guest console then I think dom0 will eat the Ctrl-o. Not sure if something like Ctrl-o Ctrl-o will work. "xl sysrq " should do the same sort of thing I think. Ian. > > Otherwise I'm completely stumped. It's probably worth going back to the > > data sheet and making sure everything matches in the DTS, in particular > > for virtulisation extension related things which might not be used by > > native Linux (e,g, the vtimer interrupt SPI number etc), but really > > that's getting a bit desperate. > > > > Ian. > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:07:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:07:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqwh-0005MG-3v; Wed, 08 Jul 2015 15:07:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqwg-0005Lk-1i for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:07:34 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 48/6E-25925-5BC3D955; Wed, 08 Jul 2015 15:07:33 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1436368051!19795601!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4627 invoked from network); 8 Jul 2015 15:07:32 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 15:07:32 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68F7Ssl032468; Wed, 8 Jul 2015 10:07:28 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68F7S7P027252; Wed, 8 Jul 2015 10:07:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 10:07:13 -0500 Message-ID: <559D2EA2.9050400@ti.com> Date: Wed, 8 Jul 2015 10:07:30 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> In-Reply-To: <1436367656.23508.65.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 11:00 AM, Ian Campbell wrote: > On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>> sysrq key, you might find pressing some of those might show what is >>> going on. >>> >> >> If I press the sysrq key combinations, while attached to the guest >> with "xl console", Dom0 responds with the appropriate message, but the >> DomU guest does not acknowledge the sysrq keys. > > If you are logged in via the dom0 console to run xl console to get the > guest console then I think dom0 will eat the Ctrl-o. Not sure if > something like Ctrl-o Ctrl-o will work. "xl sysrq " should > do the same sort of thing I think. > > Ian. > >>> Otherwise I'm completely stumped. It's probably worth going back to the >>> data sheet and making sure everything matches in the DTS, in particular >>> for virtulisation extension related things which might not be used by >>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>> that's getting a bit desperate. >>> >>> Ian. >>> > > The guest doesn't respond to any of the sysrq key combinations, I tried with both of the methods. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:07:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:07:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqwh-0005MG-3v; Wed, 08 Jul 2015 15:07:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCqwg-0005Lk-1i for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:07:34 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 48/6E-25925-5BC3D955; Wed, 08 Jul 2015 15:07:33 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1436368051!19795601!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4627 invoked from network); 8 Jul 2015 15:07:32 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 15:07:32 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68F7Ssl032468; Wed, 8 Jul 2015 10:07:28 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68F7S7P027252; Wed, 8 Jul 2015 10:07:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 10:07:13 -0500 Message-ID: <559D2EA2.9050400@ti.com> Date: Wed, 8 Jul 2015 10:07:30 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> In-Reply-To: <1436367656.23508.65.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/08/2015 11:00 AM, Ian Campbell wrote: > On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>> sysrq key, you might find pressing some of those might show what is >>> going on. >>> >> >> If I press the sysrq key combinations, while attached to the guest >> with "xl console", Dom0 responds with the appropriate message, but the >> DomU guest does not acknowledge the sysrq keys. > > If you are logged in via the dom0 console to run xl console to get the > guest console then I think dom0 will eat the Ctrl-o. Not sure if > something like Ctrl-o Ctrl-o will work. "xl sysrq " should > do the same sort of thing I think. > > Ian. > >>> Otherwise I'm completely stumped. It's probably worth going back to the >>> data sheet and making sure everything matches in the DTS, in particular >>> for virtulisation extension related things which might not be used by >>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>> that's getting a bit desperate. >>> >>> Ian. >>> > > The guest doesn't respond to any of the sysrq key combinations, I tried with both of the methods. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:20:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:20:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCr9E-0006pG-Me; Wed, 08 Jul 2015 15:20:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCr9C-0006p5-M7 for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:20:30 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id DF/7E-03371-EBF3D955; Wed, 08 Jul 2015 15:20:30 +0000 X-Env-Sender: prvs=624d3fcf7=julien.grall@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1436368827!30389146!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26745 invoked from network); 8 Jul 2015 15:20:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 15:20:29 -0000 X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="282201882" Message-ID: <559D3F44.5080607@citrix.com> Date: Wed, 8 Jul 2015 16:18:28 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> In-Reply-To: <559D2EA2.9050400@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 08/07/15 15:07, Brandon Perez wrote: > On 07/08/2015 11:00 AM, Ian Campbell wrote: >> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>> sysrq key, you might find pressing some of those might show what is >>>> going on. >>>> >>> >>> If I press the sysrq key combinations, while attached to the guest >>> with "xl console", Dom0 responds with the appropriate message, but the >>> DomU guest does not acknowledge the sysrq keys. >> >> If you are logged in via the dom0 console to run xl console to get the >> guest console then I think dom0 will eat the Ctrl-o. Not sure if >> something like Ctrl-o Ctrl-o will work. "xl sysrq " should >> do the same sort of thing I think. >> >> Ian. >> >>>> Otherwise I'm completely stumped. It's probably worth going back to the >>>> data sheet and making sure everything matches in the DTS, in particular >>>> for virtulisation extension related things which might not be used by >>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>> that's getting a bit desperate. >>>> >>>> Ian. >>>> >> >> > > The guest doesn't respond to any of the sysrq key combinations, I > tried with both of the methods. Which is expected because the console is not yet setup. Based on the log you provided earlier, I would go start to check if the guest receive the interrupt. On the xen console (CTRL-a three times) you can type 'q' it will print all the IRQ present in the LRs and which IRQ is pending for a given domain. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:20:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:20:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCr9E-0006pG-Me; Wed, 08 Jul 2015 15:20:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCr9C-0006p5-M7 for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:20:30 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id DF/7E-03371-EBF3D955; Wed, 08 Jul 2015 15:20:30 +0000 X-Env-Sender: prvs=624d3fcf7=julien.grall@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1436368827!30389146!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26745 invoked from network); 8 Jul 2015 15:20:29 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 8 Jul 2015 15:20:29 -0000 X-IronPort-AV: E=Sophos;i="5.15,432,1432598400"; d="scan'208";a="282201882" Message-ID: <559D3F44.5080607@citrix.com> Date: Wed, 8 Jul 2015 16:18:28 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> In-Reply-To: <559D2EA2.9050400@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 08/07/15 15:07, Brandon Perez wrote: > On 07/08/2015 11:00 AM, Ian Campbell wrote: >> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>> sysrq key, you might find pressing some of those might show what is >>>> going on. >>>> >>> >>> If I press the sysrq key combinations, while attached to the guest >>> with "xl console", Dom0 responds with the appropriate message, but the >>> DomU guest does not acknowledge the sysrq keys. >> >> If you are logged in via the dom0 console to run xl console to get the >> guest console then I think dom0 will eat the Ctrl-o. Not sure if >> something like Ctrl-o Ctrl-o will work. "xl sysrq " should >> do the same sort of thing I think. >> >> Ian. >> >>>> Otherwise I'm completely stumped. It's probably worth going back to the >>>> data sheet and making sure everything matches in the DTS, in particular >>>> for virtulisation extension related things which might not be used by >>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>> that's getting a bit desperate. >>>> >>>> Ian. >>>> >> >> > > The guest doesn't respond to any of the sysrq key combinations, I > tried with both of the methods. Which is expected because the console is not yet setup. Based on the log you provided earlier, I would go start to check if the guest receive the interrupt. On the xen console (CTRL-a three times) you can type 'q' it will print all the IRQ present in the LRs and which IRQ is pending for a given domain. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 08 15:37:21 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCrP1-0000Nj-6S; Wed, 08 Jul 2015 15:36:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCrOz-0000MF-0g for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:36:49 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id DE/27-30658-0934D955; Wed, 08 Jul 2015 15:36:48 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1436369806!30377100!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22898 invoked from network); 8 Jul 2015 15:36:47 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 15:36:47 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68Fahh0006079; Wed, 8 Jul 2015 10:36:43 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68Fag3q016150; Wed, 8 Jul 2015 10:36:42 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 10:36:28 -0500 Message-ID: <559D357D.3030002@ti.com> Date: Wed, 8 Jul 2015 10:36:45 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> In-Reply-To: <559D3F44.5080607@citrix.com> Content-Type: multipart/mixed; boundary="------------010104080300000501060902" X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------010104080300000501060902 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/08/2015 11:18 AM, Julien Grall wrote: > On 08/07/15 15:07, Brandon Perez wrote: >> On 07/08/2015 11:00 AM, Ian Campbell wrote: >>> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>>> sysrq key, you might find pressing some of those might show what is >>>>> going on. >>>>> >>>> >>>> If I press the sysrq key combinations, while attached to the guest >>>> with "xl console", Dom0 responds with the appropriate message, but the >>>> DomU guest does not acknowledge the sysrq keys. >>> >>> If you are logged in via the dom0 console to run xl console to get the >>> guest console then I think dom0 will eat the Ctrl-o. Not sure if >>> something like Ctrl-o Ctrl-o will work. "xl sysrq " should >>> do the same sort of thing I think. >>> >>> Ian. >>> >>>>> Otherwise I'm completely stumped. It's probably worth going back to the >>>>> data sheet and making sure everything matches in the DTS, in particular >>>>> for virtulisation extension related things which might not be used by >>>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>>> that's getting a bit desperate. >>>>> >>>>> Ian. >>>>> >>> >>> >> >> The guest doesn't respond to any of the sysrq key combinations, I >> tried with both of the methods. > > Which is expected because the console is not yet setup. > > Based on the log you provided earlier, I would go start to check if the > guest receive the interrupt. > > On the xen console (CTRL-a three times) you can type 'q' it will print > all the IRQ present in the LRs and which IRQ is pending for a given domain. > > Regards, > I've attached the full log from the domain dump below. But the interesting part of the log is: (XEN) Rangesets belonging to domain 1: (XEN) Interrupts { } (XEN) I/O Memory { } Perhaps I am interpreting this incorrectly, but it would seem that no interrupts belong to domain 1? Brandon --------------010104080300000501060902 Content-Type: text/plain; charset="UTF-8"; name="domains.dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="domains.dump" KFhFTikgJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21haW4gaW5mbyAobm93PTB4MTU6Mjc1 OTZGQTgpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOgooWEVOKSAg ICAgcmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wCihYRU4pICAgICBucl9wYWdlcz0z Mjc2OCB4ZW5oZWFwX3BhZ2VzPTUgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0 eV9jcHVzPXt9IG1heF9wYWdlcz00Mjk0OTY3NQooWEVOKSAgICAgaGFuZGxlPTAwMDAwMDAw LTAwMDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCB2bV9hc3Npc3Q9MDAwMDAwMDAKKFhFTikg ICAgIHdhdGNoZG9nIDAgZXhwaXJlcyBpbiAyMCBzZWNvbmRzCihYRU4pIHAybSBtYXBwaW5n cyBmb3IgZG9tYWluIDAgKHZtaWQgMSk6CihYRU4pICAgMUcgbWFwcGluZ3M6IDAgKHNoYXR0 ZXJlZCAwKQooWEVOKSAgIDJNIG1hcHBpbmdzOiAzMDMgKHNoYXR0ZXJlZCA3KQooWEVOKSAg IDRLIG1hcHBpbmdzOiAzOTk3CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu IDA6CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgMzYsIDQxLCA0My00NywgNTItNTMsIDU3LCA2 MC02NywgNjktODAsIDgyLTg2LCA4OC04OSwgOTItOTQsIDk3LTk4LCAxMDgtMTEwLCAxfQoo WEVOKSAgICAgSS9PIE1lbW9yeSB7IDAtMSwgNDA4MDAtNDA4NDgsIDQwZDAwLTQwZDAzLCA0 NDAwMC00NTAwMSwgNDgwMjAtNDgwMjEsIDQ4MDMyLTQ4MDM3LCA0ODAzZS00OH0KKFhFTikg Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDA6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9u IGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAwOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hh cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQ9MDAgdXBjYWxsX21hc2s9MDEgZGlydHlfY3B1cz17 fQooWEVOKSAgICAgY3B1X2hhcmRfYWZmaW5pdHk9ezAtMTI3fSBjcHVfc29mdF9hZmZpbml0 eT17MC0xMjd9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikg R0lDSF9MUnMgKHZjcHUgMCkgbWFzaz0wCihYRU4pICAgIFZDUFVfTFJbMF09MAooWEVOKSAg ICBWQ1BVX0xSWzFdPTAKKFhFTikgICAgVkNQVV9MUlsyXT0wCihYRU4pICAgIFZDUFVfTFJb M109MAooWEVOKSBJbmZsaWdodCBpcnE9NjkgbHI9MjU1CihYRU4pIFBlbmRpbmcgaXJxPTY5 CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u IGZvciBkb21haW4gMToKKFhFTikgICAgIHJlZmNudD0zIGR5aW5nPTAgcGF1c2VfY291bnQ9 MAooWEVOKSAgICAgbnJfcGFnZXM9MzI3NzEgeGVuaGVhcF9wYWdlcz01IHNoYXJlZF9wYWdl cz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MzMwMjQKKFhFTikg ICAgIGhhbmRsZT1iNTdhOTAzNy02MmFjLTRlMDEtYmExYS04MTUyZjMwNzgyMWIgdm1fYXNz aXN0PTAwMDAwMDAwCihYRU4pIHAybSBtYXBwaW5ncyBmb3IgZG9tYWluIDEgKHZtaWQgMik6 CihYRU4pICAgMUcgbWFwcGluZ3M6IDAgKHNoYXR0ZXJlZCAwKQooWEVOKSAgIDJNIG1hcHBp bmdzOiA2MyAoc2hhdHRlcmVkIDEpCihYRU4pICAgNEsgbWFwcGluZ3M6IDUxOQooWEVOKSBS YW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAxOgooWEVOKSAgICAgSW50ZXJydXB0cyB7 IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv bWFpbiAxOiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBk b21haW4gMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w ZW5kPTAwIHVwY2FsbF9tYXNrPTAxIGRpcnR5X2NwdXM9e30KKFhFTikgICAgIGNwdV9oYXJk X2FmZmluaXR5PXswLTEyN30gY3B1X3NvZnRfYWZmaW5pdHk9ezB9CihYRU4pICAgICBwYXVz ZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEKKFhFTikgR0lDSF9MUnMgKHZjcHUgMCkgbWFzaz0w CihYRU4pICAgIFZDUFVfTFJbMF09MAooWEVOKSAgICBWQ1BVX0xSWzFdPTAKKFhFTikgICAg VkNQVV9MUlsyXT0wCihYRU4pICAgIFZDUFVfTFJbM109MAooWEVOKSAgICAgTm8gcGVyaW9k aWMgdGltZXIKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDA6MCAodmlycSAxLCBwb3J0IDApCihY RU4pIE5vdGlmeWluZyBndWVzdCAxOjAgKHZpcnEgMSwgcG9ydCAwKQoK --------------010104080300000501060902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------010104080300000501060902-- From xen-users-bounces@lists.xen.org Wed Jul 08 15:37:21 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 08 Jul 2015 15:37:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCrP1-0000Nj-6S; Wed, 08 Jul 2015 15:36:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZCrOz-0000MF-0g for xen-users@lists.xen.org; Wed, 08 Jul 2015 15:36:49 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id DE/27-30658-0934D955; Wed, 08 Jul 2015 15:36:48 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1436369806!30377100!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22898 invoked from network); 8 Jul 2015 15:36:47 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-9.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Jul 2015 15:36:47 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t68Fahh0006079; Wed, 8 Jul 2015 10:36:43 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t68Fag3q016150; Wed, 8 Jul 2015 10:36:42 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 8 Jul 2015 10:36:28 -0500 Message-ID: <559D357D.3030002@ti.com> Date: Wed, 8 Jul 2015 10:36:45 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> In-Reply-To: <559D3F44.5080607@citrix.com> Content-Type: multipart/mixed; boundary="------------010104080300000501060902" X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------010104080300000501060902 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/08/2015 11:18 AM, Julien Grall wrote: > On 08/07/15 15:07, Brandon Perez wrote: >> On 07/08/2015 11:00 AM, Ian Campbell wrote: >>> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>>> sysrq key, you might find pressing some of those might show what is >>>>> going on. >>>>> >>>> >>>> If I press the sysrq key combinations, while attached to the guest >>>> with "xl console", Dom0 responds with the appropriate message, but the >>>> DomU guest does not acknowledge the sysrq keys. >>> >>> If you are logged in via the dom0 console to run xl console to get the >>> guest console then I think dom0 will eat the Ctrl-o. Not sure if >>> something like Ctrl-o Ctrl-o will work. "xl sysrq " should >>> do the same sort of thing I think. >>> >>> Ian. >>> >>>>> Otherwise I'm completely stumped. It's probably worth going back to the >>>>> data sheet and making sure everything matches in the DTS, in particular >>>>> for virtulisation extension related things which might not be used by >>>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>>> that's getting a bit desperate. >>>>> >>>>> Ian. >>>>> >>> >>> >> >> The guest doesn't respond to any of the sysrq key combinations, I >> tried with both of the methods. > > Which is expected because the console is not yet setup. > > Based on the log you provided earlier, I would go start to check if the > guest receive the interrupt. > > On the xen console (CTRL-a three times) you can type 'q' it will print > all the IRQ present in the LRs and which IRQ is pending for a given domain. > > Regards, > I've attached the full log from the domain dump below. But the interesting part of the log is: (XEN) Rangesets belonging to domain 1: (XEN) Interrupts { } (XEN) I/O Memory { } Perhaps I am interpreting this incorrectly, but it would seem that no interrupts belong to domain 1? Brandon --------------010104080300000501060902 Content-Type: text/plain; charset="UTF-8"; name="domains.dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="domains.dump" KFhFTikgJ3EnIHByZXNzZWQgLT4gZHVtcGluZyBkb21haW4gaW5mbyAobm93PTB4MTU6Mjc1 OTZGQTgpCihYRU4pIEdlbmVyYWwgaW5mb3JtYXRpb24gZm9yIGRvbWFpbiAwOgooWEVOKSAg ICAgcmVmY250PTMgZHlpbmc9MCBwYXVzZV9jb3VudD0wCihYRU4pICAgICBucl9wYWdlcz0z Mjc2OCB4ZW5oZWFwX3BhZ2VzPTUgc2hhcmVkX3BhZ2VzPTAgcGFnZWRfcGFnZXM9MCBkaXJ0 eV9jcHVzPXt9IG1heF9wYWdlcz00Mjk0OTY3NQooWEVOKSAgICAgaGFuZGxlPTAwMDAwMDAw LTAwMDAtMDAwMC0wMDAwLTAwMDAwMDAwMDAwMCB2bV9hc3Npc3Q9MDAwMDAwMDAKKFhFTikg ICAgIHdhdGNoZG9nIDAgZXhwaXJlcyBpbiAyMCBzZWNvbmRzCihYRU4pIHAybSBtYXBwaW5n cyBmb3IgZG9tYWluIDAgKHZtaWQgMSk6CihYRU4pICAgMUcgbWFwcGluZ3M6IDAgKHNoYXR0 ZXJlZCAwKQooWEVOKSAgIDJNIG1hcHBpbmdzOiAzMDMgKHNoYXR0ZXJlZCA3KQooWEVOKSAg IDRLIG1hcHBpbmdzOiAzOTk3CihYRU4pIFJhbmdlc2V0cyBiZWxvbmdpbmcgdG8gZG9tYWlu IDA6CihYRU4pICAgICBJbnRlcnJ1cHRzIHsgMzYsIDQxLCA0My00NywgNTItNTMsIDU3LCA2 MC02NywgNjktODAsIDgyLTg2LCA4OC04OSwgOTItOTQsIDk3LTk4LCAxMDgtMTEwLCAxfQoo WEVOKSAgICAgSS9PIE1lbW9yeSB7IDAtMSwgNDA4MDAtNDA4NDgsIDQwZDAwLTQwZDAzLCA0 NDAwMC00NTAwMSwgNDgwMjAtNDgwMjEsIDQ4MDMyLTQ4MDM3LCA0ODAzZS00OH0KKFhFTikg Tk9ERSBhZmZpbml0eSBmb3IgZG9tYWluIDA6IFswXQooWEVOKSBWQ1BVIGluZm9ybWF0aW9u IGFuZCBjYWxsYmFja3MgZm9yIGRvbWFpbiAwOgooWEVOKSAgICAgVkNQVTA6IENQVTAgW2hh cz1GXSBwb2xsPTAgdXBjYWxsX3BlbmQ9MDAgdXBjYWxsX21hc2s9MDEgZGlydHlfY3B1cz17 fQooWEVOKSAgICAgY3B1X2hhcmRfYWZmaW5pdHk9ezAtMTI3fSBjcHVfc29mdF9hZmZpbml0 eT17MC0xMjd9CihYRU4pICAgICBwYXVzZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTAKKFhFTikg R0lDSF9MUnMgKHZjcHUgMCkgbWFzaz0wCihYRU4pICAgIFZDUFVfTFJbMF09MAooWEVOKSAg ICBWQ1BVX0xSWzFdPTAKKFhFTikgICAgVkNQVV9MUlsyXT0wCihYRU4pICAgIFZDUFVfTFJb M109MAooWEVOKSBJbmZsaWdodCBpcnE9NjkgbHI9MjU1CihYRU4pIFBlbmRpbmcgaXJxPTY5 CihYRU4pICAgICBObyBwZXJpb2RpYyB0aW1lcgooWEVOKSBHZW5lcmFsIGluZm9ybWF0aW9u IGZvciBkb21haW4gMToKKFhFTikgICAgIHJlZmNudD0zIGR5aW5nPTAgcGF1c2VfY291bnQ9 MAooWEVOKSAgICAgbnJfcGFnZXM9MzI3NzEgeGVuaGVhcF9wYWdlcz01IHNoYXJlZF9wYWdl cz0wIHBhZ2VkX3BhZ2VzPTAgZGlydHlfY3B1cz17fSBtYXhfcGFnZXM9MzMwMjQKKFhFTikg ICAgIGhhbmRsZT1iNTdhOTAzNy02MmFjLTRlMDEtYmExYS04MTUyZjMwNzgyMWIgdm1fYXNz aXN0PTAwMDAwMDAwCihYRU4pIHAybSBtYXBwaW5ncyBmb3IgZG9tYWluIDEgKHZtaWQgMik6 CihYRU4pICAgMUcgbWFwcGluZ3M6IDAgKHNoYXR0ZXJlZCAwKQooWEVOKSAgIDJNIG1hcHBp bmdzOiA2MyAoc2hhdHRlcmVkIDEpCihYRU4pICAgNEsgbWFwcGluZ3M6IDUxOQooWEVOKSBS YW5nZXNldHMgYmVsb25naW5nIHRvIGRvbWFpbiAxOgooWEVOKSAgICAgSW50ZXJydXB0cyB7 IH0KKFhFTikgICAgIEkvTyBNZW1vcnkgeyB9CihYRU4pIE5PREUgYWZmaW5pdHkgZm9yIGRv bWFpbiAxOiBbMF0KKFhFTikgVkNQVSBpbmZvcm1hdGlvbiBhbmQgY2FsbGJhY2tzIGZvciBk b21haW4gMToKKFhFTikgICAgIFZDUFUwOiBDUFUwIFtoYXM9Rl0gcG9sbD0wIHVwY2FsbF9w ZW5kPTAwIHVwY2FsbF9tYXNrPTAxIGRpcnR5X2NwdXM9e30KKFhFTikgICAgIGNwdV9oYXJk X2FmZmluaXR5PXswLTEyN30gY3B1X3NvZnRfYWZmaW5pdHk9ezB9CihYRU4pICAgICBwYXVz ZV9jb3VudD0wIHBhdXNlX2ZsYWdzPTEKKFhFTikgR0lDSF9MUnMgKHZjcHUgMCkgbWFzaz0w CihYRU4pICAgIFZDUFVfTFJbMF09MAooWEVOKSAgICBWQ1BVX0xSWzFdPTAKKFhFTikgICAg VkNQVV9MUlsyXT0wCihYRU4pICAgIFZDUFVfTFJbM109MAooWEVOKSAgICAgTm8gcGVyaW9k aWMgdGltZXIKKFhFTikgTm90aWZ5aW5nIGd1ZXN0IDA6MCAodmlycSAxLCBwb3J0IDApCihY RU4pIE5vdGlmeWluZyBndWVzdCAxOjAgKHZpcnEgMSwgcG9ydCAwKQoK --------------010104080300000501060902 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------010104080300000501060902-- From xen-users-bounces@lists.xen.org Thu Jul 09 07:35:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 07:35:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD6LU-0003qq-Od; Thu, 09 Jul 2015 07:34:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD6LT-0003ql-Nm for xen-users@lists.xen.org; Thu, 09 Jul 2015 07:34:11 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 96/0C-31258-3F32E955; Thu, 09 Jul 2015 07:34:11 +0000 X-Env-Sender: prvs=625981f15=julien.grall@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436427249!30504643!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21541 invoked from network); 9 Jul 2015 07:34:10 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 07:34:10 -0000 X-IronPort-AV: E=Sophos;i="5.15,438,1432598400"; d="scan'208";a="282471805" Message-ID: <559E23ED.5000404@citrix.com> Date: Thu, 9 Jul 2015 08:34:05 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> In-Reply-To: <559D357D.3030002@ti.com> X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Brandon, On 08/07/2015 15:36, Brandon Perez wrote: > On 07/08/2015 11:18 AM, Julien Grall wrote: >> On 08/07/15 15:07, Brandon Perez wrote: >>> On 07/08/2015 11:00 AM, Ian Campbell wrote: >>>> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>>>> sysrq key, you might find pressing some of those might show what is >>>>>> going on. >>>>>> >>>>> >>>>> If I press the sysrq key combinations, while attached to the >>>>> guest >>>>> with "xl console", Dom0 responds with the appropriate message, but the >>>>> DomU guest does not acknowledge the sysrq keys. >>>> >>>> If you are logged in via the dom0 console to run xl console to get the >>>> guest console then I think dom0 will eat the Ctrl-o. Not sure if >>>> something like Ctrl-o Ctrl-o will work. "xl sysrq " >>>> should >>>> do the same sort of thing I think. >>>> >>>> Ian. >>>> >>>>>> Otherwise I'm completely stumped. It's probably worth going back >>>>>> to the >>>>>> data sheet and making sure everything matches in the DTS, in >>>>>> particular >>>>>> for virtulisation extension related things which might not be used by >>>>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>>>> that's getting a bit desperate. >>>>>> >>>>>> Ian. >>>>>> >>>> >>>> >>> >>> The guest doesn't respond to any of the sysrq key combinations, I >>> tried with both of the methods. >> >> Which is expected because the console is not yet setup. >> >> Based on the log you provided earlier, I would go start to check if the >> guest receive the interrupt. >> >> On the xen console (CTRL-a three times) you can type 'q' it will print >> all the IRQ present in the LRs and which IRQ is pending for a given >> domain. >> >> Regards, >> > > I've attached the full log from the domain dump below. But the > interesting part of the log is: > > (XEN) Rangesets belonging to domain 1: > (XEN) Interrupts { } > (XEN) I/O Memory { } > > Perhaps I am interpreting this incorrectly, but it would seem that > no interrupts belong to domain 1? These rangesets list the interrupt and I/O memory assigned to the guest (i.e passthrough). In the case of the timer interrupt (physical and virtual), they are owned by Xen and Xen will emulated it for each guest. From the logs the LRs are empty (see VCPU_LR) and no interrupts are currently pending. I would add some printk in function gic_handle_irq in Linux (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 07:35:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 07:35:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD6LU-0003qq-Od; Thu, 09 Jul 2015 07:34:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD6LT-0003ql-Nm for xen-users@lists.xen.org; Thu, 09 Jul 2015 07:34:11 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 96/0C-31258-3F32E955; Thu, 09 Jul 2015 07:34:11 +0000 X-Env-Sender: prvs=625981f15=julien.grall@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436427249!30504643!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21541 invoked from network); 9 Jul 2015 07:34:10 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 07:34:10 -0000 X-IronPort-AV: E=Sophos;i="5.15,438,1432598400"; d="scan'208";a="282471805" Message-ID: <559E23ED.5000404@citrix.com> Date: Thu, 9 Jul 2015 08:34:05 +0100 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> In-Reply-To: <559D357D.3030002@ti.com> X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Brandon, On 08/07/2015 15:36, Brandon Perez wrote: > On 07/08/2015 11:18 AM, Julien Grall wrote: >> On 08/07/15 15:07, Brandon Perez wrote: >>> On 07/08/2015 11:00 AM, Ian Campbell wrote: >>>> On Wed, 2015-07-08 at 09:54 -0400, Brandon Perez wrote: >>>>>> Pressing Ctrl-o on a xen guest console is the equivalent of the magic >>>>>> sysrq key, you might find pressing some of those might show what is >>>>>> going on. >>>>>> >>>>> >>>>> If I press the sysrq key combinations, while attached to the >>>>> guest >>>>> with "xl console", Dom0 responds with the appropriate message, but the >>>>> DomU guest does not acknowledge the sysrq keys. >>>> >>>> If you are logged in via the dom0 console to run xl console to get the >>>> guest console then I think dom0 will eat the Ctrl-o. Not sure if >>>> something like Ctrl-o Ctrl-o will work. "xl sysrq " >>>> should >>>> do the same sort of thing I think. >>>> >>>> Ian. >>>> >>>>>> Otherwise I'm completely stumped. It's probably worth going back >>>>>> to the >>>>>> data sheet and making sure everything matches in the DTS, in >>>>>> particular >>>>>> for virtulisation extension related things which might not be used by >>>>>> native Linux (e,g, the vtimer interrupt SPI number etc), but really >>>>>> that's getting a bit desperate. >>>>>> >>>>>> Ian. >>>>>> >>>> >>>> >>> >>> The guest doesn't respond to any of the sysrq key combinations, I >>> tried with both of the methods. >> >> Which is expected because the console is not yet setup. >> >> Based on the log you provided earlier, I would go start to check if the >> guest receive the interrupt. >> >> On the xen console (CTRL-a three times) you can type 'q' it will print >> all the IRQ present in the LRs and which IRQ is pending for a given >> domain. >> >> Regards, >> > > I've attached the full log from the domain dump below. But the > interesting part of the log is: > > (XEN) Rangesets belonging to domain 1: > (XEN) Interrupts { } > (XEN) I/O Memory { } > > Perhaps I am interpreting this incorrectly, but it would seem that > no interrupts belong to domain 1? These rangesets list the interrupt and I/O memory assigned to the guest (i.e passthrough). In the case of the timer interrupt (physical and virtual), they are owned by Xen and Xen will emulated it for each guest. From the logs the LRs are empty (see VCPU_LR) and no interrupts are currently pending. I would add some printk in function gic_handle_irq in Linux (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 10:13:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 10:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD8oZ-0004OE-Gt; Thu, 09 Jul 2015 10:12:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD8oX-0004O4-Ln for xen-users@lists.xen.org; Thu, 09 Jul 2015 10:12:21 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 56/F7-17050-4094E955; Thu, 09 Jul 2015 10:12:20 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1436436736!24234891!1 X-Originating-IP: [209.85.192.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22565 invoked from network); 9 Jul 2015 10:12:17 -0000 Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com) (209.85.192.50) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 10:12:17 -0000 Received: by qget71 with SMTP id t71so112942903qge.2 for ; Thu, 09 Jul 2015 03:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=UFj4JD4HNE/tZheEyaoGwrChNX7HobgGXlAJXAbMqeg=; b=TLFORfZrI6favKx6E4+7Bz5QiRhVvMF3g6ZkP48IafmPsVia5EJJPVs3n82+UkOaTf 8atYJpz+5noa88lwwqDSQalPia0YKU4uW9IGiwv52YoqIzExjPXfAUfhJ7gpukqMTc0b gfEyFUjOJ5RZ2k84VIx4aIhdfmplomZkLYtLOoxTX3vX1kL7hyUsI5iZXHHRvA9PlHaw Suk72oiXJzOMUaA6YzeLkHoEdcAUFSN+GlLNVBCZ2rt+papAqsX/bqzrcMGPT9qnL8Ji pUE5Ojuh93fOGoH2zGw65JeUZUq1NuDD5jK8LoJ+gFG9ErzFZnwCTNcoqdP6TOuMmV49 yY+A== X-Gm-Message-State: ALoCoQn+mINjXFudyiNjrmBc8/rah9vqeaxeyJtlXlwB3ddNn1jDimPByDOFzCFYvdelZYvYoIsu MIME-Version: 1.0 X-Received: by 10.55.42.35 with SMTP id q35mr22881141qkh.46.1436436736434; Thu, 09 Jul 2015 03:12:16 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Thu, 9 Jul 2015 03:12:16 -0700 (PDT) Date: Thu, 9 Jul 2015 11:12:16 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3447993623329223678==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3447993623329223678== Content-Type: multipart/alternative; boundary=001a11494ab66b0362051a6e7d26 --001a11494ab66b0362051a6e7d26 Content-Type: text/plain; charset=UTF-8 Hi all, I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, using routed networking. So far, it looks like the requests aren't making it to the DHCP server. I've played with vif-route a bit (static address work fine, btw), but so far no joy. /etc/default/interfaces includes: auto xenbr0 iface xenbr0 inet static address 192.168.1.1 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 pre-up brctl addbr $IFACE up ip link set $IFACE up post-down brctl delbr $IFACE down ip link set $IFACE down VM config: memory = 1024 # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 8 name = "nfsboot" vif = [ 'script=vif-route' ] disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] #bootloader = "pygrub" kernel = "/srv/xen/web/vmlinuz.netboot" ramdisk = "/srv/xen/web/initrd.gz" /etc/default/isc-dhcp-server includes INTERFACES="xenbr0" /etc/dhcp/dhcpd.conf includes: subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option broadcast-address 192.168.1.255; range 192.168.1.3 192.168.1.254; } I'm stumped! --001a11494ab66b0362051a6e7d26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm= trying to confugre DHCP on Dom0 to server up addresses to DomU, using rout= ed networking. So far, it looks like the requests aren't making it to t= he DHCP server.

I've played with vif-route a bit (sta= tic address work fine, btw), but so far no joy.

/etc/default/i= nterfaces includes:

auto xenbr0
iface xenbr0 inet static
=C2= =A0=C2=A0=C2=A0 address 192.168.1.1
=C2=A0=C2=A0=C2=A0 network 192.168.1= .0
=C2=A0=C2=A0=C2=A0 netmask 255.255.255.0
=C2=A0=C2=A0=C2=A0 broadc= ast 192.168.1.255
=C2=A0=C2=A0=C2=A0 pre-up brctl addbr $IFACE
=C2=A0= =C2=A0=C2=A0 up ip link set $IFACE up
=C2=A0=C2=A0=C2=A0 post-down brctl= delbr $IFACE
=C2=A0=C2=A0=C2=A0 down ip link set $IFACE down

VM config:
memory =3D 1024

# Should be at least 2KB per MB of = domain memory, plus a few MB per vcpu.
shadow_memory =3D 8
name =3D &= quot;nfsboot"
vif =3D [ 'script=3Dvif-route' ]
disk =3D = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ]

#bootloader = =3D "pygrub"

kernel =3D "/srv/xen/web/vmlinuz.netboot= "
ramdisk =3D "/srv/xen/web/initrd.gz"

/etc/= default/isc-dhcp-server includes INTERFACES=3D"xenbr0"

/etc/dhcp/dhcpd.conf includes:
subnet 192.168.1.0 netmask 255.255.255= .0 {
=C2=A0 option routers 192.168.1.1;
=C2=A0 option broadcast-addre= ss 192.168.1.255;
=C2=A0 range 192.168.1.3 192.168.1.254;
}

I'm stumped!
--001a11494ab66b0362051a6e7d26-- --===============3447993623329223678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3447993623329223678==-- From xen-users-bounces@lists.xen.org Thu Jul 09 10:13:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 10:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD8oZ-0004OE-Gt; Thu, 09 Jul 2015 10:12:23 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD8oX-0004O4-Ln for xen-users@lists.xen.org; Thu, 09 Jul 2015 10:12:21 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 56/F7-17050-4094E955; Thu, 09 Jul 2015 10:12:20 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-3.tower-31.messagelabs.com!1436436736!24234891!1 X-Originating-IP: [209.85.192.50] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22565 invoked from network); 9 Jul 2015 10:12:17 -0000 Received: from mail-qg0-f50.google.com (HELO mail-qg0-f50.google.com) (209.85.192.50) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 10:12:17 -0000 Received: by qget71 with SMTP id t71so112942903qge.2 for ; Thu, 09 Jul 2015 03:12:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=UFj4JD4HNE/tZheEyaoGwrChNX7HobgGXlAJXAbMqeg=; b=TLFORfZrI6favKx6E4+7Bz5QiRhVvMF3g6ZkP48IafmPsVia5EJJPVs3n82+UkOaTf 8atYJpz+5noa88lwwqDSQalPia0YKU4uW9IGiwv52YoqIzExjPXfAUfhJ7gpukqMTc0b gfEyFUjOJ5RZ2k84VIx4aIhdfmplomZkLYtLOoxTX3vX1kL7hyUsI5iZXHHRvA9PlHaw Suk72oiXJzOMUaA6YzeLkHoEdcAUFSN+GlLNVBCZ2rt+papAqsX/bqzrcMGPT9qnL8Ji pUE5Ojuh93fOGoH2zGw65JeUZUq1NuDD5jK8LoJ+gFG9ErzFZnwCTNcoqdP6TOuMmV49 yY+A== X-Gm-Message-State: ALoCoQn+mINjXFudyiNjrmBc8/rah9vqeaxeyJtlXlwB3ddNn1jDimPByDOFzCFYvdelZYvYoIsu MIME-Version: 1.0 X-Received: by 10.55.42.35 with SMTP id q35mr22881141qkh.46.1436436736434; Thu, 09 Jul 2015 03:12:16 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Thu, 9 Jul 2015 03:12:16 -0700 (PDT) Date: Thu, 9 Jul 2015 11:12:16 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3447993623329223678==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3447993623329223678== Content-Type: multipart/alternative; boundary=001a11494ab66b0362051a6e7d26 --001a11494ab66b0362051a6e7d26 Content-Type: text/plain; charset=UTF-8 Hi all, I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, using routed networking. So far, it looks like the requests aren't making it to the DHCP server. I've played with vif-route a bit (static address work fine, btw), but so far no joy. /etc/default/interfaces includes: auto xenbr0 iface xenbr0 inet static address 192.168.1.1 network 192.168.1.0 netmask 255.255.255.0 broadcast 192.168.1.255 pre-up brctl addbr $IFACE up ip link set $IFACE up post-down brctl delbr $IFACE down ip link set $IFACE down VM config: memory = 1024 # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 8 name = "nfsboot" vif = [ 'script=vif-route' ] disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] #bootloader = "pygrub" kernel = "/srv/xen/web/vmlinuz.netboot" ramdisk = "/srv/xen/web/initrd.gz" /etc/default/isc-dhcp-server includes INTERFACES="xenbr0" /etc/dhcp/dhcpd.conf includes: subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.1; option broadcast-address 192.168.1.255; range 192.168.1.3 192.168.1.254; } I'm stumped! --001a11494ab66b0362051a6e7d26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I'm= trying to confugre DHCP on Dom0 to server up addresses to DomU, using rout= ed networking. So far, it looks like the requests aren't making it to t= he DHCP server.

I've played with vif-route a bit (sta= tic address work fine, btw), but so far no joy.

/etc/default/i= nterfaces includes:

auto xenbr0
iface xenbr0 inet static
=C2= =A0=C2=A0=C2=A0 address 192.168.1.1
=C2=A0=C2=A0=C2=A0 network 192.168.1= .0
=C2=A0=C2=A0=C2=A0 netmask 255.255.255.0
=C2=A0=C2=A0=C2=A0 broadc= ast 192.168.1.255
=C2=A0=C2=A0=C2=A0 pre-up brctl addbr $IFACE
=C2=A0= =C2=A0=C2=A0 up ip link set $IFACE up
=C2=A0=C2=A0=C2=A0 post-down brctl= delbr $IFACE
=C2=A0=C2=A0=C2=A0 down ip link set $IFACE down

VM config:
memory =3D 1024

# Should be at least 2KB per MB of = domain memory, plus a few MB per vcpu.
shadow_memory =3D 8
name =3D &= quot;nfsboot"
vif =3D [ 'script=3Dvif-route' ]
disk =3D = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ]

#bootloader = =3D "pygrub"

kernel =3D "/srv/xen/web/vmlinuz.netboot= "
ramdisk =3D "/srv/xen/web/initrd.gz"

/etc/= default/isc-dhcp-server includes INTERFACES=3D"xenbr0"

/etc/dhcp/dhcpd.conf includes:
subnet 192.168.1.0 netmask 255.255.255= .0 {
=C2=A0 option routers 192.168.1.1;
=C2=A0 option broadcast-addre= ss 192.168.1.255;
=C2=A0 range 192.168.1.3 192.168.1.254;
}

I'm stumped!
--001a11494ab66b0362051a6e7d26-- --===============3447993623329223678== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3447993623329223678==-- From xen-users-bounces@lists.xen.org Thu Jul 09 11:24:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 11:24:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD9vq-00022M-DM; Thu, 09 Jul 2015 11:23:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD9vo-00022H-VV for xen-users@lists.xen.org; Thu, 09 Jul 2015 11:23:57 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id D0/39-19853-BC95E955; Thu, 09 Jul 2015 11:23:55 +0000 X-Env-Sender: linux@thehobsons.co.uk X-Msg-Ref: server-9.tower-206.messagelabs.com!1436441034!20011971!1 X-Originating-IP: [81.174.135.208] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26837 invoked from network); 9 Jul 2015 11:23:54 -0000 Received: from patsy.thehobsons.co.uk (HELO patsy.thehobsons.co.uk) (81.174.135.208) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 11:23:54 -0000 X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.22] (lan.furness.net [77.233.151.255]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 85E681402B for ; Thu, 9 Jul 2015 11:23:51 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Thu, 9 Jul 2015 12:23:50 +0100 Message-Id: References: To: "xen-users@lists.xen.org" X-Mailer: Apple Mail (2.1510) Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Phil Lello wrote: > /etc/default/interfaces includes: > > auto xenbr0 > iface xenbr0 inet static > address 192.168.1.1 > network 192.168.1.0 > netmask 255.255.255.0 > broadcast 192.168.1.255 > pre-up brctl addbr $IFACE > up ip link set $IFACE up > post-down brctl delbr $IFACE > down ip link set $IFACE down That's an old way of doing it. These days the OS will take care of it by itself - at least Debian has for a long time, I assume Ubuntu has followed suit. auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 192.168.1.1 netmask 255.255.255.0 I don't bother specifying network or broadcast - it's just more to get wrong and the system will figure them out automatically. Also, you want to make sure there are no "network managers" or similar running - for this sort of system they are not needed and will just get in the way. > vif = [ 'script=vif-route' ] I prefer to explicitly specify the bridge - partly because all of my hosts have multiple bridges configured. vif = [ 'script=vif-route,bridge=xenbr0' ] Other than that I can see one reason it might not work. The ISC server only supports broadcast interfaces* - and I don't know whether a direct attachment to a bridge like that looks enough like an ethernet interface to work. What does the server log as it starts up ? It's to do with the way it must bypass the IP stack for some operations. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 11:24:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 11:24:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD9vq-00022M-DM; Thu, 09 Jul 2015 11:23:58 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZD9vo-00022H-VV for xen-users@lists.xen.org; Thu, 09 Jul 2015 11:23:57 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id D0/39-19853-BC95E955; Thu, 09 Jul 2015 11:23:55 +0000 X-Env-Sender: linux@thehobsons.co.uk X-Msg-Ref: server-9.tower-206.messagelabs.com!1436441034!20011971!1 X-Originating-IP: [81.174.135.208] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26837 invoked from network); 9 Jul 2015 11:23:54 -0000 Received: from patsy.thehobsons.co.uk (HELO patsy.thehobsons.co.uk) (81.174.135.208) by server-9.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 11:23:54 -0000 X-Virus-Scanned: Debian amavisd-new at patsy.thehobsons.co.uk Received: from [192.168.1.22] (lan.furness.net [77.233.151.255]) by patsy.thehobsons.co.uk (Postfix) with ESMTPSA id 85E681402B for ; Thu, 9 Jul 2015 11:23:51 +0000 (UTC) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Simon Hobson In-Reply-To: Date: Thu, 9 Jul 2015 12:23:50 +0100 Message-Id: References: To: "xen-users@lists.xen.org" X-Mailer: Apple Mail (2.1510) Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Phil Lello wrote: > /etc/default/interfaces includes: > > auto xenbr0 > iface xenbr0 inet static > address 192.168.1.1 > network 192.168.1.0 > netmask 255.255.255.0 > broadcast 192.168.1.255 > pre-up brctl addbr $IFACE > up ip link set $IFACE up > post-down brctl delbr $IFACE > down ip link set $IFACE down That's an old way of doing it. These days the OS will take care of it by itself - at least Debian has for a long time, I assume Ubuntu has followed suit. auto xenbr0 iface xenbr0 inet static bridge_ports eth0 address 192.168.1.1 netmask 255.255.255.0 I don't bother specifying network or broadcast - it's just more to get wrong and the system will figure them out automatically. Also, you want to make sure there are no "network managers" or similar running - for this sort of system they are not needed and will just get in the way. > vif = [ 'script=vif-route' ] I prefer to explicitly specify the bridge - partly because all of my hosts have multiple bridges configured. vif = [ 'script=vif-route,bridge=xenbr0' ] Other than that I can see one reason it might not work. The ISC server only supports broadcast interfaces* - and I don't know whether a direct attachment to a bridge like that looks enough like an ethernet interface to work. What does the server log as it starts up ? It's to do with the way it must bypass the IP stack for some operations. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 11:44:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 11:44:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAFY-0003Ju-Vi; Thu, 09 Jul 2015 11:44:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAFX-0003Jl-GA for xen-users@lists.xen.org; Thu, 09 Jul 2015 11:44:19 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 2C/A3-10437-29E5E955; Thu, 09 Jul 2015 11:44:18 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436442250!24274610!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11586 invoked from network); 9 Jul 2015 11:44:12 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 11:44:12 -0000 X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="282523962" Message-ID: <1436442225.23508.118.camel@citrix.com> From: Ian Campbell To: Phil Lello Date: Thu, 9 Jul 2015 12:43:45 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 11:12 +0100, Phil Lello wrote: > Hi all, > > > I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, > using routed networking Normally routed networking[0] would imply no bridge, but rather some routing/firewall(NAT) tables in domain 0. In particular vif-route won't put any virtual interfaces onto the bridge, because it assumes things will be routed. Perhaps you are trying to build a "brouter"[1]? I don't know much about this configuration or how it is supposed to work, but I do notice that the document linked from [1] at [2] uses vif-bridge not vif-route (I'd recommend ignoring the xend specfic network-* scripting there and setting it up via the distro mechanisms such as /etc/default/interfaces). HTH, Ian. [0] http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing [1] http://wiki.xen.org/wiki/Xen_Networking#Advanced_configurations [2] https://tr.opensuse.org/Xen3_and_a_Virtual_Network _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 11:44:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 11:44:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAFY-0003Ju-Vi; Thu, 09 Jul 2015 11:44:20 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAFX-0003Jl-GA for xen-users@lists.xen.org; Thu, 09 Jul 2015 11:44:19 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 2C/A3-10437-29E5E955; Thu, 09 Jul 2015 11:44:18 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436442250!24274610!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11586 invoked from network); 9 Jul 2015 11:44:12 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 11:44:12 -0000 X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="282523962" Message-ID: <1436442225.23508.118.camel@citrix.com> From: Ian Campbell To: Phil Lello Date: Thu, 9 Jul 2015 12:43:45 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 11:12 +0100, Phil Lello wrote: > Hi all, > > > I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, > using routed networking Normally routed networking[0] would imply no bridge, but rather some routing/firewall(NAT) tables in domain 0. In particular vif-route won't put any virtual interfaces onto the bridge, because it assumes things will be routed. Perhaps you are trying to build a "brouter"[1]? I don't know much about this configuration or how it is supposed to work, but I do notice that the document linked from [1] at [2] uses vif-bridge not vif-route (I'd recommend ignoring the xend specfic network-* scripting there and setting it up via the distro mechanisms such as /etc/default/interfaces). HTH, Ian. [0] http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing [1] http://wiki.xen.org/wiki/Xen_Networking#Advanced_configurations [2] https://tr.opensuse.org/Xen3_and_a_Virtual_Network _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 12:06:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 12:06:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAb5-0005Fl-A8; Thu, 09 Jul 2015 12:06:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAb3-0005EJ-Jb for xen-users@lists.xen.org; Thu, 09 Jul 2015 12:06:33 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id EE/F8-13517-8C36E955; Thu, 09 Jul 2015 12:06:32 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1436443591!24233208!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6453 invoked from network); 9 Jul 2015 12:06:32 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 12:06:32 -0000 X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="279464664" Message-ID: <1436443588.23508.127.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Thu, 9 Jul 2015 13:06:28 +0100 In-Reply-To: <559D357D.3030002@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 10:36 -0400, Brandon Perez wrote: > I've attached the full log from the domain dump below. But the > interesting part of the log is: > > (XEN) Rangesets belonging to domain 1: > (XEN) Interrupts { } > (XEN) I/O Memory { } > > Perhaps I am interpreting this incorrectly, but it would seem that > no interrupts belong to domain 1? As Julien says these only list actual physical interrupts so it's expected unless you are doing passthrough. As well as what Julien suggests you could try running "$prefix/lib/xen/bin/xenctx 0" to get full register state. You could also perhaps try disabling HCR_EL2.TWI and/or TWE (trap wait for interrupts and events respectively). Ages ago we had some bugs in these areas, those are thought to be long gone, but it's worth checking. AIUI you are running the same 3.14/android kernel in both dom0 and domU. Do you have the option of running a newer mainline kernel on your platform, to rule out either changes made in the Android branch or issues in the 3.14 kernel which have been fixed since. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 12:06:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 12:06:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAb5-0005Fl-A8; Thu, 09 Jul 2015 12:06:35 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDAb3-0005EJ-Jb for xen-users@lists.xen.org; Thu, 09 Jul 2015 12:06:33 +0000 Received: from [85.158.137.68] by server-6.bemta-3.messagelabs.com id EE/F8-13517-8C36E955; Thu, 09 Jul 2015 12:06:32 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1436443591!24233208!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6453 invoked from network); 9 Jul 2015 12:06:32 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-7.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 12:06:32 -0000 X-IronPort-AV: E=Sophos;i="5.15,439,1432598400"; d="scan'208";a="279464664" Message-ID: <1436443588.23508.127.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Thu, 9 Jul 2015 13:06:28 +0100 In-Reply-To: <559D357D.3030002@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-08 at 10:36 -0400, Brandon Perez wrote: > I've attached the full log from the domain dump below. But the > interesting part of the log is: > > (XEN) Rangesets belonging to domain 1: > (XEN) Interrupts { } > (XEN) I/O Memory { } > > Perhaps I am interpreting this incorrectly, but it would seem that > no interrupts belong to domain 1? As Julien says these only list actual physical interrupts so it's expected unless you are doing passthrough. As well as what Julien suggests you could try running "$prefix/lib/xen/bin/xenctx 0" to get full register state. You could also perhaps try disabling HCR_EL2.TWI and/or TWE (trap wait for interrupts and events respectively). Ages ago we had some bugs in these areas, those are thought to be long gone, but it's worth checking. AIUI you are running the same 3.14/android kernel in both dom0 and domU. Do you have the option of running a newer mainline kernel on your platform, to rule out either changes made in the Android branch or issues in the 3.14 kernel which have been fixed since. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 14:56:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 14:56:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDEt-0003Jz-RU; Thu, 09 Jul 2015 14:55:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDEs-0003J4-J4 for xen-users@lists.xen.org; Thu, 09 Jul 2015 14:55:50 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 98/E1-18733-57B8E955; Thu, 09 Jul 2015 14:55:49 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1436453746!24604969!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8408 invoked from network); 9 Jul 2015 14:55:48 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 14:55:48 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69Etixg003548; Thu, 9 Jul 2015 09:55:44 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69EtiQK029217; Thu, 9 Jul 2015 09:55:44 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 09:55:27 -0500 Message-ID: <559E7D63.3050804@ti.com> Date: Thu, 9 Jul 2015 09:55:47 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> In-Reply-To: <1436443588.23508.127.camel@citrix.com> Content-Type: multipart/mixed; boundary="------------020403030701000905010909" X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020403030701000905010909 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/09/2015 03:34 AM, Julien Grall wrote: > Hi Brandon, > > These rangesets list the interrupt and I/O memory assigned to the guest > (i.e passthrough). > > In the case of the timer interrupt (physical and virtual), they are > owned by Xen and Xen will emulated it for each guest. > > From the logs the LRs are empty (see VCPU_LR) and no interrupts are > currently pending. > > I would add some printk in function gic_handle_irq in Linux > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. > I added that printk statement, and I never see any physical or virtual timer interrupts being delivered to the guest. I believe the guest is using the virtual timer, because when I do a more full register dump with trace32, I see that CNTV_CVAL is programmed to a non-zero value, but CNTP_CVAL is 0. I also noticed the following line during the Dom0 guest boot: (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz Is this expected to be different from the expected interrupt ID's for ARM core timers (these numbers are all offset by +5)? Correct me if I'm wrong, but it seems like gic_handle_irq() is not the control path taken by the PPI timers. It looks like the functions "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) handle those interrupts. Also, based on the following lines in xen/arch/arm/irq.c: 224-226, it seems like that the guests cannot be delivered PPI's from the function "do_IRQ()": /* the irq cannot be a PPI, we only support delivery of SPIs to * guests */ vgic_vcpu_inject_spi(info->d, info->virq); Also, how do the functions in xen/arch/arm/vtimer.c fit into this picture? Would they be the ones responsible for delivering the vtimer interrupt to the guest? > Regards, > On 07/09/2015 08:06 AM, Ian Campbell wrote: > On Wed, 2015-07-08 at 10:36 -0400, Brandon Perez wrote: >> I've attached the full log from the domain dump below. But the >> interesting part of the log is: >> >> (XEN) Rangesets belonging to domain 1: >> (XEN) Interrupts { } >> (XEN) I/O Memory { } >> >> Perhaps I am interpreting this incorrectly, but it would seem that >> no interrupts belong to domain 1? > > As Julien says these only list actual physical interrupts so it's > expected unless you are doing passthrough. > > As well as what Julien suggests you could try running > "$prefix/lib/xen/bin/xenctx 0" to get full register state. I've attached the xenctx dump. > > You could also perhaps try disabling HCR_EL2.TWI and/or TWE (trap wait > for interrupts and events respectively). Ages ago we had some bugs in > these areas, those are thought to be long gone, but it's worth checking. > No luck with that, the guest still doesn't boot successfully. > AIUI you are running the same 3.14/android kernel in both dom0 and domU. > Do you have the option of running a newer mainline kernel on your > platform, to rule out either changes made in the Android branch or > issues in the 3.14 kernel which have been fixed since. > > Ian. > Yes, I'm using the 3.14 kernel for both dom0 and domU. Unfortunately, I need the 3.14 kernel, but if these problems persist, I may try to update to a newer mainline kernel. Brandon --------------020403030701000905010909 Content-Type: text/plain; charset="UTF-8"; name="xenctx_guest.dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xenctx_guest.dump" UEM6ICAgICAgIGMwMDFlYTY4CkNQU1I6ICAgICA2MDAwMDE5MwpVU1I6ICAgICAgICAgICAg ICAgU1A6MDAwMDAwMDAgTFI6MDAwMDAwMDAKU1ZDOiBTUFNSOjYwMDAwMTUzIFNQOmMwODg1 ZjY4IExSOmMwMDBmZGQ0CkZJUTogU1BTUjowMDAwMDAwMCBTUDowMDAwMDAwMCBMUjpjMmMy YzJjMgpJUlE6IFNQU1I6NjAwMDAxZDMgU1A6YzA4ZGE3YzAgTFI6YzA2MjQ1NDAKQUJUOiBT UFNSOjAwMDAwMDAwIFNQOmMwOGRhN2NjIExSOmMwOGRhN2NjClVORDogU1BTUjowMDAwMDAw MCBTUDpjMDhkYTdkOCBMUjpjMDhkYTdkOAoKIHIwX3VzcjogZmZmZmZmZWQgICAgICAgIHIx X3VzcjogMDc2NjIwMDAgICAgICAgIHIyX3VzcjogYzA4OGQ1NzgKIHIzX3VzcjogMDAwMDAw MDAgICAgICAgIHI0X3VzcjogYzA4ODQwMDAgICAgICAgIHI1X3VzcjogYzA4OGM1MjQKIHI2 X3VzcjogYzA2MmM5MGMgICAgICAgIHI3X3VzcjogYzA4ZDliZjkgICAgICAgIHI4X3Vzcjog MDAwMDAwMDEKIHI5X3VzcjogMDAwMDAwMDAgICAgICAgcjEwX3VzcjogYzA4ZDliZjkgICAg ICAgcjExX3VzcjogYzA4ODVmNzQKcjEyX3VzcjogYzA4ODVmNjgKCiByOF9maXE6IDAwMDAw MDAwCiByOV9maXE6IDAwMDAwMDAwICAgICAgIHIxMF9maXE6IDAwMDAwMDAwICAgICAgIHIx MV9maXE6IDAwMDAwMDAwCnIxMl9maXE6IDAwMDAwMDAwCgpTQ1RMUjogMzBjNTM4N2QKVFRC Q1I6IDAwMDAwMDAwYjUwMjM1MDAKVFRCUjA6IDAwMDAwMDAwNDAwMDMwMDAKVFRCUjE6IDAw MDAwMDAwNDAwMDcwMDAKCg== --------------020403030701000905010909 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020403030701000905010909-- From xen-users-bounces@lists.xen.org Thu Jul 09 14:56:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 14:56:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDEt-0003Jz-RU; Thu, 09 Jul 2015 14:55:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDEs-0003J4-J4 for xen-users@lists.xen.org; Thu, 09 Jul 2015 14:55:50 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 98/E1-18733-57B8E955; Thu, 09 Jul 2015 14:55:49 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1436453746!24604969!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8408 invoked from network); 9 Jul 2015 14:55:48 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-11.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 14:55:48 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69Etixg003548; Thu, 9 Jul 2015 09:55:44 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69EtiQK029217; Thu, 9 Jul 2015 09:55:44 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 09:55:27 -0500 Message-ID: <559E7D63.3050804@ti.com> Date: Thu, 9 Jul 2015 09:55:47 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> In-Reply-To: <1436443588.23508.127.camel@citrix.com> Content-Type: multipart/mixed; boundary="------------020403030701000905010909" X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020403030701000905010909 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/09/2015 03:34 AM, Julien Grall wrote: > Hi Brandon, > > These rangesets list the interrupt and I/O memory assigned to the guest > (i.e passthrough). > > In the case of the timer interrupt (physical and virtual), they are > owned by Xen and Xen will emulated it for each guest. > > From the logs the LRs are empty (see VCPU_LR) and no interrupts are > currently pending. > > I would add some printk in function gic_handle_irq in Linux > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. > I added that printk statement, and I never see any physical or virtual timer interrupts being delivered to the guest. I believe the guest is using the virtual timer, because when I do a more full register dump with trace32, I see that CNTV_CVAL is programmed to a non-zero value, but CNTP_CVAL is 0. I also noticed the following line during the Dom0 guest boot: (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz Is this expected to be different from the expected interrupt ID's for ARM core timers (these numbers are all offset by +5)? Correct me if I'm wrong, but it seems like gic_handle_irq() is not the control path taken by the PPI timers. It looks like the functions "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) handle those interrupts. Also, based on the following lines in xen/arch/arm/irq.c: 224-226, it seems like that the guests cannot be delivered PPI's from the function "do_IRQ()": /* the irq cannot be a PPI, we only support delivery of SPIs to * guests */ vgic_vcpu_inject_spi(info->d, info->virq); Also, how do the functions in xen/arch/arm/vtimer.c fit into this picture? Would they be the ones responsible for delivering the vtimer interrupt to the guest? > Regards, > On 07/09/2015 08:06 AM, Ian Campbell wrote: > On Wed, 2015-07-08 at 10:36 -0400, Brandon Perez wrote: >> I've attached the full log from the domain dump below. But the >> interesting part of the log is: >> >> (XEN) Rangesets belonging to domain 1: >> (XEN) Interrupts { } >> (XEN) I/O Memory { } >> >> Perhaps I am interpreting this incorrectly, but it would seem that >> no interrupts belong to domain 1? > > As Julien says these only list actual physical interrupts so it's > expected unless you are doing passthrough. > > As well as what Julien suggests you could try running > "$prefix/lib/xen/bin/xenctx 0" to get full register state. I've attached the xenctx dump. > > You could also perhaps try disabling HCR_EL2.TWI and/or TWE (trap wait > for interrupts and events respectively). Ages ago we had some bugs in > these areas, those are thought to be long gone, but it's worth checking. > No luck with that, the guest still doesn't boot successfully. > AIUI you are running the same 3.14/android kernel in both dom0 and domU. > Do you have the option of running a newer mainline kernel on your > platform, to rule out either changes made in the Android branch or > issues in the 3.14 kernel which have been fixed since. > > Ian. > Yes, I'm using the 3.14 kernel for both dom0 and domU. Unfortunately, I need the 3.14 kernel, but if these problems persist, I may try to update to a newer mainline kernel. Brandon --------------020403030701000905010909 Content-Type: text/plain; charset="UTF-8"; name="xenctx_guest.dump" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xenctx_guest.dump" UEM6ICAgICAgIGMwMDFlYTY4CkNQU1I6ICAgICA2MDAwMDE5MwpVU1I6ICAgICAgICAgICAg ICAgU1A6MDAwMDAwMDAgTFI6MDAwMDAwMDAKU1ZDOiBTUFNSOjYwMDAwMTUzIFNQOmMwODg1 ZjY4IExSOmMwMDBmZGQ0CkZJUTogU1BTUjowMDAwMDAwMCBTUDowMDAwMDAwMCBMUjpjMmMy YzJjMgpJUlE6IFNQU1I6NjAwMDAxZDMgU1A6YzA4ZGE3YzAgTFI6YzA2MjQ1NDAKQUJUOiBT UFNSOjAwMDAwMDAwIFNQOmMwOGRhN2NjIExSOmMwOGRhN2NjClVORDogU1BTUjowMDAwMDAw MCBTUDpjMDhkYTdkOCBMUjpjMDhkYTdkOAoKIHIwX3VzcjogZmZmZmZmZWQgICAgICAgIHIx X3VzcjogMDc2NjIwMDAgICAgICAgIHIyX3VzcjogYzA4OGQ1NzgKIHIzX3VzcjogMDAwMDAw MDAgICAgICAgIHI0X3VzcjogYzA4ODQwMDAgICAgICAgIHI1X3VzcjogYzA4OGM1MjQKIHI2 X3VzcjogYzA2MmM5MGMgICAgICAgIHI3X3VzcjogYzA4ZDliZjkgICAgICAgIHI4X3Vzcjog MDAwMDAwMDEKIHI5X3VzcjogMDAwMDAwMDAgICAgICAgcjEwX3VzcjogYzA4ZDliZjkgICAg ICAgcjExX3VzcjogYzA4ODVmNzQKcjEyX3VzcjogYzA4ODVmNjgKCiByOF9maXE6IDAwMDAw MDAwCiByOV9maXE6IDAwMDAwMDAwICAgICAgIHIxMF9maXE6IDAwMDAwMDAwICAgICAgIHIx MV9maXE6IDAwMDAwMDAwCnIxMl9maXE6IDAwMDAwMDAwCgpTQ1RMUjogMzBjNTM4N2QKVFRC Q1I6IDAwMDAwMDAwYjUwMjM1MDAKVFRCUjA6IDAwMDAwMDAwNDAwMDMwMDAKVFRCUjE6IDAw MDAwMDAwNDAwMDcwMDAKCg== --------------020403030701000905010909 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020403030701000905010909-- From xen-users-bounces@lists.xen.org Thu Jul 09 15:31:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 15:31:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDli-0005pR-Kd; Thu, 09 Jul 2015 15:29:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDlg-0005pM-Kl for xen-users@lists.xen.org; Thu, 09 Jul 2015 15:29:44 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id D9/E8-03371-8639E955; Thu, 09 Jul 2015 15:29:44 +0000 X-Env-Sender: prvs=625981f15=julien.grall@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436455782!30714496!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2250 invoked from network); 9 Jul 2015 15:29:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 15:29:43 -0000 X-IronPort-AV: E=Sophos;i="5.15,440,1432598400"; d="scan'208";a="279552942" Message-ID: <559E9362.3000402@citrix.com> Date: Thu, 9 Jul 2015 17:29:38 +0200 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> In-Reply-To: <559E7D63.3050804@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 09/07/2015 15:55, Brandon Perez wrote: > On 07/09/2015 03:34 AM, Julien Grall wrote: > > These rangesets list the interrupt and I/O memory assigned to the guest > > (i.e passthrough). > > > > In the case of the timer interrupt (physical and virtual), they are > > owned by Xen and Xen will emulated it for each guest. > > > > From the logs the LRs are empty (see VCPU_LR) and no interrupts are > > currently pending. > > > > I would add some printk in function gic_handle_irq in Linux > > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which > > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. > > > > I added that printk statement, and I never see any physical or > virtual timer interrupts being delivered to the guest. I believe the > guest is using the virtual timer, because when I do a more full register > dump with trace32, I see that CNTV_CVAL is programmed to a non-zero > value, but CNTP_CVAL is 0. Do you receive other interrupts in the guest? > > I also noticed the following line during the Dom0 guest boot: > > (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz > > Is this expected to be different from the expected interrupt ID's > for ARM core timers (these numbers are all offset by +5)? The timer IRQs for DOM0 and the guest may be different. DOM0 will use the same as the hardware (i.e the one in your log), while guests have a their interrupt defined in the guest layout (see xen/include/public/arch-arm.h). > Correct me if I'm wrong, but it seems like gic_handle_irq() is not > the control path taken by the PPI timers. It looks like the functions > "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) > handle those interrupts. I think you are mixing two different things here: - gic_handle_irq is the Linux interrupt handler for GICv2 where every IRQ is coming (PPIs, SPIs...) - vtimer_interrupt and timer_interrupt are Xen handlers which will take of the timer IRQs of the hardware. When the hardware fire a virtual interrupt it will be: 1) Received by Xen via gic_interrupt 2) do_IRQ will dispatch the IRQ 3) virtual_interrupt will be called has it has been registered as callback for the virtual timer 4) The interrupt will be injected to the guest using the guest virtual interrupt number. I.e the LRs will be setup 5) The guest will receive the interrupt 6) gic_handle_irq will dispatch the interrupt > > Also, based on the following lines in xen/arch/arm/irq.c: 224-226, > it seems like that the guests cannot be delivered PPI's from the > function "do_IRQ()": > > /* the irq cannot be a PPI, we only support delivery of SPIs to > * guests */ > vgic_vcpu_inject_spi(info->d, info->virq); This call is only used for IRQ owned by the domain. In the case of the timer IRQs, they are owned by Xen and therefore not directly injected to the guest. > > Also, how do the functions in xen/arch/arm/vtimer.c fit into this > picture? Would they be the ones responsible for delivering the vtimer > interrupt to the guest? The file vtimer.c contains anything related to the guest timer: emulation of the physical timer and context/restore of both virtual and physical timer. The injection of the timer interrupts will be done in different place: - virtual: this is done in vtimer_interrupt (xen/arch/arm/timer.c) when the domain is running. If the domain is not running, we create a timer and may inject an interrupt if the timer has expired (see virt_timer_expired in xen/arch/arm/vtimer.c). - physical: the timer is completely emulated. The injection of the interrupt is done in phys_timer_expired (xen/arch/arm/vtimer.c). You can add printk in those place to check whether the interrupt is injected to the guest or not. It may give you an insight of whether the timer has been correctly setup by the guest or not. Note that you may want to only print when it's not domain 0 to avoid log pollution. > Yes, I'm using the 3.14 kernel for both dom0 and domU. > Unfortunately, I need the 3.14 kernel, but if these problems persist, I > may try to update to a newer mainline kernel. May I ask you to provide - the .config used to build the kernel - a link to the git repo containing the branch (I wasn't able to find it on your first mail) You also said you had local changes in both Linux and Xen. Can you tell us what kind of changes? Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 15:31:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 15:31:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDli-0005pR-Kd; Thu, 09 Jul 2015 15:29:46 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDDlg-0005pM-Kl for xen-users@lists.xen.org; Thu, 09 Jul 2015 15:29:44 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id D9/E8-03371-8639E955; Thu, 09 Jul 2015 15:29:44 +0000 X-Env-Sender: prvs=625981f15=julien.grall@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436455782!30714496!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2250 invoked from network); 9 Jul 2015 15:29:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 15:29:43 -0000 X-IronPort-AV: E=Sophos;i="5.15,440,1432598400"; d="scan'208";a="279552942" Message-ID: <559E9362.3000402@citrix.com> Date: Thu, 9 Jul 2015 17:29:38 +0200 From: Julien Grall User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Brandon Perez , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> In-Reply-To: <559E7D63.3050804@ti.com> X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, On 09/07/2015 15:55, Brandon Perez wrote: > On 07/09/2015 03:34 AM, Julien Grall wrote: > > These rangesets list the interrupt and I/O memory assigned to the guest > > (i.e passthrough). > > > > In the case of the timer interrupt (physical and virtual), they are > > owned by Xen and Xen will emulated it for each guest. > > > > From the logs the LRs are empty (see VCPU_LR) and no interrupts are > > currently pending. > > > > I would add some printk in function gic_handle_irq in Linux > > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which > > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. > > > > I added that printk statement, and I never see any physical or > virtual timer interrupts being delivered to the guest. I believe the > guest is using the virtual timer, because when I do a more full register > dump with trace32, I see that CNTV_CVAL is programmed to a non-zero > value, but CNTP_CVAL is 0. Do you receive other interrupts in the guest? > > I also noticed the following line during the Dom0 guest boot: > > (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz > > Is this expected to be different from the expected interrupt ID's > for ARM core timers (these numbers are all offset by +5)? The timer IRQs for DOM0 and the guest may be different. DOM0 will use the same as the hardware (i.e the one in your log), while guests have a their interrupt defined in the guest layout (see xen/include/public/arch-arm.h). > Correct me if I'm wrong, but it seems like gic_handle_irq() is not > the control path taken by the PPI timers. It looks like the functions > "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) > handle those interrupts. I think you are mixing two different things here: - gic_handle_irq is the Linux interrupt handler for GICv2 where every IRQ is coming (PPIs, SPIs...) - vtimer_interrupt and timer_interrupt are Xen handlers which will take of the timer IRQs of the hardware. When the hardware fire a virtual interrupt it will be: 1) Received by Xen via gic_interrupt 2) do_IRQ will dispatch the IRQ 3) virtual_interrupt will be called has it has been registered as callback for the virtual timer 4) The interrupt will be injected to the guest using the guest virtual interrupt number. I.e the LRs will be setup 5) The guest will receive the interrupt 6) gic_handle_irq will dispatch the interrupt > > Also, based on the following lines in xen/arch/arm/irq.c: 224-226, > it seems like that the guests cannot be delivered PPI's from the > function "do_IRQ()": > > /* the irq cannot be a PPI, we only support delivery of SPIs to > * guests */ > vgic_vcpu_inject_spi(info->d, info->virq); This call is only used for IRQ owned by the domain. In the case of the timer IRQs, they are owned by Xen and therefore not directly injected to the guest. > > Also, how do the functions in xen/arch/arm/vtimer.c fit into this > picture? Would they be the ones responsible for delivering the vtimer > interrupt to the guest? The file vtimer.c contains anything related to the guest timer: emulation of the physical timer and context/restore of both virtual and physical timer. The injection of the timer interrupts will be done in different place: - virtual: this is done in vtimer_interrupt (xen/arch/arm/timer.c) when the domain is running. If the domain is not running, we create a timer and may inject an interrupt if the timer has expired (see virt_timer_expired in xen/arch/arm/vtimer.c). - physical: the timer is completely emulated. The injection of the interrupt is done in phys_timer_expired (xen/arch/arm/vtimer.c). You can add printk in those place to check whether the interrupt is injected to the guest or not. It may give you an insight of whether the timer has been correctly setup by the guest or not. Note that you may want to only print when it's not domain 0 to avoid log pollution. > Yes, I'm using the 3.14 kernel for both dom0 and domU. > Unfortunately, I need the 3.14 kernel, but if these problems persist, I > may try to update to a newer mainline kernel. May I ask you to provide - the .config used to build the kernel - a link to the git repo containing the branch (I wasn't able to find it on your first mail) You also said you had local changes in both Linux and Xen. Can you tell us what kind of changes? Regards, -- Julien Grall _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 16:19:03 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 16:19:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDEWU-00026A-0p; Thu, 09 Jul 2015 16:18:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDEWS-00025f-MC for xen-users@lists.xen.org; Thu, 09 Jul 2015 16:18:05 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 1B/9A-18676-CBE9E955; Thu, 09 Jul 2015 16:18:04 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1436458680!30671527!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22005 invoked from network); 9 Jul 2015 16:18:01 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 16:18:01 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69GHvhF015650; Thu, 9 Jul 2015 11:17:57 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69GHuRa019505; Thu, 9 Jul 2015 11:17:57 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 11:17:39 -0500 Message-ID: <559E90A7.7010809@ti.com> Date: Thu, 9 Jul 2015 11:17:59 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> In-Reply-To: <559E9362.3000402@citrix.com> Content-Type: multipart/mixed; boundary="------------020909000202020305090300" X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020909000202020305090300 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/09/2015 11:29 AM, Julien Grall wrote: > Hi, > > On 09/07/2015 15:55, Brandon Perez wrote: >> On 07/09/2015 03:34 AM, Julien Grall wrote: >> > These rangesets list the interrupt and I/O memory assigned to the >> guest >> > (i.e passthrough). >> > >> > In the case of the timer interrupt (physical and virtual), they are >> > owned by Xen and Xen will emulated it for each guest. >> > >> > From the logs the LRs are empty (see VCPU_LR) and no interrupts are >> > currently pending. >> > >> > I would add some printk in function gic_handle_irq in Linux >> > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which >> > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. >> > >> >> I added that printk statement, and I never see any physical or >> virtual timer interrupts being delivered to the guest. I believe the >> guest is using the virtual timer, because when I do a more full register >> dump with trace32, I see that CNTV_CVAL is programmed to a non-zero >> value, but CNTP_CVAL is 0. > > Do you receive other interrupts in the guest? > >> >> I also noticed the following line during the Dom0 guest boot: >> >> (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz >> >> Is this expected to be different from the expected interrupt ID's >> for ARM core timers (these numbers are all offset by +5)? > > The timer IRQs for DOM0 and the guest may be different. DOM0 will use > the same as the hardware (i.e the one in your log), while guests have a > their interrupt defined in the guest layout (see > xen/include/public/arch-arm.h). > >> Correct me if I'm wrong, but it seems like gic_handle_irq() is not >> the control path taken by the PPI timers. It looks like the functions >> "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) >> handle those interrupts. > > I think you are mixing two different things here: > - gic_handle_irq is the Linux interrupt handler for GICv2 where > every IRQ is coming (PPIs, SPIs...) > - vtimer_interrupt and timer_interrupt are Xen handlers which > will take of the timer IRQs of the hardware. > > When the hardware fire a virtual interrupt it will be: > 1) Received by Xen via gic_interrupt > 2) do_IRQ will dispatch the IRQ > 3) virtual_interrupt will be called has it has been registered as > callback for the virtual timer > 4) The interrupt will be injected to the guest using the guest > virtual interrupt number. I.e the LRs will be setup > 5) The guest will receive the interrupt > 6) gic_handle_irq will dispatch the interrupt > >> >> Also, based on the following lines in xen/arch/arm/irq.c: 224-226, >> it seems like that the guests cannot be delivered PPI's from the >> function "do_IRQ()": >> >> /* the irq cannot be a PPI, we only support delivery of SPIs to >> * guests */ >> vgic_vcpu_inject_spi(info->d, info->virq); > > This call is only used for IRQ owned by the domain. > > In the case of the timer IRQs, they are owned by Xen and therefore not > directly injected to the guest. > >> >> Also, how do the functions in xen/arch/arm/vtimer.c fit into this >> picture? Would they be the ones responsible for delivering the vtimer >> interrupt to the guest? > > The file vtimer.c contains anything related to the guest timer: > emulation of the physical timer and context/restore of both virtual and > physical timer. > > The injection of the timer interrupts will be done in different place: > - virtual: this is done in vtimer_interrupt (xen/arch/arm/timer.c) > when the domain is running. If the domain is not running, we create a > timer and may inject an interrupt if the timer has expired (see > virt_timer_expired in xen/arch/arm/vtimer.c). > - physical: the timer is completely emulated. The injection of the > interrupt is done in phys_timer_expired (xen/arch/arm/vtimer.c). > > You can add printk in those place to check whether the interrupt is > injected to the guest or not. It may give you an insight of whether the > timer has been correctly setup by the guest or not. > > Note that you may want to only print when it's not domain 0 to avoid log > pollution. > >> Yes, I'm using the 3.14 kernel for both dom0 and domU. >> Unfortunately, I need the 3.14 kernel, but if these problems persist, I >> may try to update to a newer mainline kernel. > > May I ask you to provide > - the .config used to build the kernel > - a link to the git repo containing the branch (I wasn't able to > find it on your first mail) > > You also said you had local changes in both Linux and Xen. Can you tell > us what kind of changes? > > Regards, > Hi Julien, Thanks, for the clarifications on my questions on interrupt/timer code flow in Xen. That made it a lot clearer. I figured out what is causing the bug, and it turned out to be one of the local changes I had to Xen. On the DRA72x device, there are a large number of peripheral devices, more than can be handled by the SPI on the GIC. Therefore, there's an internal mechanism that allows the routing of these peripherals to the interrupt lines on the GIC. Unfortunately, this means that the "interrupt" property of devices in the device tree do not contain the interrupt ID of the device, but rather contain the index (ID) of the peripheral on the board. In the Linux kernel, the peripherals are mapped to SPI IRQ lines as they are needed. So, given the same device tree and configuration settings, the mapping will always be the same, but this cannot be easily inferred from the device tree. The mapping is not static, but once the interrupts are assigned, they do not change. Naturally, Xen is unaware of this interrupt ID remapping, so it maps interrupts prematurely, or assertions fail, as the "interrupt ID" found in the device tree is larger than the total number of GIC lines. To work-around this, I made the mapping of peripherals fully static, so Xen would accept the default configuration given to it by the bootloader, and the Linux kernel would not to attempt to create a new mapping from the devices in the device tree. The change I made essentially involved adding an extra layer of translation to "gic_irq_xlate()", where if the platform has defined irq remap function, then it performs this remapping. This lead to an issue because I assumed that all devices in the device tree were peripheral devices, tied to SPIs (thus requiring translation). PPIs, naturally, are independent of this peripheral remapping, since they are on the physical processor. Thus, there was a timer node in the device tree, and I was incorrectly translating these interrupt numbers, treating the like SPIs, instead of PPIs. So, I just had to make the simple change of performing the extra layer of translation only if it was an SPI. Then, since none of the timer interrupt functions were properly mapped to the correct IRQ lines, the timer interrupts were not handled properly, which showed up in my guest kernel boot as the Guest getting stuck in a hrtimer sleep forever, since no virtual timer interrupts were ever received. For the sake of completeness, I've attached my .config file for the kernel. It's a standard kernel configuration, with some extra parameters for Xen as outlined in [1]. The git repo is at git://git.omapzoom.org/kernel/omap.git, and the branch is "android-3.14-6AL.1.0". [1] http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM Brandon --------------020909000202020305090300 Content-Type: text/plain; charset="UTF-8"; name=".config" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=".config" IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4 L2FybSAzLjE0LjMxIEtlcm5lbCBDb25maWd1cmF0aW9uCiMKQ09ORklHX0FSTT15CkNPTkZJ R19NSUdIVF9IQVZFX1BDST15CkNPTkZJR19TWVNfU1VQUE9SVFNfQVBNX0VNVUxBVElPTj15 CkNPTkZJR19IQVZFX1BST0NfQ1BVPXkKQ09ORklHX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNP TkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfVFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15 CkNPTkZJR19SV1NFTV9HRU5FUklDX1NQSU5MT0NLPXkKQ09ORklHX0FSQ0hfSEFTX0NQVUZS RVE9eQpDT05GSUdfQVJDSF9IQVNfQkFOREdBUD15CkNPTkZJR19HRU5FUklDX0hXRUlHSFQ9 eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfTkVFRF9ETUFfTUFQ X1NUQVRFPXkKQ09ORklHX1ZFQ1RPUlNfQkFTRT0weGZmZmYwMDAwCkNPTkZJR19BUk1fUEFU Q0hfUEhZU19WSVJUPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0RFRkNPTkZJR19M SVNUPSIvbGliL21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0lSUV9X T1JLPXkKQ09ORklHX0JVSUxEVElNRV9FWFRBQkxFX1NPUlQ9eQoKIwojIEdlbmVyYWwgc2V0 dXAKIwpDT05GSUdfSU5JVF9FTlZfQVJHX0xJTUlUPTMyCkNPTkZJR19DUk9TU19DT01QSUxF PSIiCiMgQ09ORklHX0NPTVBJTEVfVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19MT0NBTFZFUlNJ T049IiIKQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPPXkKQ09ORklHX0hBVkVfS0VSTkVMX0da SVA9eQpDT05GSUdfSEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15 CkNPTkZJR19IQVZFX0tFUk5FTF9MWk89eQpDT05GSUdfSEFWRV9LRVJORUxfTFo0PXkKQ09O RklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENP TkZJR19LRVJORUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBz ZXQKIyBDT05GSUdfS0VSTkVMX0xaNCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1RO QU1FPSIobm9uZSkiCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lT VklQQ19TWVNDVEw9eQpDT05GSUdfUE9TSVhfTVFVRVVFPXkKQ09ORklHX1BPU0lYX01RVUVV RV9TWVNDVEw9eQojIENPTkZJR19GSEFORExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQVVESVQg aXMgbm90IHNldAoKIwojIElSUSBzdWJzeXN0ZW0KIwpDT05GSUdfR0VORVJJQ19JUlFfUFJP QkU9eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19IQVJESVJRU19TV19SRVNF TkQ9eQpDT05GSUdfR0VORVJJQ19JUlFfQ0hJUD15CkNPTkZJR19JUlFfRE9NQUlOPXkKIyBD T05GSUdfSVJRX0RPTUFJTl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19JUlFfRk9SQ0VEX1RI UkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKQ09ORklHX0tUSU1FX1NDQUxBUj15CkNP TkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNf QlVJTEQ9eQpDT05GSUdfQVJDSF9IQVNfVElDS19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJ Q19DTE9DS0VWRU5UU19CUk9BRENBU1Q9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpDT05G SUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haX0NPTU1PTj15CiMgQ09ORklHX0haX1BF UklPRElDIGlzIG5vdCBzZXQKQ09ORklHX05PX0haX0lETEU9eQojIENPTkZJR19OT19IWl9G VUxMIGlzIG5vdCBzZXQKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15 CgojCiMgQ1BVL1Rhc2sgdGltZSBhbmQgc3RhdHMgYWNjb3VudGluZwojCkNPTkZJR19USUNL X0NQVV9BQ0NPVU5USU5HPXkKIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4gaXMg bm90IHNldAojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5USU5HIGlzIG5vdCBzZXQKQ09ORklH X0JTRF9QUk9DRVNTX0FDQ1Q9eQojIENPTkZJR19CU0RfUFJPQ0VTU19BQ0NUX1YzIGlzIG5v dCBzZXQKIyBDT05GSUdfVEFTS1NUQVRTIGlzIG5vdCBzZXQKCiMKIyBSQ1UgU3Vic3lzdGVt CiMKQ09ORklHX1RSRUVfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9SQ1U9eQpDT05G SUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlzIG5vdCBzZXQK Q09ORklHX1JDVV9GQU5PVVQ9MzIKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0xNgojIENPTkZJ R19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFog aXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklH X1JDVV9CT09TVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9OT0NCX0NQVSBpcyBub3Qgc2V0 CkNPTkZJR19JS0NPTkZJRz15CkNPTkZJR19JS0NPTkZJR19QUk9DPXkKQ09ORklHX0xPR19C VUZfU0hJRlQ9MTYKQ09ORklHX0dFTkVSSUNfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQ Uz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0NHUk9VUF9G UkVFWkVSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQX0RFVklDRSBpcyBub3Qgc2V0CiMg Q09ORklHX0NQVVNFVFMgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfQ1BVQUNDVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFU09VUkNFX0NPVU5URVJTIGlzIG5vdCBzZXQKIyBDT05GSUdf Q0dST1VQX1BFUkYgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfU0NIRUQgaXMgbm90IHNl dAojIENPTkZJR19CTEtfQ0dST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hFQ0tQT0lOVF9S RVNUT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFNRVNQQUNFUyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDSEVEX0FVVE9HUk9VUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU0ZTX0RFUFJFQ0FU RUQgaXMgbm90IHNldAojIENPTkZJR19SRUxBWSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVW X0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09VUkNFPSIiCkNPTkZJR19SRF9HWklQPXkK IyBDT05GSUdfUkRfQlpJUDIgaXMgbm90IHNldAojIENPTkZJR19SRF9MWk1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfUkRfWFogaXMgbm90IHNldAojIENPTkZJR19SRF9MWk8gaXMgbm90IHNl dAojIENPTkZJR19SRF9MWjQgaXMgbm90IHNldAojIENPTkZJR19DQ19PUFRJTUlaRV9GT1Jf U0laRSBpcyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpDT05GSUdfQU5PTl9JTk9ERVM9eQpD T05GSUdfSEFWRV9VSUQxNj15CkNPTkZJR19FWFBFUlQ9eQpDT05GSUdfVUlEMTY9eQojIENP TkZJR19TWVNDVExfU1lTQ0FMTCBpcyBub3Qgc2V0CkNPTkZJR19LQUxMU1lNUz15CiMgQ09O RklHX0tBTExTWU1TX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19QUklOVEs9eQpDT05GSUdfQlVH PXkKQ09ORklHX0VMRl9DT1JFPXkKQ09ORklHX0JBU0VfRlVMTD15CkNPTkZJR19GVVRFWD15 CkNPTkZJR19FUE9MTD15CkNPTkZJR19TSUdOQUxGRD15CkNPTkZJR19USU1FUkZEPXkKQ09O RklHX0VWRU5URkQ9eQpDT05GSUdfU0hNRU09eQpDT05GSUdfQUlPPXkKQ09ORklHX1BDSV9R VUlSS1M9eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZf RVZFTlRTPXkKQ09ORklHX1BFUkZfVVNFX1ZNQUxMT0M9eQoKIwojIEtlcm5lbCBQZXJmb3Jt YW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBDT05G SUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9D T1VOVEVSUz15CkNPTkZJR19DT01QQVRfQlJLPXkKQ09ORklHX1NMQUI9eQojIENPTkZJR19T TFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xPQiBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU1RF TV9UUlVTVEVEX0tFWVJJTkcgaXMgbm90IHNldApDT05GSUdfUFJPRklMSU5HPXkKQ09ORklH X09QUk9GSUxFPXkKQ09ORklHX0hBVkVfT1BST0ZJTEU9eQpDT05GSUdfS1BST0JFUz15CkNP TkZJR19KVU1QX0xBQkVMPXkKIyBDT05GSUdfSEFWRV82NEJJVF9BTElHTkVEX0FDQ0VTUyBp cyBub3Qgc2V0CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09O RklHX0FSQ0hfVVNFX0JVSUxUSU5fQlNXQVA9eQpDT05GSUdfS1JFVFBST0JFUz15CkNPTkZJ R19IQVZFX0tQUk9CRVM9eQpDT05GSUdfSEFWRV9LUkVUUFJPQkVTPXkKQ09ORklHX0hBVkVf QVJDSF9UUkFDRUhPT0s9eQpDT05GSUdfSEFWRV9ETUFfQVRUUlM9eQpDT05GSUdfSEFWRV9E TUFfQ09OVElHVU9VUz15CkNPTkZJR19HRU5FUklDX1NNUF9JRExFX1RIUkVBRD15CkNPTkZJ R19HRU5FUklDX0lETEVfUE9MTF9TRVRVUD15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNL X0FDQ0VTU19BUEk9eQpDT05GSUdfSEFWRV9DTEs9eQpDT05GSUdfSEFWRV9ETUFfQVBJX0RF QlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJR19IQVZFX1BFUkZfUkVH Uz15CkNPTkZJR19IQVZFX1BFUkZfVVNFUl9TVEFDS19EVU1QPXkKQ09ORklHX0hBVkVfQVJD SF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfV0FOVF9JUENfUEFSU0VfVkVSU0lPTj15CkNP TkZJR19IQVZFX0FSQ0hfU0VDQ09NUF9GSUxURVI9eQpDT05GSUdfSEFWRV9DQ19TVEFDS1BS T1RFQ1RPUj15CiMgQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9SIGlzIG5vdCBzZXQKQ09ORklH X0NDX1NUQUNLUFJPVEVDVE9SX05PTkU9eQojIENPTkZJR19DQ19TVEFDS1BST1RFQ1RPUl9S RUdVTEFSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0NfU1RBQ0tQUk9URUNUT1JfU1RST05HIGlz IG5vdCBzZXQKQ09ORklHX0hBVkVfQ09OVEVYVF9UUkFDS0lORz15CkNPTkZJR19IQVZFX1ZJ UlRfQ1BVX0FDQ09VTlRJTkdfR0VOPXkKQ09ORklHX0hBVkVfSVJRX1RJTUVfQUNDT1VOVElO Rz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfTU9E VUxFU19VU0VfRUxGX1JFTD15CkNPTkZJR19DTE9ORV9CQUNLV0FSRFM9eQpDT05GSUdfT0xE X1NJR1NVU1BFTkQzPXkKQ09ORklHX09MRF9TSUdBQ1RJT049eQoKIwojIEdDT1YtYmFzZWQg a2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklHX0dDT1ZfS0VSTkVMIGlzIG5vdCBzZXQKQ09O RklHX0hBVkVfR0VORVJJQ19ETUFfQ09IRVJFTlQ9eQpDT05GSUdfU0xBQklORk89eQpDT05G SUdfUlRfTVVURVhFUz15CkNPTkZJR19CQVNFX1NNQUxMPTAKQ09ORklHX01PRFVMRVM9eQpD T05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQ9eQpDT05GSUdfTU9EVUxFX1VOTE9BRD15CkNPTkZJ R19NT0RVTEVfRk9SQ0VfVU5MT0FEPXkKQ09ORklHX01PRFZFUlNJT05TPXkKQ09ORklHX01P RFVMRV9TUkNWRVJTSU9OX0FMTD15CiMgQ09ORklHX01PRFVMRV9TSUcgaXMgbm90IHNldApD T05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklHX0JMT0NLPXkKQ09ORklHX0xCREFGPXkKIyBD T05GSUdfQkxLX0RFVl9CU0cgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0JTR0xJQiBp cyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05G SUdfQkxLX0NNRExJTkVfUEFSU0VSIGlzIG5vdCBzZXQKCiMKIyBQYXJ0aXRpb24gVHlwZXMK IwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9O IGlzIG5vdCBzZXQKIyBDT05GSUdfQUlYX1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklH X09TRl9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19BTUlHQV9QQVJUSVRJT04gaXMg bm90IHNldAojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19N QUNfUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX01TRE9TX1BBUlRJVElPTj15CiMgQ09O RklHX0JTRF9ESVNLTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19NSU5JWF9TVUJQQVJUSVRJ T04gaXMgbm90IHNldAojIENPTkZJR19TT0xBUklTX1g4Nl9QQVJUSVRJT04gaXMgbm90IHNl dAojIENPTkZJR19VTklYV0FSRV9ESVNLTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19MRE1f UEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0dJX1BBUlRJVElPTiBpcyBub3Qgc2V0 CiMgQ09ORklHX1VMVFJJWF9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19TVU5fUEFS VElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfS0FSTUFfUEFSVElUSU9OIGlzIG5vdCBzZXQK Q09ORklHX0VGSV9QQVJUSVRJT049eQojIENPTkZJR19TWVNWNjhfUEFSVElUSU9OIGlzIG5v dCBzZXQKIyBDT05GSUdfQ01ETElORV9QQVJUSVRJT04gaXMgbm90IHNldAoKIwojIElPIFNj aGVkdWxlcnMKIwpDT05GSUdfSU9TQ0hFRF9OT09QPXkKQ09ORklHX0lPU0NIRURfREVBRExJ TkU9eQpDT05GSUdfSU9TQ0hFRF9DRlE9eQojIENPTkZJR19ERUZBVUxUX0RFQURMSU5FIGlz IG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfQ0ZRPXkKIyBDT05GSUdfREVGQVVMVF9OT09QIGlz IG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfSU9TQ0hFRD0iY2ZxIgpDT05GSUdfVU5JTkxJTkVf U1BJTl9VTkxPQ0s9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19BVE9NSUNfUk1XPXkKQ09ORklH X01VVEVYX1NQSU5fT05fT1dORVI9eQpDT05GSUdfRlJFRVpFUj15CgojCiMgU3lzdGVtIFR5 cGUKIwpDT05GSUdfTU1VPXkKQ09ORklHX0FSQ0hfTVVMVElQTEFURk9STT15CiMgQ09ORklH X0FSQ0hfSU5URUdSQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfUkVBTFZJRVcgaXMg bm90IHNldAojIENPTkZJR19BUkNIX1ZFUlNBVElMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfQVQ5MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfQ0xQUzcxMVggaXMgbm90IHNldAoj IENPTkZJR19BUkNIX0dFTUlOSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfRUJTQTExMCBp cyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfRVA5M1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJD SF9GT09UQlJJREdFIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ORVRYIGlzIG5vdCBzZXQK IyBDT05GSUdfQVJDSF9JT1AxM1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9JT1AzMlgg aXMgbm90IHNldAojIENPTkZJR19BUkNIX0lPUDMzWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfSVhQNFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ET1ZFIGlzIG5vdCBzZXQKIyBD T05GSUdfQVJDSF9LSVJLV09PRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVY3OFhYMCBp cyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfT1JJT041WCBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfTU1QIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9LUzg2OTUgaXMgbm90IHNldAojIENP TkZJR19BUkNIX1c5MFg5MDAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX0xQQzMyWFggaXMg bm90IHNldAojIENPTkZJR19BUkNIX1BYQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVNN X05PRFQgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NITU9CSUxFX0xFR0FDWSBpcyBub3Qg c2V0CiMgQ09ORklHX0FSQ0hfUlBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9TQTExMDAg aXMgbm90IHNldAojIENPTkZJR19BUkNIX1MzQzI0WFggaXMgbm90IHNldAojIENPTkZJR19B UkNIX1MzQzY0WFggaXMgbm90IHNldAojIENPTkZJR19BUkNIX1M1UDY0WDAgaXMgbm90IHNl dAojIENPTkZJR19BUkNIX1M1UEMxMDAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1M1UFYy MTAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX0VYWU5PUyBpcyBub3Qgc2V0CiMgQ09ORklH X0FSQ0hfREFWSU5DSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfT01BUDEgaXMgbm90IHNl dAoKIwojIE11bHRpcGxlIHBsYXRmb3JtIHNlbGVjdGlvbgojCgojCiMgQ1BVIENvcmUgZmFt aWx5IHNlbGVjdGlvbgojCiMgQ09ORklHX0FSQ0hfTVVMVElfVjYgaXMgbm90IHNldApDT05G SUdfQVJDSF9NVUxUSV9WNz15CkNPTkZJR19BUkNIX01VTFRJX1Y2X1Y3PXkKIyBDT05GSUdf QVJDSF9NVUxUSV9DUFVfQVVUTyBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVZFQlUgaXMg bm90IHNldAojIENPTkZJR19BUkNIX0JDTSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfQkVS TElOIGlzIG5vdCBzZXQKQ09ORklHX0dQSU9fUENBOTUzWD15CiMgQ09ORklHX0tFWUJPQVJE X0dQSU9fUE9MTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ISUdIQkFOSyBpcyBub3Qg c2V0CiMgQ09ORklHX0FSQ0hfSEkzeHh4IGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9LRVlT VE9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVNNX0RUIGlzIG5vdCBzZXQKIyBDT05G SUdfQVJDSF9NWEMgaXMgbm90IHNldAoKIwojIFRJIE9NQVAgQ29tbW9uIEZlYXR1cmVzCiMK CiMKIyBPTUFQIEZlYXR1cmUgU2VsZWN0aW9ucwojCkNPTkZJR19PTUFQX1JFU0VUX0NMT0NL Uz15CkNPTkZJR19PTUFQX01VWD15CkNPTkZJR19PTUFQX01VWF9ERUJVRz15CkNPTkZJR19P TUFQX01VWF9XQVJOSU5HUz15CkNPTkZJR19PTUFQXzMyS19USU1FUj15CkNPTkZJR19PTUFQ X0RNX1RJTUVSPXkKQ09ORklHX09NQVBfUE1fTk9PUD15CkNPTkZJR19NQUNIX09NQVBfR0VO RVJJQz15CkNPTkZJR19BUkNIX09NQVA9eQojIENPTkZJR19BUkNIX09NQVAzIGlzIG5vdCBz ZXQKIyBDT05GSUdfQVJDSF9PTUFQNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NPQ19PTUFQNSBp cyBub3Qgc2V0CiMgQ09ORklHX1NPQ19BTTMzWFggaXMgbm90IHNldAojIENPTkZJR19TT0Nf QU00M1hYIGlzIG5vdCBzZXQKQ09ORklHX1NPQ19EUkE3WFg9eQpDT05GSUdfQVJDSF9PTUFQ MlBMVVM9eQoKIwojIFRJIE9NQVAyLzMvNCBTcGVjaWZpYyBGZWF0dXJlcwojCkNPTkZJR19B UkNIX09NQVAyUExVU19UWVBJQ0FMPXkKIyBDT05GSUdfU09DX0hBU19PTUFQMl9TRFJDIGlz IG5vdCBzZXQKQ09ORklHX1NPQ19IQVNfUkVBTFRJTUVfQ09VTlRFUj15CgojCiMgT01BUCBM ZWdhY3kgUGxhdGZvcm0gRGF0YSBCb2FyZCBUeXBlCiMKIyBDT05GSUdfQVJDSF9ST0NLQ0hJ UCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU09DRlBHQSBpcyBub3Qgc2V0CiMgQ09ORklH X1BMQVRfU1BFQVIgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NUSSBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfU0hNT0JJTEVfTVVMVEkgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NV TlhJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9TSVJGIGlzIG5vdCBzZXQKIyBDT05GSUdf QVJDSF9URUdSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfVTg1MDAgaXMgbm90IHNldAoj IENPTkZJR19BUkNIX1ZFWFBSRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9WSVJUIGlz IG5vdCBzZXQKIyBDT05GSUdfQVJDSF9XTTg4NTAgaXMgbm90IHNldAojIENPTkZJR19BUkNI X1pZTlEgaXMgbm90IHNldAoKIwojIFByb2Nlc3NvciBUeXBlCiMKQ09ORklHX0NQVV9WNz15 CkNPTkZJR19DUFVfMzJ2Nks9eQpDT05GSUdfQ1BVXzMydjc9eQpDT05GSUdfQ1BVX0FCUlRf RVY3PXkKQ09ORklHX0NQVV9QQUJSVF9WNz15CkNPTkZJR19DUFVfQ0FDSEVfVjc9eQpDT05G SUdfQ1BVX0NBQ0hFX1ZJUFQ9eQpDT05GSUdfQ1BVX0NPUFlfVjY9eQpDT05GSUdfQ1BVX1RM Ql9WNz15CkNPTkZJR19DUFVfSEFTX0FTSUQ9eQpDT05GSUdfQ1BVX0NQMTU9eQpDT05GSUdf Q1BVX0NQMTVfTU1VPXkKCiMKIyBQcm9jZXNzb3IgRmVhdHVyZXMKIwpDT05GSUdfQVJNX0xQ QUU9eQpDT05GSUdfQVJDSF9QSFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19BUkNIX0RNQV9B RERSX1RfNjRCSVQ9eQpDT05GSUdfQVJNX1RIVU1CPXkKQ09ORklHX0FSTV9USFVNQkVFPXkK Q09ORklHX0FSTV9WSVJUX0VYVD15CkNPTkZJR19TV1BfRU1VTEFURT15CiMgQ09ORklHX0NQ VV9JQ0FDSEVfRElTQUJMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9EQ0FDSEVfRElTQUJM RSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9CUFJFRElDVF9ESVNBQkxFIGlzIG5vdCBzZXQK Q09ORklHX0tVU0VSX0hFTFBFUlM9eQojIENPTkZJR19DQUNIRV9MMlgwIGlzIG5vdCBzZXQK Q09ORklHX0FSTV9MMV9DQUNIRV9TSElGVF82PXkKQ09ORklHX0FSTV9MMV9DQUNIRV9TSElG VD02CkNPTkZJR19BUk1fRE1BX01FTV9CVUZGRVJBQkxFPXkKQ09ORklHX0FSTV9OUl9CQU5L Uz04CkNPTkZJR19NVUxUSV9JUlFfSEFORExFUj15CiMgQ09ORklHX0FSTV9FUlJBVEFfNDMw OTczIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV82NDM3MTkgaXMgbm90IHNldAoj IENPTkZJR19BUk1fRVJSQVRBXzcyMDc4OSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSTV9FUlJB VEFfNzU0MzIyIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV83NTQzMjcgaXMgbm90 IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzc2NDM2OSBpcyBub3Qgc2V0CiMgQ09ORklHX0FS TV9FUlJBVEFfNzc1NDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV83OTgxODEg aXMgbm90IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzc3MzAyMiBpcyBub3Qgc2V0CkNPTkZJ R19USV9QUklWX0VETUE9eQoKIwojIEJ1cyBzdXBwb3J0CiMKQ09ORklHX1BDST15CkNPTkZJ R19QQ0lfU1lTQ0FMTD15CiMgQ09ORklHX1BDSV9NU0kgaXMgbm90IHNldAojIENPTkZJR19Q Q0lfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTyBp cyBub3Qgc2V0CiMgQ09ORklHX1BDSV9TVFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfUENJX0lP ViBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSV9QUkkgaXMgbm90IHNldAojIENPTkZJR19QQ0lf UEFTSUQgaXMgbm90IHNldAoKIwojIFBDSSBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCkNP TkZJR19QQ0lfRFJBN1hYPXkKQ09ORklHX1BDSUVfRFc9eQojIENPTkZJR19QQ0lFUE9SVEJV UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0CgojCiMgS2VybmVsIEZl YXR1cmVzCiMKQ09ORklHX0hBVkVfU01QPXkKQ09ORklHX1NNUD15CkNPTkZJR19TTVBfT05f VVA9eQpDT05GSUdfQVJNX0NQVV9UT1BPTE9HWT15CiMgQ09ORklHX1NDSEVEX01DIGlzIG5v dCBzZXQKIyBDT05GSUdfU0NIRURfU01UIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJNX0FS Q0hfVElNRVI9eQojIENPTkZJR19NQ1BNIGlzIG5vdCBzZXQKIyBDT05GSUdfQklHX0xJVFRM RSBpcyBub3Qgc2V0CkNPTkZJR19WTVNQTElUXzNHPXkKIyBDT05GSUdfVk1TUExJVF8yRyBp cyBub3Qgc2V0CiMgQ09ORklHX1ZNU1BMSVRfMUcgaXMgbm90IHNldApDT05GSUdfUEFHRV9P RkZTRVQ9MHhDMDAwMDAwMApDT05GSUdfTlJfQ1BVUz0yCkNPTkZJR19IT1RQTFVHX0NQVT15 CkNPTkZJR19BUk1fUFNDST15CkNPTkZJR19BUkNIX05SX0dQSU89NTEyCiMgQ09ORklHX1BS RUVNUFRfTk9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIGlzIG5v dCBzZXQKQ09ORklHX1BSRUVNUFQ9eQpDT05GSUdfUFJFRU1QVF9DT1VOVD15CkNPTkZJR19I Wl9GSVhFRD0wCkNPTkZJR19IWl8xMDA9eQojIENPTkZJR19IWl8yMDAgaXMgbm90IHNldAoj IENPTkZJR19IWl8yNTAgaXMgbm90IHNldAojIENPTkZJR19IWl8zMDAgaXMgbm90IHNldAoj IENPTkZJR19IWl81MDAgaXMgbm90IHNldAojIENPTkZJR19IWl8xMDAwIGlzIG5vdCBzZXQK Q09ORklHX0haPTEwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKIyBDT05GSUdfVEhVTUIyX0tF Uk5FTCBpcyBub3Qgc2V0CkNPTkZJR19BRUFCST15CiMgQ09ORklHX09BQklfQ09NUEFUIGlz IG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX0hPTEVTX01FTU9SWU1PREVMPXkKIyBDT05GSUdf QVJDSF9TUEFSU0VNRU1fREVGQVVMVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU0VMRUNU X01FTU9SWV9NT0RFTCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfUEZOX1ZBTElEPXkK Q09ORklHX0hJR0hNRU09eQojIENPTkZJR19ISUdIUFRFIGlzIG5vdCBzZXQKQ09ORklHX0hX X1BFUkZfRVZFTlRTPXkKQ09ORklHX1NZU19TVVBQT1JUU19IVUdFVExCRlM9eQpDT05GSUdf QVJDSF9XQU5UX0dFTkVSQUxfSFVHRVRMQj15CkNPTkZJR19GTEFUTUVNPXkKQ09ORklHX0ZM QVRfTk9ERV9NRU1fTUFQPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0s9eQpDT05GSUdfTk9fQk9P VE1FTT15CkNPTkZJR19NRU1PUllfSVNPTEFUSU9OPXkKIyBDT05GSUdfSEFWRV9CT09UTUVN X0lORk9fTk9ERSBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxBR1NfRVhURU5ERUQ9eQpDT05G SUdfU1BMSVRfUFRMT0NLX0NQVVM9NApDT05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdS QVRJT049eQpDT05GSUdfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxB Rz0wCkNPTkZJR19CT1VOQ0U9eQpDT05GSUdfTU1VX05PVElGSUVSPXkKIyBDT05GSUdfS1NN IGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfTU1BUF9NSU5fQUREUj00MDk2CiMgQ09ORklH X1RSQU5TUEFSRU5UX0hVR0VQQUdFIGlzIG5vdCBzZXQKQ09ORklHX0NST1NTX01FTU9SWV9B VFRBQ0g9eQojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlJPTlRT V0FQIGlzIG5vdCBzZXQKQ09ORklHX0NNQT15CiMgQ09ORklHX0NNQV9ERUJVRyBpcyBub3Qg c2V0CiMgQ09ORklHX1pCVUQgaXMgbm90IHNldAojIENPTkZJR19aU01BTExPQyBpcyBub3Qg c2V0CkNPTkZJR19GT1JDRV9NQVhfWk9ORU9SREVSPTExCkNPTkZJR19BTElHTk1FTlRfVFJB UD15CiMgQ09ORklHX1VBQ0NFU1NfV0lUSF9NRU1DUFkgaXMgbm90IHNldAojIENPTkZJR19T RUNDT01QIGlzIG5vdCBzZXQKQ09ORklHX1NXSU9UTEI9eQpDT05GSUdfSU9NTVVfSEVMUEVS PXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hFTj15CiMgQ09ORklHX0FSTV9GTFVTSF9D T05TT0xFX09OX1JFU1RBUlQgaXMgbm90IHNldAoKIwojIEJvb3Qgb3B0aW9ucwojCkNPTkZJ R19VU0VfT0Y9eQpDT05GSUdfQVRBR1M9eQojIENPTkZJR19ERVBSRUNBVEVEX1BBUkFNX1NU UlVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JVSUxEX0FSTV9BUFBFTkRFRF9EVEJfSU1BR0Ug aXMgbm90IHNldApDT05GSUdfWkJPT1RfUk9NX1RFWFQ9MHgwCkNPTkZJR19aQk9PVF9ST01f QlNTPTB4MApDT05GSUdfQVJNX0FQUEVOREVEX0RUQj15CkNPTkZJR19BUk1fQVRBR19EVEJf Q09NUEFUPXkKQ09ORklHX0FSTV9BVEFHX0RUQl9DT01QQVRfQ01ETElORV9GUk9NX0JPT1RM T0FERVI9eQojIENPTkZJR19BUk1fQVRBR19EVEJfQ09NUEFUX0NNRExJTkVfRVhURU5EIGlz IG5vdCBzZXQKQ09ORklHX0NNRExJTkU9InJvb3Q9L2Rldi9tbWNibGswcDIgcm9vdHdhaXQg Y29uc29sZT10dHlPMiwxMTUyMDAiCkNPTkZJR19DTURMSU5FX0ZST01fQk9PVExPQURFUj15 CiMgQ09ORklHX0NNRExJTkVfRVhURU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfQ01ETElORV9G T1JDRSBpcyBub3Qgc2V0CkNPTkZJR19LRVhFQz15CkNPTkZJR19BVEFHU19QUk9DPXkKIyBD T05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CkNPTkZJR19BVVRPX1pSRUxBRERSPXkKCiMK IyBDUFUgUG93ZXIgTWFuYWdlbWVudAojCgojCiMgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nCiMK Q09ORklHX0NQVV9GUkVRPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9DT01NT049eQpDT05GSUdf Q1BVX0ZSRVFfU1RBVD15CkNPTkZJR19DUFVfRlJFUV9TVEFUX0RFVEFJTFM9eQojIENPTkZJ R19DUFVfRlJFUV9ERUZBVUxUX0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklH X0NQVV9GUkVRX0RFRkFVTFRfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQ VV9GUkVRX0RFRkFVTFRfR09WX1VTRVJTUEFDRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJF UV9ERUZBVUxUX0dPVl9PTkRFTUFORD15CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09W X0NPTlNFUlZBVElWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09W X0lOVEVSQUNUSVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dPVl9QRVJGT1JNQU5D RT15CkNPTkZJR19DUFVfRlJFUV9HT1ZfUE9XRVJTQVZFPW0KQ09ORklHX0NQVV9GUkVRX0dP Vl9VU0VSU1BBQ0U9bQpDT05GSUdfQ1BVX0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdf Q1BVX0ZSRVFfR09WX0lOVEVSQUNUSVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dP Vl9DT05TRVJWQVRJVkU9bQpDT05GSUdfR0VORVJJQ19DUFVGUkVRX0NQVTA9eQoKIwojIEFS TSBDUFUgZnJlcXVlbmN5IHNjYWxpbmcgZHJpdmVycwojCiMgQ09ORklHX0FSTV9LSVJLV09P RF9DUFVGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX09NQVAyUExVU19DUFVGUkVRIGlz IG5vdCBzZXQKCiMKIyBDUFUgSWRsZQojCkNPTkZJR19DUFVfSURMRT15CiMgQ09ORklHX0NQ VV9JRExFX01VTFRJUExFX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfQ1BVX0lETEVfR09W X0xBRERFUj15CkNPTkZJR19DUFVfSURMRV9HT1ZfTUVOVT15CgojCiMgQVJNIENQVSBJZGxl IERyaXZlcnMKIwojIENPTkZJR19BUk1fSElHSEJBTktfQ1BVSURMRSBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfTkVFRFNfQ1BVX0lETEVfQ09VUExFRCBpcyBub3Qgc2V0CgojCiMgRmxv YXRpbmcgcG9pbnQgZW11bGF0aW9uCiMKCiMKIyBBdCBsZWFzdCBvbmUgZW11bGF0aW9uIG11 c3QgYmUgc2VsZWN0ZWQKIwpDT05GSUdfVkZQPXkKQ09ORklHX1ZGUHYzPXkKQ09ORklHX05F T049eQojIENPTkZJR19LRVJORUxfTU9ERV9ORU9OIGlzIG5vdCBzZXQKCiMKIyBVc2Vyc3Bh Y2UgYmluYXJ5IGZvcm1hdHMKIwpDT05GSUdfQklORk1UX0VMRj15CkNPTkZJR19BUkNIX0JJ TkZNVF9FTEZfUkFORE9NSVpFX1BJRT15CkNPTkZJR19DT1JFX0RVTVBfREVGQVVMVF9FTEZf SEVBREVSUz15CkNPTkZJR19CSU5GTVRfU0NSSVBUPXkKIyBDT05GSUdfSEFWRV9BT1VUIGlz IG5vdCBzZXQKQ09ORklHX0JJTkZNVF9NSVNDPXkKQ09ORklHX0NPUkVEVU1QPXkKCiMKIyBQ b3dlciBtYW5hZ2VtZW50IG9wdGlvbnMKIwpDT05GSUdfU1VTUEVORD15CkNPTkZJR19TVVNQ RU5EX0ZSRUVaRVI9eQpDT05GSUdfSEFTX1dBS0VMT0NLPXkKQ09ORklHX1dBS0VMT0NLPXkK Q09ORklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FV VE9TTEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CkNP TkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKQ09ORklHX1BNX0RFQlVHPXkKIyBDT05G SUdfUE1fQURWQU5DRURfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QTV9URVNUX1NVU1BF TkQgaXMgbm90IHNldApDT05GSUdfUE1fU0xFRVBfREVCVUc9eQojIENPTkZJR19BUE1fRU1V TEFUSU9OIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX09QUD15CkNPTkZJR19QTV9PUFA9 eQpDT05GSUdfUE1fQ0xLPXkKIyBDT05GSUdfV1FfUE9XRVJfRUZGSUNJRU5UX0RFRkFVTFQg aXMgbm90IHNldApDT05GSUdfQ1BVX1BNPXkKIyBDT05GSUdfU1VTUEVORF9USU1FIGlzIG5v dCBzZXQKQ09ORklHX0FSQ0hfU1VTUEVORF9QT1NTSUJMRT15CkNPTkZJR19BUk1fQ1BVX1NV U1BFTkQ9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5nIG9wdGlvbnMKIwpDT05GSUdf UEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJQUcgaXMgbm90IHNldApDT05GSUdfVU5JWD15 CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qgc2V0CkNPTkZJR19YRlJNPXkKQ09ORklHX1hG Uk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9eQojIENPTkZJR19YRlJNX1NVQl9QT0xJQ1kg aXMgbm90IHNldApDT05GSUdfWEZSTV9NSUdSQVRFPXkKIyBDT05GSUdfWEZSTV9TVEFUSVNU SUNTIGlzIG5vdCBzZXQKQ09ORklHX05FVF9LRVk9eQpDT05GSUdfTkVUX0tFWV9NSUdSQVRF PXkKQ09ORklHX0lORVQ9eQpDT05GSUdfSVBfTVVMVElDQVNUPXkKIyBDT05GSUdfSVBfQURW QU5DRURfUk9VVEVSIGlzIG5vdCBzZXQKQ09ORklHX0lQX1BOUD15CkNPTkZJR19JUF9QTlBf REhDUD15CkNPTkZJR19JUF9QTlBfQk9PVFA9eQpDT05GSUdfSVBfUE5QX1JBUlA9eQojIENP TkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9JUF9UVU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JUF9N Uk9VVEUgaXMgbm90IHNldAojIENPTkZJR19TWU5fQ09PS0lFUyBpcyBub3Qgc2V0CiMgQ09O RklHX05FVF9JUFZUSSBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfQUggaXMgbm90IHNldAoj IENPTkZJR19JTkVUX0VTUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfSVBDT01QIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5FVF9YRlJNX1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO RVRfVFVOTkVMIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfWEZSTV9NT0RFX1RSQU5TUE9SVD15 CkNPTkZJR19JTkVUX1hGUk1fTU9ERV9UVU5ORUw9eQpDT05GSUdfSU5FVF9YRlJNX01PREVf QkVFVD15CiMgQ09ORklHX0lORVRfTFJPIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfRElBRz15 CkNPTkZJR19JTkVUX1RDUF9ESUFHPXkKIyBDT05GSUdfSU5FVF9VRFBfRElBRyBpcyBub3Qg c2V0CiMgQ09ORklHX1RDUF9DT05HX0FEVkFOQ0VEIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9D T05HX0NVQklDPXkKQ09ORklHX0RFRkFVTFRfVENQX0NPTkc9ImN1YmljIgojIENPTkZJR19U Q1BfTUQ1U0lHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0CiMgQ09ORklH X05FVExBQkVMIGlzIG5vdCBzZXQKQ09ORklHX0FORFJPSURfUEFSQU5PSURfTkVUV09SSz15 CkNPTkZJR19ORVRfQUNUSVZJVFlfU1RBVFM9eQojIENPTkZJR19ORVRXT1JLX1NFQ01BUksg aXMgbm90IHNldAojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMgbm90IHNl dApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBz ZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CkNPTkZJR19CUklER0VfTkVURklMVEVS PXkKCiMKIyBDb3JlIE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKIyBDT05GSUdfTkVURklM VEVSX05FVExJTktfQUNDVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5L X1FVRVVFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX05FVExJTktfTE9HIGlzIG5v dCBzZXQKQ09ORklHX05GX0NPTk5UUkFDSz1tCiMgQ09ORklHX05GX0NPTk5UUkFDS19NQVJL IGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5UUkFDS19QUk9DRlM9eQojIENPTkZJR19ORl9D T05OVFJBQ0tfRVZFTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RJTUVP VVQgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfVElNRVNUQU1QIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NU X1BST1RPX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9DVF9QUk9UT19VRFBMSVRFIGlz IG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX0FNQU5EQSBpcyBub3Qgc2V0CiMgQ09O RklHX05GX0NPTk5UUkFDS19GVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tf SDMyMyBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19JUkMgaXMgbm90IHNldAoj IENPTkZJR19ORl9DT05OVFJBQ0tfTkVUQklPU19OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05G X0NPTk5UUkFDS19TTk1QIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFAg aXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfU0FORSBpcyBub3Qgc2V0CiMgQ09O RklHX05GX0NPTk5UUkFDS19TSVAgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tf VEZUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NUX05FVExJTksgaXMgbm90IHNldAojIENP TkZJR19ORl9DVF9ORVRMSU5LX1RJTUVPVVQgaXMgbm90IHNldApDT05GSUdfTkZfTkFUPW0K Q09ORklHX05GX05BVF9ORUVERUQ9eQojIENPTkZJR19ORl9OQVRfQU1BTkRBIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkZfTkFUX0ZUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX05BVF9JUkMg aXMgbm90IHNldAojIENPTkZJR19ORl9OQVRfU0lQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZf TkFUX1RGVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9UQUJMRVMgaXMgbm90IHNldApDT05G SUdfTkVURklMVEVSX1hUQUJMRVM9bQoKIwojIFh0YWJsZXMgY29tYmluZWQgbW9kdWxlcwoj CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM VEVSX1hUX0NPTk5NQVJLIGlzIG5vdCBzZXQKCiMKIyBYdGFibGVzIHRhcmdldHMKIwojIENP TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NMQVNTSUZZIGlzIG5vdCBzZXQKIyBDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9DT05OTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJ TFRFUl9YVF9UQVJHRVRfSE1BUksgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf VEFSR0VUX0lETEVUSU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH RVRfTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MT0cgaXMg bm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUksgaXMgbm90IHNldAoj IENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05FVE1BUCBpcyBub3Qgc2V0CiMgQ09ORklH X05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0cgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxU RVJfWFRfVEFSR0VUX05GUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf VEFSR0VUX1JBVEVFU1QgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUUg aXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RDUE1TUyBpcyBub3Qg c2V0CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X0FERFJUWVBFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0JQRiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DR1JPVVAgaXMgbm90IHNl dAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0xVU1RFUiBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX0NPTk5CWVRFUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRF Ul9YVF9NQVRDSF9DT05OTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfQ09OTkxJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X0NPTk5NQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5U UkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DUFUgaXMgbm90 IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUCBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9ERVZHUk9VUCBpcyBub3Qgc2V0CiMgQ09ORklHX05F VEZJTFRFUl9YVF9NQVRDSF9EU0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hU X01BVENIX0VDTiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9FU1Ag aXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEFTSExJTUlUIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUiBpcyBub3Qgc2V0CiMg Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9ITCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJ TFRFUl9YVF9NQVRDSF9JUENPTVAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfSVBSQU5HRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9M MlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MSU1JVCBpcyBub3Qgc2V0CiMg Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9NQUMgaXMgbm90IHNldAojIENPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9N QVRDSF9NVUxUSVBPUlQgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf TkZBQ0NUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09XTkVSIGlz IG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BPTElDWSBpcyBub3Qgc2V0 CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QSFlTREVWIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEUgaXMgbm90IHNldAojIENPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfUVVPVEEgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfUVVPVEEyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JB VEVFU1QgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVBTE0gaXMg bm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5UIGlzIG5vdCBzZXQK IyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19O RVRGSUxURVJfWFRfTUFUQ0hfU09DS0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVS X1hUX01BVENIX1NUQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1NUQVRJU1RJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVFJJ TkcgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RJTUUgaXMgbm90IHNldAojIENP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfU0VU IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlMgaXMgbm90IHNldAoKIwojIElQOiBOZXRmaWx0 ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZSQUdfSVBWND1tCkNPTkZJR19ORl9D T05OVFJBQ0tfSVBWND1tCkNPTkZJR19ORl9DT05OVFJBQ0tfUFJPQ19DT01QQVQ9eQpDT05G SUdfSVBfTkZfSVBUQUJMRVM9bQojIENPTkZJR19JUF9ORl9NQVRDSF9BSCBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQX05GX01BVENIX0VDTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX01B VENIX1RUTCBpcyBub3Qgc2V0CkNPTkZJR19JUF9ORl9GSUxURVI9bQojIENPTkZJR19JUF9O Rl9UQVJHRVRfUkVKRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfVEFSR0VUX1NZTlBS T1hZIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0cgaXMgbm90IHNldApD T05GSUdfTkZfTkFUX0lQVjQ9bQpDT05GSUdfSVBfTkZfVEFSR0VUX01BU1FVRVJBREU9bQoj IENPTkZJR19JUF9ORl9UQVJHRVRfTkVUTUFQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZf VEFSR0VUX1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfTkFUX1BQVFAgaXMgbm90 IHNldAojIENPTkZJR19ORl9OQVRfSDMyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX01B TkdMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1JBVyBpcyBub3Qgc2V0CiMgQ09ORklH X0lQX05GX1NFQ1VSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfQVJQVEFCTEVTIGlz IG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX05GX0VCVEFCTEVTIGlzIG5vdCBzZXQKIyBDT05G SUdfSVBfRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1NDVFAgaXMgbm90IHNldAojIENP TkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBDT05GSUdf QVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9bQpD T05GSUdfQlJJREdFPW0KQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKQ09ORklHX0hB VkVfTkVUX0RTQT15CiMgQ09ORklHX1ZMQU5fODAyMVEgaXMgbm90IHNldAojIENPTkZJR19E RUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPW0KIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBD T05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklH X1BIT05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05G SUdfNkxPV1BBTl9JUEhDPW0KIyBDT05GSUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05G SUdfRENCIGlzIG5vdCBzZXQKQ09ORklHX0ROU19SRVNPTFZFUj15CiMgQ09ORklHX0JBVE1B Tl9BRFYgaXMgbm90IHNldAojIENPTkZJR19PUEVOVlNXSVRDSCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZTT0NLRVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19NTUFQIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkVUTElOS19ESUFHIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX01QTFNf R1NPIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNSIGlzIG5vdCBzZXQKQ09ORklHX1JQUz15CkNP TkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfQ0dST1VQX05FVF9QUklP IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQX05FVF9DTEFTU0lEIGlzIG5vdCBzZXQKQ09O RklHX05FVF9SWF9CVVNZX1BPTEw9eQpDT05GSUdfQlFMPXkKIyBDT05GSUdfQlBGX0pJVCBp cyBub3Qgc2V0CkNPTkZJR19ORVRfRkxPV19MSU1JVD15CgojCiMgTmV0d29yayB0ZXN0aW5n CiMKIyBDT05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9UQ1BQUk9C RSBpcyBub3Qgc2V0CiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQKQ09ORklHX0NBTj1t CkNPTkZJR19DQU5fUkFXPW0KQ09ORklHX0NBTl9CQ009bQpDT05GSUdfQ0FOX0dXPW0KCiMK IyBDQU4gRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19DQU5fVkNBTiBpcyBub3Qgc2V0CiMg Q09ORklHX0NBTl9TTENBTiBpcyBub3Qgc2V0CkNPTkZJR19DQU5fREVWPW0KQ09ORklHX0NB Tl9DQUxDX0JJVFRJTUlORz15CiMgQ09ORklHX0NBTl9MRURTIGlzIG5vdCBzZXQKIyBDT05G SUdfQ0FOX0FUOTEgaXMgbm90IHNldAojIENPTkZJR19DQU5fVElfSEVDQyBpcyBub3Qgc2V0 CiMgQ09ORklHX0NBTl9NQ1AyNTFYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0ZMRVhDQU4g aXMgbm90IHNldAojIENPTkZJR19QQ0hfQ0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0dS Q0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX1NKQTEwMDAgaXMgbm90IHNldApDT05GSUdf Q0FOX0NfQ0FOPW0KQ09ORklHX0NBTl9DX0NBTl9QTEFURk9STT1tCiMgQ09ORklHX0NBTl9D X0NBTl9QQ0kgaXMgbm90IHNldAojIENPTkZJR19DQU5fQ0M3NzAgaXMgbm90IHNldAoKIwoj IENBTiBVU0IgaW50ZXJmYWNlcwojCiMgQ09ORklHX0NBTl9FTVNfVVNCIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0FOX0VTRF9VU0IyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0tWQVNFUl9V U0IgaXMgbm90IHNldAojIENPTkZJR19DQU5fUEVBS19VU0IgaXMgbm90IHNldAojIENPTkZJ R19DQU5fOERFVl9VU0IgaXMgbm90IHNldAojIENPTkZJR19DQU5fU09GVElORyBpcyBub3Qg c2V0CiMgQ09ORklHX0NBTl9ERUJVR19ERVZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJE QSBpcyBub3Qgc2V0CkNPTkZJR19CVD1tCiMgQ09ORklHX0JUX1JGQ09NTSBpcyBub3Qgc2V0 CiMgQ09ORklHX0JUX0JORVAgaXMgbm90IHNldAojIENPTkZJR19CVF9ISURQIGlzIG5vdCBz ZXQKCiMKIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMKIwojIENPTkZJR19CVF9IQ0lCVFVT QiBpcyBub3Qgc2V0CiMgQ09ORklHX0JUX0hDSUJUU0RJTyBpcyBub3Qgc2V0CkNPTkZJR19C VF9IQ0lVQVJUPW0KQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9C Q1NQPXkKIyBDT05GSUdfQlRfSENJVUFSVF9BVEgzSyBpcyBub3Qgc2V0CkNPTkZJR19CVF9I Q0lVQVJUX0xMPXkKIyBDT05GSUdfQlRfSENJVUFSVF8zV0lSRSBpcyBub3Qgc2V0CkNPTkZJ R19CVF9IQ0lCQ00yMDNYPW0KQ09ORklHX0JUX0hDSUJQQTEwWD1tCiMgQ09ORklHX0JUX0hD SUJGVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRfSENJVkhDSSBpcyBub3Qgc2V0CiMgQ09O RklHX0JUX01SVkwgaXMgbm90IHNldApDT05GSUdfQlRfV0lMSU5LPW0KIyBDT05GSUdfQUZf UlhSUEMgaXMgbm90IHNldApDT05GSUdfV0lSRUxFU1M9eQojIENPTkZJR19DRkc4MDIxMSBp cyBub3Qgc2V0CiMgQ09ORklHX0xJQjgwMjExIGlzIG5vdCBzZXQKCiMKIyBDRkc4MDIxMSBu ZWVkcyB0byBiZSBlbmFibGVkIGZvciBNQUM4MDIxMQojCiMgQ09ORklHX1dJTUFYIGlzIG5v dCBzZXQKQ09ORklHX1JGS0lMTD15CkNPTkZJR19SRktJTExfUE09eQpDT05GSUdfUkZLSUxM X0xFRFM9eQojIENPTkZJR19SRktJTExfSU5QVVQgaXMgbm90IHNldAojIENPTkZJR19SRktJ TExfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZLSUxMX0dQSU8gaXMgbm90IHNl dAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENPTkZJR19DQUlGIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAojIENPTkZJR19ORkMgaXMgbm90IHNldApD T05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVycwojCgojCiMgR2VuZXJp YyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BBVEg9Ii9zYmluL2hv dHBsdWciCkNPTkZJR19ERVZUTVBGUz15CkNPTkZJR19ERVZUTVBGU19NT1VOVD15CkNPTkZJ R19TVEFOREFMT05FPXkKQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQ9eQpDT05GSUdf RldfTE9BREVSPXkKQ09ORklHX0ZJUk1XQVJFX0lOX0tFUk5FTD15CkNPTkZJR19FWFRSQV9G SVJNV0FSRT0iIgpDT05GSUdfRldfTE9BREVSX1VTRVJfSEVMUEVSPXkKIyBDT05GSUdfREVC VUdfRFJJVkVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfREVWUkVTIGlzIG5vdCBzZXQK Q09ORklHX1NZU19IWVBFUlZJU09SPXkKIyBDT05GSUdfR0VORVJJQ19DUFVfREVWSUNFUyBp cyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQ1BVX0FVVE9QUk9CRSBpcyBub3Qgc2V0CkNPTkZJ R19TT0NfQlVTPXkKQ09ORklHX1JFR01BUD15CkNPTkZJR19SRUdNQVBfSTJDPXkKQ09ORklH X1JFR01BUF9TUEk9eQpDT05GSUdfUkVHTUFQX01NSU89eQpDT05GSUdfUkVHTUFQX0lSUT15 CkNPTkZJR19ETUFfU0hBUkVEX0JVRkZFUj15CkNPTkZJR19ETUFfQ01BPXkKCiMKIyBEZWZh dWx0IGNvbnRpZ3VvdXMgbWVtb3J5IGFyZWEgc2l6ZToKIwpDT05GSUdfQ01BX1NJWkVfTUJZ VEVTPTI0CkNPTkZJR19DTUFfU0laRV9TRUxfTUJZVEVTPXkKIyBDT05GSUdfQ01BX1NJWkVf U0VMX1BFUkNFTlRBR0UgaXMgbm90IHNldAojIENPTkZJR19DTUFfU0laRV9TRUxfTUlOIGlz IG5vdCBzZXQKIyBDT05GSUdfQ01BX1NJWkVfU0VMX01BWCBpcyBub3Qgc2V0CkNPTkZJR19D TUFfQUxJR05NRU5UPTgKQ09ORklHX0NNQV9BUkVBUz03CgojCiMgQnVzIGRldmljZXMKIwpD T05GSUdfT01BUF9PQ1AyU0NQPXkKIyBDT05GSUdfT01BUF9JTlRFUkNPTk5FQ1QgaXMgbm90 IHNldAojIENPTkZJR19BUk1fQ0NJIGlzIG5vdCBzZXQKQ09ORklHX0NPTk5FQ1RPUj15CkNP TkZJR19QUk9DX0VWRU5UUz15CkNPTkZJR19NVEQ9eQpDT05GSUdfTVREX1RFU1RTPW0KIyBD T05GSUdfTVREX1JFREJPT1RfUEFSVFMgaXMgbm90IHNldApDT05GSUdfTVREX0NNRExJTkVf UEFSVFM9eQojIENPTkZJR19NVERfQUZTX1BBUlRTIGlzIG5vdCBzZXQKQ09ORklHX01URF9P Rl9QQVJUUz15CiMgQ09ORklHX01URF9BUjdfUEFSVFMgaXMgbm90IHNldAoKIwojIFVzZXIg TW9kdWxlcyBBbmQgVHJhbnNsYXRpb24gTGF5ZXJzCiMKQ09ORklHX01URF9CTEtERVZTPXkK Q09ORklHX01URF9CTE9DSz15CiMgQ09ORklHX0ZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX05G VEwgaXMgbm90IHNldAojIENPTkZJR19JTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JGRF9G VEwgaXMgbm90IHNldAojIENPTkZJR19TU0ZEQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NNX0ZU TCBpcyBub3Qgc2V0CkNPTkZJR19NVERfT09QUz15CiMgQ09ORklHX01URF9TV0FQIGlzIG5v dCBzZXQKCiMKIyBSQU0vUk9NL0ZsYXNoIGNoaXAgZHJpdmVycwojCkNPTkZJR19NVERfQ0ZJ PXkKIyBDT05GSUdfTVREX0pFREVDUFJPQkUgaXMgbm90IHNldApDT05GSUdfTVREX0dFTl9Q Uk9CRT15CiMgQ09ORklHX01URF9DRklfQURWX09QVElPTlMgaXMgbm90IHNldApDT05GSUdf TVREX01BUF9CQU5LX1dJRFRIXzE9eQpDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzI9eQpD T05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzQ9eQojIENPTkZJR19NVERfTUFQX0JBTktfV0lE VEhfOCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8xNiBpcyBub3Qg c2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8zMiBpcyBub3Qgc2V0CkNPTkZJR19N VERfQ0ZJX0kxPXkKQ09ORklHX01URF9DRklfSTI9eQojIENPTkZJR19NVERfQ0ZJX0k0IGlz IG5vdCBzZXQKIyBDT05GSUdfTVREX0NGSV9JOCBpcyBub3Qgc2V0CkNPTkZJR19NVERfQ0ZJ X0lOVEVMRVhUPXkKIyBDT05GSUdfTVREX0NGSV9BTURTVEQgaXMgbm90IHNldAojIENPTkZJ R19NVERfQ0ZJX1NUQUEgaXMgbm90IHNldApDT05GSUdfTVREX0NGSV9VVElMPXkKIyBDT05G SUdfTVREX1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9ST00gaXMgbm90IHNldAojIENP TkZJR19NVERfQUJTRU5UIGlzIG5vdCBzZXQKCiMKIyBNYXBwaW5nIGRyaXZlcnMgZm9yIGNo aXAgYWNjZXNzCiMKIyBDT05GSUdfTVREX0NPTVBMRVhfTUFQUElOR1MgaXMgbm90IHNldAoj IENPTkZJR19NVERfUEhZU01BUCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9QSFlTTUFQX09G IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0lOVEVMX1ZSX05PUiBpcyBub3Qgc2V0CiMgQ09O RklHX01URF9QTEFUUkFNIGlzIG5vdCBzZXQKCiMKIyBTZWxmLWNvbnRhaW5lZCBNVEQgZGV2 aWNlIGRyaXZlcnMKIwojIENPTkZJR19NVERfUE1DNTUxIGlzIG5vdCBzZXQKIyBDT05GSUdf TVREX0RBVEFGTEFTSCBpcyBub3Qgc2V0CkNPTkZJR19NVERfTTI1UDgwPW0KIyBDT05GSUdf TVREX1NTVDI1TCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9TTFJBTSBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9QSFJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NVERSQU0gaXMgbm90 IHNldAojIENPTkZJR19NVERfQkxPQ0syTVREIGlzIG5vdCBzZXQKCiMKIyBEaXNrLU9uLUNo aXAgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19NVERfRE9DRzMgaXMgbm90IHNldApDT05G SUdfTVREX05BTkRfSURTPXkKQ09ORklHX01URF9OQU5EX0VDQz15CiMgQ09ORklHX01URF9O QU5EX0VDQ19TTUMgaXMgbm90IHNldApDT05GSUdfTVREX05BTkQ9eQojIENPTkZJR19NVERf TkFORF9FQ0NfQkNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX1NNX0NPTU1PTiBpcyBub3Qg c2V0CiMgQ09ORklHX01URF9OQU5EX0RFTkFMSSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9O QU5EX0dQSU8gaXMgbm90IHNldApDT05GSUdfTVREX05BTkRfT01BUDI9eQpDT05GSUdfTVRE X05BTkRfT01BUF9CQ0g9eQojIENPTkZJR19NVERfTkFORF9SSUNPSCBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9OQU5EX0RJU0tPTkNISVAgaXMgbm90IHNldAojIENPTkZJR19NVERfTkFO RF9ET0NHNCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9OQU5EX0NBRkUgaXMgbm90IHNldAoj IENPTkZJR19NVERfTkFORF9OQU5EU0lNIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX05BTkRf UExBVEZPUk0gaXMgbm90IHNldApDT05GSUdfTVREX09ORU5BTkQ9eQpDT05GSUdfTVREX09O RU5BTkRfVkVSSUZZX1dSSVRFPXkKIyBDT05GSUdfTVREX09ORU5BTkRfR0VORVJJQyBpcyBu b3Qgc2V0CiMgQ09ORklHX01URF9PTkVOQU5EX09UUCBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9PTkVOQU5EXzJYX1BST0dSQU0gaXMgbm90IHNldAoKIwojIExQRERSIGZsYXNoIG1lbW9y eSBkcml2ZXJzCiMKIyBDT05GSUdfTVREX0xQRERSIGlzIG5vdCBzZXQKQ09ORklHX01URF9V Qkk9eQpDT05GSUdfTVREX1VCSV9XTF9USFJFU0hPTEQ9NDA5NgpDT05GSUdfTVREX1VCSV9C RUJfTElNSVQ9MjAKIyBDT05GSUdfTVREX1VCSV9GQVNUTUFQIGlzIG5vdCBzZXQKIyBDT05G SUdfTVREX1VCSV9HTFVFQkkgaXMgbm90IHNldApDT05GSUdfRFRDPXkKQ09ORklHX09GPXkK CiMKIyBEZXZpY2UgVHJlZSBhbmQgT3BlbiBGaXJtd2FyZSBzdXBwb3J0CiMKQ09ORklHX1BS T0NfREVWSUNFVFJFRT15CiMgQ09ORklHX09GX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklH X09GX0ZMQVRUUkVFPXkKQ09ORklHX09GX0VBUkxZX0ZMQVRUUkVFPXkKQ09ORklHX09GX0FE RFJFU1M9eQpDT05GSUdfT0ZfSVJRPXkKQ09ORklHX09GX05FVD15CkNPTkZJR19PRl9NRElP PXkKQ09ORklHX09GX1BDST15CkNPTkZJR19PRl9QQ0lfSVJRPXkKQ09ORklHX09GX01URD15 CkNPTkZJR19PRl9SRVNFUlZFRF9NRU09eQpDT05GSUdfQVJDSF9NSUdIVF9IQVZFX1BDX1BB UlBPUlQ9eQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVY9eQoj IENPTkZJR19CTEtfREVWX05VTExfQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9Q Q0lFU1NEX01USVAzMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9DSVNTX0RBIGlz IG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EQUM5NjAgaXMgbm90IHNldAojIENPTkZJR19C TEtfREVWX1VNRU0gaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NPV19DT01NT04gaXMg bm90IHNldApDT05GSUdfQkxLX0RFVl9MT09QPXkKQ09ORklHX0JMS19ERVZfTE9PUF9NSU5f Q09VTlQ9OAojIENPTkZJR19CTEtfREVWX0NSWVBUT0xPT1AgaXMgbm90IHNldAojIENPTkZJ R19CTEtfREVWX0RSQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX05CRCBpcyBub3Qg c2V0CiMgQ09ORklHX0JMS19ERVZfTlZNRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZf U1g4IGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfUkFNPXkKQ09ORklHX0JMS19ERVZfUkFN X0NPVU5UPTE2CkNPTkZJR19CTEtfREVWX1JBTV9TSVpFPTE2Mzg0CiMgQ09ORklHX0JMS19E RVZfWElQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0CiMg Q09ORklHX0FUQV9PVkVSX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX01HX0RJU0sgaXMgbm90 IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JB Q0tFTkQ9eQojIENPTkZJR19WSVJUSU9fQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF Vl9SQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1JTWFggaXMgbm90IHNldAoKIwoj IE1pc2MgZGV2aWNlcwojCkNPTkZJR19TRU5TT1JTX0xJUzNMVjAyRD1tCiMgQ09ORklHX0FE NTI1WF9EUE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNRUxfUFdNIGlzIG5vdCBzZXQKIyBD T05GSUdfRFVNTVlfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0 CiMgQ09ORklHX1NHSV9JT0M0IGlzIG5vdCBzZXQKIyBDT05GSUdfVElGTV9DT1JFIGlzIG5v dCBzZXQKIyBDT05GSUdfSUNTOTMyUzQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTUVMX1NT QyBpcyBub3Qgc2V0CiMgQ09ORklHX0VOQ0xPU1VSRV9TRVJWSUNFUyBpcyBub3Qgc2V0CiMg Q09ORklHX0hQX0lMTyBpcyBub3Qgc2V0CiMgQ09ORklHX0FQRFM5ODAyQUxTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVNMMjkwMDMgaXMgbm90IHNldAojIENPTkZJR19JU0wyOTAyMCBpcyBu b3Qgc2V0CkNPTkZJR19TRU5TT1JTX1RTTDI1NTA9bQojIENPTkZJR19TRU5TT1JTX0JIMTc4 MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19BUERTOTkwWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90 IHNldAojIENPTkZJR19EUzE2ODIgaXMgbm90IHNldAojIENPTkZJR19USV9EQUM3NTEyIGlz IG5vdCBzZXQKIyBDT05GSUdfVUlEX1NUQVQgaXMgbm90IHNldApDT05GSUdfQk1QMDg1PXkK Q09ORklHX0JNUDA4NV9JMkM9bQojIENPTkZJR19CTVAwODVfU1BJIGlzIG5vdCBzZXQKIyBD T05GSUdfUENIX1BIVUIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1dJVENIX0ZTQTk0ODAg aXMgbm90IHNldAojIENPTkZJR19MQVRUSUNFX0VDUDNfQ09ORklHIGlzIG5vdCBzZXQKIyBD T05GSUdfU1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0CgojCiMg RUVQUk9NIHN1cHBvcnQKIwojIENPTkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMgQ09O RklHX0VFUFJPTV9BVDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk9NX0xFR0FDWSBpcyBu b3Qgc2V0CiMgQ09ORklHX0VFUFJPTV9NQVg2ODc1IGlzIG5vdCBzZXQKQ09ORklHX0VFUFJP TV85M0NYNj15CiMgQ09ORklHX0VFUFJPTV85M1hYNDYgaXMgbm90IHNldAojIENPTkZJR19D QjcxMF9DT1JFIGlzIG5vdCBzZXQKCiMKIyBUZXhhcyBJbnN0cnVtZW50cyBzaGFyZWQgdHJh bnNwb3J0IGxpbmUgZGlzY2lwbGluZQojCkNPTkZJR19USV9TVD15CkNPTkZJR19TVF9IQ0k9 eQojIENPTkZJR19TRU5TT1JTX0xJUzNfU1BJIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNf TElTM19JMkM9bQoKIwojIEFsdGVyYSBGUEdBIGZpcm13YXJlIGRvd25sb2FkIG1vZHVsZQoj CiMgQ09ORklHX0FMVEVSQV9TVEFQTCBpcyBub3Qgc2V0CgojCiMgSW50ZWwgTUlDIEhvc3Qg RHJpdmVyCiMKCiMKIyBJbnRlbCBNSUMgQ2FyZCBEcml2ZXIKIwpDT05GSUdfSEFWRV9JREU9 eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFNDU0kgZGV2aWNlIHN1cHBvcnQKIwpD T05GSUdfU0NTSV9NT0Q9eQojIENPTkZJR19SQUlEX0FUVFJTIGlzIG5vdCBzZXQKQ09ORklH X1NDU0k9eQpDT05GSUdfU0NTSV9ETUE9eQojIENPTkZJR19TQ1NJX1RHVCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NDU0lfTkVUTElOSyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1BST0NfRlM9 eQoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09ORklH X0JMS19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdf Q0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0 CiMgQ09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNldAojIENPTkZJR19DSFJfREVWX1NDSCBp cyBub3Qgc2V0CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CiMgQ09ORklHX1NDU0lfQ09OU1RB TlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlzIG5vdCBzZXQKQ09ORklH X1NDU0lfU0NBTl9BU1lOQz15CgojCiMgU0NTSSBUcmFuc3BvcnRzCiMKIyBDT05GSUdfU0NT SV9TUElfQVRUUlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZDX0FUVFJTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9JU0NTSV9BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf U0FTX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9TUlBfQVRUUlMgaXMgbm90IHNldApDT05GSUdfU0NTSV9MT1dM RVZFTD15CiMgQ09ORklHX0lTQ1NJX1RDUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0JP T1RfU1lTRlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf Qk5YMl9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQk5YMlhfRkNPRSBpcyBub3Qg c2V0CiMgQ09ORklHX0JFMklTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl8zV19Y WFhYX1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90IHNldAojIENP TkZJR19TQ1NJXzNXXzlYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJXzNXX1NBUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FB Q1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90IHNldAojIENP TkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzk0WFggaXMg bm90IHNldAojIENPTkZJR19TQ1NJX01WU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9N VlVNSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQVJDTVNSIGlzIG5vdCBzZXQKIyBDT05G SUdfU0NTSV9FU0FTMlIgaXMgbm90IHNldAojIENPTkZJR19NRUdBUkFJRF9ORVdHRU4gaXMg bm90IHNldAojIENPTkZJR19NRUdBUkFJRF9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19N RUdBUkFJRF9TQVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01QVDJTQVMgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX01QVDNTQVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1VGU0hD RCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSFBUSU9QIGlzIG5vdCBzZXQKIyBDT05GSUdf TElCRkMgaXMgbm90IHNldAojIENPTkZJR19MSUJGQ09FIGlzIG5vdCBzZXQKIyBDT05GSUdf RkNPRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENP TkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TVEVYIGlzIG5vdCBzZXQKIyBD T05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSVBSIGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfMTI4MCBpcyBub3Qgc2V0CiMgQ09ORklH X1NDU0lfUUxBX0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTEFfSVNDU0kgaXMgbm90 IHNldAojIENPTkZJR19TQ1NJX0xQRkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RDMzk1 eCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTBUIGlzIG5vdCBzZXQKIyBDT05GSUdf U0NTSV9OU1AzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREVCVUcgaXMgbm90IHNldAoj IENPTkZJR19TQ1NJX1BNQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BNODAwMSBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1JQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9C RkFfRkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1ZJUlRJTyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfQ0hFTFNJT19GQ09FIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ESCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZF UkJPU0VfRVJST1I9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGgg bm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKIyBDT05GSUdfU0FUQV9BSENJIGlzIG5vdCBz ZXQKQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STT15CiMgQ09ORklHX0FIQ0lfSU1YIGlzIG5v dCBzZXQKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf QUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMgbm90IHNldApD T05GSUdfQVRBX1NGRj15CgojCiMgU0ZGIGNvbnRyb2xsZXJzIHdpdGggY3VzdG9tIERNQSBp bnRlcmZhY2UKIwojIENPTkZJR19QRENfQURNQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf UVNUT1IgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NYNCBpcyBub3Qgc2V0CkNPTkZJR19B VEFfQk1ETUE9eQoKIwojIFNBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1ETUEKIwojIENP TkZJR19BVEFfUElJWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfSElHSEJBTksgaXMgbm90 IHNldAojIENPTkZJR19TQVRBX01WIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9OViBpcyBu b3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJPTUlTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf UkNBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdf U0FUQV9TSVMgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09O RklHX1NBVEFfVUxJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAoj IENPTkZJR19TQVRBX1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xs ZXJzIHdpdGggQk1ETUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklH X1BBVEFfQU1EIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BUkFTQU5fQ0YgaXMgbm90IHNl dAojIENPTkZJR19QQVRBX0FSVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVElJWFAg aXMgbm90IHNldAojIENPTkZJR19QQVRBX0FUUDg2N1ggaXMgbm90IHNldAojIENPTkZJR19Q QVRBX0NNRDY0WCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1M1NTIwIGlzIG5vdCBzZXQK IyBDT05GSUdfUEFUQV9DUzU1MzAgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NTNTUzNiBp cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1lQUkVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BB VEFfRUZBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSFBUMzY2IGlzIG5vdCBzZXQKIyBD T05GSUdfUEFUQV9IUFQzN1ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMk4gaXMg bm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf SVQ4MjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9JVDgyMVggaXMgbm90IHNldAojIENP TkZJR19QQVRBX0pNSUNST04gaXMgbm90IHNldAojIENPTkZJR19QQVRBX01BUlZFTEwgaXMg bm90IHNldAojIENPTkZJR19QQVRBX05FVENFTEwgaXMgbm90IHNldAojIENPTkZJR19QQVRB X05JTkpBMzIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05TODc0MTUgaXMgbm90IHNldAoj IENPTkZJR19QQVRBX09MRFBJSVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX09QVElETUEg aXMgbm90IHNldAojIENPTkZJR19QQVRBX1BEQzIwMjdYIGlzIG5vdCBzZXQKIyBDT05GSUdf UEFUQV9QRENfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SQURJU1lTIGlzIG5vdCBz ZXQKIyBDT05GSUdfUEFUQV9SREMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NDMTIwMCBp cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0NIIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9T RVJWRVJXT1JLUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0lMNjgwIGlzIG5vdCBzZXQK IyBDT05GSUdfUEFUQV9TSVMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1RPU0hJQkEgaXMg bm90IHNldAojIENPTkZJR19QQVRBX1RSSUZMRVggaXMgbm90IHNldAojIENPTkZJR19QQVRB X1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfV0lOQk9ORCBpcyBub3Qgc2V0CgojCiMg UElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJzCiMKIyBDT05GSUdfUEFUQV9DTUQ2NDBfUENJIGlz IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9NUElJWCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf TlM4NzQxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfT1BUSSBpcyBub3Qgc2V0CiMgQ09O RklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19QQVRBX1JaMTAwMCBpcyBu b3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2FjeSBkcml2ZXJzCiMKIyBDT05G SUdfQVRBX0dFTkVSSUMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0xFR0FDWSBpcyBub3Qg c2V0CkNPTkZJR19NRD15CiMgQ09ORklHX0JMS19ERVZfTUQgaXMgbm90IHNldAojIENPTkZJ R19CQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0RNIGlzIG5vdCBzZXQKIyBD T05GSUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNl dAoKIwojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lS RSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJ R19JMk8gaXMgbm90IHNldApDT05GSUdfTkVUREVWSUNFUz15CkNPTkZJR19NSUk9eQpDT05G SUdfTkVUX0NPUkU9eQojIENPTkZJR19CT05ESU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfRFVN TVkgaXMgbm90IHNldAojIENPTkZJR19FUVVBTElaRVIgaXMgbm90IHNldAojIENPTkZJR19O RVRfRkMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVEVBTSBpcyBub3Qgc2V0CiMgQ09ORklH X01BQ1ZMQU4gaXMgbm90IHNldAojIENPTkZJR19WWExBTiBpcyBub3Qgc2V0CiMgQ09ORklH X05FVENPTlNPTEUgaXMgbm90IHNldAojIENPTkZJR19ORVRQT0xMIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVUX1BPTExfQ09OVFJPTExFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZFVEggaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9fTkVUIGlz IG5vdCBzZXQKIyBDT05GSUdfTkxNT04gaXMgbm90IHNldAojIENPTkZJR19BUkNORVQgaXMg bm90IHNldAoKIwojIENBSUYgdHJhbnNwb3J0IGRyaXZlcnMKIwoKIwojIERpc3RyaWJ1dGVk IFN3aXRjaCBBcmNoaXRlY3R1cmUgZHJpdmVycwojCiMgQ09ORklHX05FVF9EU0FfTVY4OEU2 WFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTYwNjAgaXMgbm90IHNldAoj IENPTkZJR19ORVRfRFNBX01WODhFNlhYWF9ORUVEX1BQVSBpcyBub3Qgc2V0CiMgQ09ORklH X05FVF9EU0FfTVY4OEU2MTMxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTYx MjNfNjFfNjUgaXMgbm90IHNldApDT05GSUdfRVRIRVJORVQ9eQpDT05GSUdfTkVUX1ZFTkRP Ul8zQ09NPXkKIyBDT05GSUdfVk9SVEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFlQSE9PTiBp cyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0FEQVBURUM9eQojIENPTkZJR19BREFQVEVD X1NUQVJGSVJFIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQUxURU9OPXkKIyBDT05G SUdfQUNFTklDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQU1EPXkKIyBDT05GSUdf QU1EODExMV9FVEggaXMgbm90IHNldAojIENPTkZJR19QQ05FVDMyIGlzIG5vdCBzZXQKQ09O RklHX05FVF9WRU5ET1JfQVJDPXkKIyBDT05GSUdfQVJDX0VNQUMgaXMgbm90IHNldApDT05G SUdfTkVUX1ZFTkRPUl9BVEhFUk9TPXkKIyBDT05GSUdfQVRMMiBpcyBub3Qgc2V0CiMgQ09O RklHX0FUTDEgaXMgbm90IHNldAojIENPTkZJR19BVEwxRSBpcyBub3Qgc2V0CiMgQ09ORklH X0FUTDFDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxYIGlzIG5vdCBzZXQKQ09ORklHX05FVF9D QURFTkNFPXkKIyBDT05GSUdfQVJNX0FUOTFfRVRIRVIgaXMgbm90IHNldAojIENPTkZJR19N QUNCIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT009eQojIENPTkZJR19C NDQgaXMgbm90IHNldAojIENPTkZJR19CTlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ05JQyBp cyBub3Qgc2V0CiMgQ09ORklHX1RJR09OMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JOWDJYIGlz IG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQlJPQ0FERT15CiMgQ09ORklHX0JOQSBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9DQUxYRURBX1hHTUFDIGlzIG5vdCBzZXQKQ09ORklHX05F VF9WRU5ET1JfQ0hFTFNJTz15CiMgQ09ORklHX0NIRUxTSU9fVDEgaXMgbm90IHNldAojIENP TkZJR19DSEVMU0lPX1QzIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hFTFNJT19UNCBpcyBub3Qg c2V0CiMgQ09ORklHX0NIRUxTSU9fVDRWRiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X0NJUlJVUz15CiMgQ09ORklHX0NTODl4MCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X0NJU0NPPXkKIyBDT05GSUdfRU5JQyBpcyBub3Qgc2V0CiMgQ09ORklHX0RNOTAwMCBpcyBu b3Qgc2V0CiMgQ09ORklHX0RORVQgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9ERUM9 eQojIENPTkZJR19ORVRfVFVMSVAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9ETElO Sz15CiMgQ09ORklHX0RMMksgaXMgbm90IHNldAojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0VNVUxFWD15CiMgQ09ORklHX0JFMk5FVCBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0VYQVI9eQojIENPTkZJR19TMklPIGlzIG5vdCBzZXQK IyBDT05GSUdfVlhHRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0ZBUkFEQVk9eQoj IENPTkZJR19GVE1BQzEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZUR01BQzEwMCBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0hQPXkKIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldApD T05GSUdfTkVUX1ZFTkRPUl9JTlRFTD15CiMgQ09ORklHX0UxMDAgaXMgbm90IHNldAojIENP TkZJR19FMTAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0UxMDAwRSBpcyBub3Qgc2V0CiMgQ09O RklHX0lHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lHQlZGIGlzIG5vdCBzZXQKIyBDT05GSUdf SVhHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSTQw RSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAw MCBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X01BUlZFTEw9eQojIENPTkZJR19NVk1ESU8gaXMgbm90IHNldAojIENPTkZJR19TS0dFIGlz IG5vdCBzZXQKIyBDT05GSUdfU0tZMiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01F TExBTk9YPXkKIyBDT05GSUdfTUxYNF9FTiBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDRfQ09S RSBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDVfQ09SRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRf VkVORE9SX01JQ1JFTD15CiMgQ09ORklHX0tTODg0MiBpcyBub3Qgc2V0CkNPTkZJR19LUzg4 NTE9eQpDT05GSUdfS1M4ODUxX01MTD15CiMgQ09ORklHX0tTWjg4NFhfUENJIGlzIG5vdCBz ZXQKQ09ORklHX05FVF9WRU5ET1JfTUlDUk9DSElQPXkKIyBDT05GSUdfRU5DMjhKNjAgaXMg bm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9NWVJJPXkKIyBDT05GSUdfTVlSSTEwR0UgaXMg bm90IHNldAojIENPTkZJR19GRUFMTlggaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9O QVRTRU1JPXkKIyBDT05GSUdfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05TODM4MjAg aXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl84MzkwPXkKIyBDT05GSUdfQVg4ODc5NiBp cyBub3Qgc2V0CiMgQ09ORklHX05FMktfUENJIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5E T1JfTlZJRElBPXkKIyBDT05GSUdfRk9SQ0VERVRIIGlzIG5vdCBzZXQKQ09ORklHX05FVF9W RU5ET1JfT0tJPXkKIyBDT05GSUdfRVRIT0MgaXMgbm90IHNldApDT05GSUdfTkVUX1BBQ0tF VF9FTkdJTkU9eQojIENPTkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQKIyBDT05GSUdfWUVMTE9X RklOIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfUUxPR0lDPXkKIyBDT05GSUdfUUxB M1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1FMQ05JQyBpcyBub3Qgc2V0CiMgQ09ORklHX1FM R0UgaXMgbm90IHNldAojIENPTkZJR19ORVRYRU5fTklDIGlzIG5vdCBzZXQKQ09ORklHX05F VF9WRU5ET1JfUkVBTFRFSz15CiMgQ09ORklHXzgxMzlDUCBpcyBub3Qgc2V0CiMgQ09ORklH XzgxMzlUT08gaXMgbm90IHNldAojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0CiMgQ09ORklH X1NIX0VUSCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1JEQz15CiMgQ09ORklHX1I2 MDQwIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0VFUT15CkNPTkZJR19ORVRfVkVO RE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVO RE9SX1NJUz15CiMgQ09ORklHX1NJUzkwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJUzE5MCBp cyBub3Qgc2V0CiMgQ09ORklHX1NGQyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NN U0M9eQpDT05GSUdfU01DOTFYPXkKIyBDT05GSUdfRVBJQzEwMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NNQzkxMVggaXMgbm90IHNldApDT05GSUdfU01TQzkxMVg9eQojIENPTkZJR19TTVND OTExWF9BUkNIX0hPT0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TQzk0MjAgaXMgbm90IHNl dApDT05GSUdfTkVUX1ZFTkRPUl9TVE1JQ1JPPXkKIyBDT05GSUdfU1RNTUFDX0VUSCBpcyBu b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NVTj15CiMgQ09ORklHX0hBUFBZTUVBTCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NVTkdFTSBpcyBub3Qgc2V0CiMgQ09ORklHX0NBU1NJTkkgaXMg bm90IHNldAojIENPTkZJR19OSVUgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9URUhV VEk9eQojIENPTkZJR19URUhVVEkgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9UST15 CkNPTkZJR19USV9EQVZJTkNJX01ESU89eQpDT05GSUdfVElfREFWSU5DSV9DUERNQT15CkNP TkZJR19USV9DUFNXX1BIWV9TRUw9eQpDT05GSUdfVElfQ1BTVz15CkNPTkZJR19USV9DUFRT PXkKIyBDT05GSUdfVExBTiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1ZJQT15CiMg Q09ORklHX1ZJQV9SSElORSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJQV9WRUxPQ0lUWSBpcyBu b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEw MCBpcyBub3Qgc2V0CiMgQ09ORklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklH X0ZEREkgaXMgbm90IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CkNPTkZJR19QSFlM SUI9eQoKIwojIE1JSSBQSFkgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfQVQ4MDNYX1BIWT15 CiMgQ09ORklHX0FNRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NQVJWRUxMX1BIWSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RBVklDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUVNFTUlf UEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0NJ Q0FEQV9QSFkgaXMgbm90IHNldAojIENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0CkNP TkZJR19TTVNDX1BIWT15CiMgQ09ORklHX0JST0FEQ09NX1BIWSBpcyBub3Qgc2V0CiMgQ09O RklHX0JDTTg3WFhfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUNQTFVTX1BIWSBpcyBub3Qg c2V0CiMgQ09ORklHX1JFQUxURUtfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFUSU9OQUxf UEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xT SV9FVDEwMTFDX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNl dAojIENPTkZJR19GSVhFRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcg aXMgbm90IHNldAojIENPTkZJR19NRElPX0JVU19NVVhfR1BJTyBpcyBub3Qgc2V0CiMgQ09O RklHX01ESU9fQlVTX01VWF9NTUlPUkVHIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlDUkVMX0tT ODk5NU1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xJ UCBpcyBub3Qgc2V0CgojCiMgVVNCIE5ldHdvcmsgQWRhcHRlcnMKIwojIENPTkZJR19VU0Jf Q0FUQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9LQVdFVEggaXMgbm90IHNldAojIENPTkZJ R19VU0JfUEVHQVNVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SVEw4MTUwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1JUTDgxNTIgaXMgbm90IHNldApDT05GSUdfVVNCX1VTQk5FVD15 CkNPTkZJR19VU0JfTkVUX0FYODgxN1g9eQpDT05GSUdfVVNCX05FVF9BWDg4MTc5XzE3OEE9 eQpDT05GSUdfVVNCX05FVF9DRENFVEhFUj15CiMgQ09ORklHX1VTQl9ORVRfQ0RDX0VFTSBp cyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX0NEQ19OQ009eQojIENPTkZJR19VU0JfTkVUX0hV QVdFSV9DRENfTkNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9DRENfTUJJTSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfRE05NjAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X05FVF9TUjk3MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1NSOTgwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMgbm90IHNldApDT05GSUdfVVNCX05F VF9TTVNDOTVYWD15CiMgQ09ORklHX1VTQl9ORVRfR0w2MjBBIGlzIG5vdCBzZXQKQ09ORklH X1VTQl9ORVRfTkVUMTA4MD15CiMgQ09ORklHX1VTQl9ORVRfUExVU0IgaXMgbm90IHNldAoj IENPTkZJR19VU0JfTkVUX01DUzc4MzAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1JO RElTX0hPU1QgaXMgbm90IHNldApDT05GSUdfVVNCX05FVF9DRENfU1VCU0VUPXkKQ09ORklH X1VTQl9BTElfTTU2MzI9eQpDT05GSUdfVVNCX0FOMjcyMD15CkNPTkZJR19VU0JfQkVMS0lO PXkKQ09ORklHX1VTQl9BUk1MSU5VWD15CkNPTkZJR19VU0JfRVBTT04yODg4PXkKQ09ORklH X1VTQl9LQzIxOTA9eQpDT05GSUdfVVNCX05FVF9aQVVSVVM9eQojIENPTkZJR19VU0JfTkVU X0NYODIzMTBfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9LQUxNSUEgaXMgbm90 IHNldAojIENPTkZJR19VU0JfTkVUX1FNSV9XV0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0hTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfSU5UNTFYMSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9JUEhFVEggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0lFUlJBX05FVCBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9WTDYwMCBpcyBub3Qgc2V0CkNPTkZJR19XTEFOPXkK IyBDT05GSUdfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1pEMTIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1dJRklfQ09OVFJPTF9G VU5DIGlzIG5vdCBzZXQKIyBDT05GSUdfSE9TVEFQIGlzIG5vdCBzZXQKIyBDT05GSUdfV0xf VEkgaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0 byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05G SUdfWEVOX05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQoj IENPTkZJR19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0Cgoj CiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQojIENPTkZJR19JTlBV VF9GRl9NRU1MRVNTIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1BPTExERVY9bQojIENPTkZJ R19JTlBVVF9TUEFSU0VLTUFQIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01BVFJJWEtNQVA9 bQoKIwojIFVzZXJsYW5kIGludGVyZmFjZXMKIwpDT05GSUdfSU5QVVRfTU9VU0VERVY9eQpD T05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVg9eQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NS RUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4CkNPTkZJR19J TlBVVF9KT1lERVY9eQpDT05GSUdfSU5QVVRfRVZERVY9eQojIENPTkZJR19JTlBVVF9FVkJV RyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0tFWVJFU0VUIGlzIG5vdCBzZXQKIyBDT05G SUdfSU5QVVRfS0VZQ09NQk8gaXMgbm90IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJz CiMKQ09ORklHX0lOUFVUX0tFWUJPQVJEPXkKIyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OCBp cyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODkgaXMgbm90IHNldApDT05GSUdf S0VZQk9BUkRfQVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9RVDEwNzAgaXMgbm90IHNldAoj IENPTkZJR19LRVlCT0FSRF9RVDIxNjAgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9M S0tCRCBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9HUElPPXkKIyBDT05GSUdfS0VZQk9B UkRfVENBNjQxNiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTg0MTggaXMgbm90 IHNldApDT05GSUdfS0VZQk9BUkRfTUFUUklYPW0KIyBDT05GSUdfS0VZQk9BUkRfTE04MzIz IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTE04MzMzIGlzIG5vdCBzZXQKIyBDT05G SUdfS0VZQk9BUkRfTUFYNzM1OSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01DUyBp cyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01QUjEyMSBpcyBub3Qgc2V0CiMgQ09ORklH X0tFWUJPQVJEX05FV1RPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09QRU5DT1JF UyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NBTVNVTkcgaXMgbm90IHNldAojIENP TkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NV TktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09NQVA0IGlzIG5vdCBzZXQKIyBD T05GSUdfS0VZQk9BUkRfWFRLQkQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0U9eQpD T05GSUdfTU9VU0VfUFMyPXkKQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01PVVNF X1BTMl9MT0dJUFMyUFA9eQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19N T1VTRV9QUzJfQ1lQUkVTUz15CkNPTkZJR19NT1VTRV9QUzJfVFJBQ0tQT0lOVD15CiMgQ09O RklHX01PVVNFX1BTMl9FTEFOVEVDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1BTMl9T RU5URUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1BTMl9UT1VDSEtJVCBpcyBub3Qg c2V0CiMgQ09ORklHX01PVVNFX1NFUklBTCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX0FQ UExFVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9CQ001OTc0IGlzIG5vdCBzZXQK IyBDT05GSUdfTU9VU0VfQ1lBUEEgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9WU1hYWEFB IGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01P VVNFX1NZTkFQVElDU19JMkMgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1Nf VVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfSk9ZU1RJQ0sgaXMgbm90IHNldAojIENP TkZJR19JTlBVVF9UQUJMRVQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfVE9VQ0hTQ1JFRU49 eQpDT05GSUdfVE9VQ0hTQ1JFRU5fQURTNzg0Nj15CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FE Nzg3NyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FENzg3OSBpcyBub3Qgc2V0 CkNPTkZJR19UT1VDSFNDUkVFTl9BVE1FTF9NWFQ9eQojIENPTkZJR19UT1VDSFNDUkVFTl9B VU9fUElYQ0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fQlUyMTAxMyBpcyBu b3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0NZOENUTUcxMTAgaXMgbm90IHNldAojIENP TkZJR19UT1VDSFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNI U0NSRUVOX0NZVFRTUDRfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0RZ TkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMgbm90 IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fRUdBTEFYIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRlVKSVRT VSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFggaXMgbm90IHNldAoj IENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NS RUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxIGlz IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJDIGlzIG5vdCBzZXQKIyBD T05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND UkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTU1TMTE0IGlz IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05G SUdfVE9VQ0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f TUs3MTIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QRU5NT1VOVCBpcyBub3Qg c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMgbm90IHNldAojIENPTkZJ R19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF RU5fVE9VQ0hXSU4gaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fVElfQU0zMzVYX1RT Qz15CkNPTkZJR19UT1VDSFNDUkVFTl9QSVhDSVI9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fTERD MzAwMT15CiMgQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9DT01QT1NJVEUgaXMgbm90IHNldAoj IENPTkZJR19UT1VDSFNDUkVFTl9UT1VDSElUMjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fVFNDX1NFUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVFND MjAwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNl dAojIENPTkZJR19UT1VDSFNDUkVFTl9XOTBYOTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fU1QxMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fU1VSNDAg aXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qgc2V0CiMg Q09ORklHX1RPVUNIU0NSRUVOX1pGT1JDRSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NSVND PXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQk1B MTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09O RklHX0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9HUDJBIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5QVVRfR1BJT19CRUVQRVIgaXMgbm90IHNldAojIENPTkZJR19J TlBVVF9HUElPX1RJTFRfUE9MTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQVRJX1JF TU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlDSE9SRCBpcyBub3Qgc2V0CiMg Q09ORklHX0lOUFVUX0tFWVNQQU5fUkVNT1RFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRf S1hUSjkgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9QT1dFUk1BVEUgaXMgbm90IHNldAoj IENPTkZJR19JTlBVVF9ZRUFMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQ00xMDkg aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9UV0w2MDQwX1ZJQlJBIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5QVVRfVUlOUFVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfR1BJTyBpcyBu b3Qgc2V0CkNPTkZJR19JTlBVVF9QQUxNQVNfUFdSQlVUVE9OPXkKIyBDT05GSUdfSU5QVVRf UENGODU3NCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0dQSU9fUk9UQVJZX0VOQ09ERVIg aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BRFhMMzRYIGlzIG5vdCBzZXQKIyBDT05GSUdf SU5QVVRfSU1TX1BDVSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNQTMwMDAgaXMgbm90 IHNldApDT05GSUdfSU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdhcmUg SS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX1NFUlBPUlQ9eQojIENP TkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9fTElCUFMyPXkKIyBD T05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fQUxURVJBX1BTMiBp cyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1VTFQgaXMgbm90IHNldAojIENPTkZJR19T RVJJT19BUkNfUFMyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fQVBCUFMyIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VSSU9fT0xQQ19BUFNQIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBP UlQgaXMgbm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1RUWT15CkNP TkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJR19WVF9DT05T T0xFPXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdfSFdfQ09OU09MRT15CkNP TkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENP TkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVH QUNZX1BUWVMgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRBUkQgaXMgbm90 IHNldAojIENPTkZJR19OT1pPTUkgaXMgbm90IHNldAojIENPTkZJR19OX0dTTSBpcyBub3Qg c2V0CiMgQ09ORklHX1RSQUNFX1NJTksgaXMgbm90IHNldApDT05GSUdfREVWTUVNPXkKQ09O RklHX0RFVktNRU09eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUw PXkKQ09ORklHX1NFUklBTF84MjUwX0RFUFJFQ0FURURfT1BUSU9OUz15CkNPTkZJR19TRVJJ QUxfODI1MF9DT05TT0xFPXkKQ09ORklHX1NFUklBTF84MjUwX0RNQT15CkNPTkZJR19TRVJJ QUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfTlJfVUFSVFM9MzIKQ09ORklHX1NF UklBTF84MjUwX1JVTlRJTUVfVUFSVFM9NApDT05GSUdfU0VSSUFMXzgyNTBfRVhURU5ERUQ9 eQpDT05GSUdfU0VSSUFMXzgyNTBfTUFOWV9QT1JUUz15CkNPTkZJR19TRVJJQUxfODI1MF9T SEFSRV9JUlE9eQpDT05GSUdfU0VSSUFMXzgyNTBfREVURUNUX0lSUT15CkNPTkZJR19TRVJJ QUxfODI1MF9SU0E9eQojIENPTkZJR19TRVJJQUxfODI1MF9EVyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklBTF84MjUwX0VNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMXzgyNTBfT01B UCBpcyBub3Qgc2V0CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9ydAojCiMgQ09O RklHX1NFUklBTF9NQVgzMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX01BWDMxMFgg aXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBub3Qgc2V0CiMgQ09ORklH X1NFUklBTF9TSF9TQ0kgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9eQpDT05GSUdf U0VSSUFMX0NPUkVfQ09OU09MRT15CiMgQ09ORklHX1NFUklBTF9KU00gaXMgbm90IHNldApD T05GSUdfU0VSSUFMX09GX1BMQVRGT1JNPXkKQ09ORklHX1NFUklBTF9PTUFQPXkKQ09ORklH X1NFUklBTF9PTUFQX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfU0NDTlhQIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VSSUFMX1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19TRVJJ QUxfQUxURVJBX0pUQUdVQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9V QVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0lGWDZYNjAgaXMgbm90IHNldAojIENP TkZJR19TRVJJQUxfUENIX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfWElMSU5Y X1BTX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfQVJDIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VSSUFMX1JQMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9GU0xfTFBVQVJU IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1NUX0FTQyBpcyBub3Qgc2V0CiMgQ09ORklH X1RUWV9QUklOVEsgaXMgbm90IHNldApDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNf SVJRPXkKQ09ORklHX0hWQ19YRU49eQpDT05GSUdfSFZDX1hFTl9GUk9OVEVORD15CiMgQ09O RklHX0hWQ19EQ0MgaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9fQ09OU09MRSBpcyBub3Qg c2V0CiMgQ09ORklHX0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET009 eQojIENPTkZJR19IV19SQU5ET01fVElNRVJJT01FTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hX X1JBTkRPTV9BVE1FTCBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET01fT01BUD15CiMgQ09O RklHX0hXX1JBTkRPTV9WSVJUSU8gaXMgbm90IHNldAojIENPTkZJR19IV19SQU5ET01fRVhZ Tk9TIGlzIG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldAojIENPTkZJR19BUFBM SUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1JBV19EUklWRVIgaXMgbm90IHNldAojIENPTkZJ R19UQ0dfVFBNIGlzIG5vdCBzZXQKQ09ORklHX0RFVlBPUlQ9eQojIENPTkZJR19EQ0NfVFRZ IGlzIG5vdCBzZXQKQ09ORklHX0kyQz15CkNPTkZJR19JMkNfQk9BUkRJTkZPPXkKQ09ORklH X0kyQ19DT01QQVQ9eQpDT05GSUdfSTJDX0NIQVJERVY9eQojIENPTkZJR19JMkNfTVVYIGlz IG5vdCBzZXQKQ09ORklHX0kyQ19IRUxQRVJfQVVUTz15CkNPTkZJR19JMkNfQUxHT0JJVD15 CgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNv bnRyb2xsZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBD T05GSUdfSTJDX0FMSTE1NjMgaXMgbm90IHNldAojIENPTkZJR19JMkNfQUxJMTVYMyBpcyBu b3Qgc2V0CiMgQ09ORklHX0kyQ19BTUQ3NTYgaXMgbm90IHNldAojIENPTkZJR19JMkNfQU1E ODExMSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JODAxIGlzIG5vdCBzZXQKIyBDT05GSUdf STJDX0lTQ0ggaXMgbm90IHNldAojIENPTkZJR19JMkNfUElJWDQgaXMgbm90IHNldAojIENP TkZJR19JMkNfTkZPUkNFMiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM1NTk1IGlzIG5v dCBzZXQKIyBDT05GSUdfSTJDX1NJUzYzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM5 NlggaXMgbm90IHNldAojIENPTkZJR19JMkNfVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X1ZJQVBSTyBpcyBub3Qgc2V0CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5 IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0NCVVNfR1BJTyBp cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BMQVRGT1JNIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX0RFU0lHTldBUkVfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VH MjBUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19J MkNfT0NPUkVTIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19PTUFQPXkKIyBDT05GSUdfSTJDX1BD QV9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QWEFfUENJIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX1NJTVRFQyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19YSUxJTlggaXMg bm90IHNldAoKIwojIEV4dGVybmFsIEkyQy9TTUJ1cyBhZGFwdGVyIGRyaXZlcnMKIwojIENP TkZJR19JMkNfRElPTEFOX1UyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QQVJQT1JUX0xJ R0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1JPQk9URlVaWl9PU0lGIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX1RBT1NfRVZNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1RJTllfVVNC IGlzIG5vdCBzZXQKCiMKIyBPdGhlciBJMkMvU01CdXMgYnVzIGRyaXZlcnMKIwojIENPTkZJ R19JMkNfU1RVQiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19DT1JFIGlzIG5vdCBz ZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19JMkNfREVC VUdfQlVTIGlzIG5vdCBzZXQKQ09ORklHX1NQST15CiMgQ09ORklHX1NQSV9ERUJVRyBpcyBu b3Qgc2V0CkNPTkZJR19TUElfTUFTVEVSPXkKCiMKIyBTUEkgTWFzdGVyIENvbnRyb2xsZXIg RHJpdmVycwojCiMgQ09ORklHX1NQSV9BTFRFUkEgaXMgbm90IHNldAojIENPTkZJR19TUElf QklUQkFORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9HUElPIGlzIG5vdCBzZXQKIyBDT05G SUdfU1BJX0ZTTF9TUEkgaXMgbm90IHNldAojIENPTkZJR19TUElfT0NfVElOWSBpcyBub3Qg c2V0CkNPTkZJR19TUElfT01BUDI0WFg9eQpDT05GSUdfU1BJX1RJX1FTUEk9eQojIENPTkZJ R19TUElfUFhBMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX1BYQTJYWF9QQ0kgaXMgbm90 IHNldAojIENPTkZJR19TUElfU0MxOElTNjAyIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX1RP UENMSUZGX1BDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9YQ09NTSBpcyBub3Qgc2V0CiMg Q09ORklHX1NQSV9YSUxJTlggaXMgbm90IHNldAojIENPTkZJR19TUElfREVTSUdOV0FSRSBp cyBub3Qgc2V0CgojCiMgU1BJIFByb3RvY29sIE1hc3RlcnMKIwpDT05GSUdfU1BJX1NQSURF Vj15CiMgQ09ORklHX1NQSV9UTEU2MlgwIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNJIGlzIG5v dCBzZXQKCiMKIyBQUFMgc3VwcG9ydAojCkNPTkZJR19QUFM9eQojIENPTkZJR19QUFNfREVC VUcgaXMgbm90IHNldAoKIwojIFBQUyBjbGllbnRzIHN1cHBvcnQKIwojIENPTkZJR19QUFNf Q0xJRU5UX0tUSU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BQU19DTElFTlRfTERJU0MgaXMg bm90IHNldAojIENPTkZJR19QUFNfQ0xJRU5UX0dQSU8gaXMgbm90IHNldAoKIwojIFBQUyBn ZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBUUCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BU UF8xNTg4X0NMT0NLPXkKCiMKIyBFbmFibGUgUEhZTElCIGFuZCBORVRXT1JLX1BIWV9USU1F U1RBTVBJTkcgdG8gc2VlIHRoZSBhZGRpdGlvbmFsIGNsb2Nrcy4KIwpDT05GSUdfUElOQ1RS TD15CgojCiMgUGluIGNvbnRyb2xsZXJzCiMKQ09ORklHX1BJTk1VWD15CkNPTkZJR19QSU5D T05GPXkKQ09ORklHX0dFTkVSSUNfUElOQ09ORj15CiMgQ09ORklHX0RFQlVHX1BJTkNUUkwg aXMgbm90IHNldAojIENPTkZJR19QSU5DVFJMX0NBUFJJIGlzIG5vdCBzZXQKQ09ORklHX1BJ TkNUUkxfVElfSU9ERUxBWT15CiMgQ09ORklHX1BJTkNUUkxfTVNNOFg3NCBpcyBub3Qgc2V0 CkNPTkZJR19QSU5DVFJMX1NJTkdMRT15CiMgQ09ORklHX1BJTkNUUkxfUEFMTUFTIGlzIG5v dCBzZXQKQ09ORklHX0FSQ0hfSEFWRV9DVVNUT01fR1BJT19IPXkKQ09ORklHX0FSQ0hfUkVR VUlSRV9HUElPTElCPXkKQ09ORklHX0dQSU9MSUI9eQpDT05GSUdfR1BJT19ERVZSRVM9eQpD T05GSUdfT0ZfR1BJTz15CkNPTkZJR19ERUJVR19HUElPPXkKQ09ORklHX0dQSU9fU1lTRlM9 eQoKIwojIE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzOgojCiMgQ09ORklHX0dQSU9fR0VO RVJJQ19QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fRU0gaXMgbm90IHNldAoj IENPTkZJR19HUElPX1JDQVIgaXMgbm90IHNldAojIENPTkZJR19HUElPX1NDSDMxMVggaXMg bm90IHNldAojIENPTkZJR19HUElPX1RTNTUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f Vlg4NTUgaXMgbm90IHNldAojIENPTkZJR19HUElPX0dSR1BJTyBpcyBub3Qgc2V0CgojCiMg STJDIEdQSU8gZXhwYW5kZXJzOgojCiMgQ09ORklHX0dQSU9fTUFYNzMwMCBpcyBub3Qgc2V0 CiMgQ09ORklHX0dQSU9fTUFYNzMyWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fUENBOTUz WF9JUlEgaXMgbm90IHNldApDT05GSUdfR1BJT19QQ0Y4NTdYPXkKIyBDT05GSUdfR1BJT19T WDE1MFggaXMgbm90IHNldAojIENPTkZJR19HUElPX1RXTDYwNDAgaXMgbm90IHNldAojIENP TkZJR19HUElPX0FEUDU1ODggaXMgbm90IHNldAojIENPTkZJR19HUElPX0FETlAgaXMgbm90 IHNldAoKIwojIFBDSSBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19HUElPX0JUOFhYIGlz IG5vdCBzZXQKIyBDT05GSUdfR1BJT19BTUQ4MTExIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJ T19NTF9JT0ggaXMgbm90IHNldAojIENPTkZJR19HUElPX1JEQzMyMVggaXMgbm90IHNldAoK IwojIFNQSSBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19HUElPX01BWDczMDEgaXMgbm90 IHNldAojIENPTkZJR19HUElPX01DUDIzUzA4IGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19N QzMzODgwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT183NFgxNjQgaXMgbm90IHNldAoKIwoj IEFDOTcgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBMUEMgR1BJTyBleHBhbmRlcnM6CiMKCiMK IyBNT0RVTGJ1cyBHUElPIGV4cGFuZGVyczoKIwpDT05GSUdfR1BJT19QQUxNQVM9eQojIENP TkZJR19HUElPX1RQUzY1OTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19CQ01fS09OQSBp cyBub3Qgc2V0CgojCiMgVVNCIEdQSU8gZXhwYW5kZXJzOgojCkNPTkZJR19XMT15CkNPTkZJ R19XMV9DT049eQoKIwojIDEtd2lyZSBCdXMgTWFzdGVycwojCiMgQ09ORklHX1cxX01BU1RF Ul9NQVRST1ggaXMgbm90IHNldAojIENPTkZJR19XMV9NQVNURVJfRFMyNDkwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfTUFTVEVSX0RTMjQ4MiBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX01B U1RFUl9EUzFXTSBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX01BU1RFUl9HUElPIGlzIG5vdCBz ZXQKIyBDT05GSUdfSERRX01BU1RFUl9PTUFQIGlzIG5vdCBzZXQKCiMKIyAxLXdpcmUgU2xh dmVzCiMKIyBDT05GSUdfVzFfU0xBVkVfVEhFUk0gaXMgbm90IHNldAojIENPTkZJR19XMV9T TEFWRV9TTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDA4IGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyNDIzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDMxIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDMzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyNzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNzgwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNzgxIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyOEUwNCBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX1NMQVZFX0JRMjcwMDAgaXMgbm90 IHNldApDT05GSUdfUE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVH IGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfR0VO RVJJQ19BRENfQkFUVEVSWSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfUE9XRVIgaXMgbm90 IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRF UllfRFMyNzgxIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODIgaXMgbm90IHNl dAojIENPTkZJR19CQVRURVJZX1NCUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfQlEy N3gwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfTUFYMTcwNDAgaXMgbm90IHNldAoj IENPTkZJR19CQVRURVJZX01BWDE3MDQyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9J U1AxNzA0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAzIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0hBUkdFUl9MUDg3MjcgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0dQ SU8gaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX01BTkFHRVIgaXMgbm90IHNldAojIENP TkZJR19DSEFSR0VSX0JRMjQxNVggaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQx OTAgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQ3MzUgaXMgbm90IHNldAojIENP TkZJR19DSEFSR0VSX1NNQjM0NyBpcyBub3Qgc2V0CiMgQ09ORklHX1BPV0VSX1JFU0VUIGlz IG5vdCBzZXQKIyBDT05GSUdfUE9XRVJfUkVTRVRfUkVTVEFSVCBpcyBub3Qgc2V0CkNPTkZJ R19QT1dFUl9BVlM9eQpDT05GSUdfVk9MVEFHRV9ET01BSU49eQoKIwojIFZvbHRhZ2UgRG9t YWluIEZyYW1ld29yayBEcml2ZXJzCiMKQ09ORklHX1ZPTFRBR0VfRE9NQUlOX09NQVA9eQpD T05GSUdfVElfQ09QUk9DPXkKQ09ORklHX0hXTU9OPXkKIyBDT05GSUdfSFdNT05fVklEIGlz IG5vdCBzZXQKIyBDT05GSUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0 aXZlIGRyaXZlcnMKIwojIENPTkZJR19TRU5TT1JTX0FENzMxNCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRDc0MTgg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEQ1hYIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRE0xMDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI1IGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI2IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRE0xMDI5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDMxIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE05MjQwIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRFQ3MzEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRFQ3NDYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDcwIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDc1IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BU0M3NjIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BVFhQMSBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRFM2MjAgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0RTMTYyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSTVLX0FNQiBpcyBub3Qg c2V0CiMgQ09ORklHX1NFTlNPUlNfRjcxODA1RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP UlNfRjcxODgyRkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0Y3NTM3NVMgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0c3NjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19HNzYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfR1BJ T19GQU49eQojIENPTkZJR19TRU5TT1JTX0hJSDYxMzAgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0hUVTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JSU9fSFdNT04gaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0lUODcgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0pDNDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJTkVBR0UgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0xNNjMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xN NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzMgaXMgbm90IHNldApDT05GSUdf U0VOU09SU19MTTc1PW0KIyBDT05GSUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19MTTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkyIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjE1IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjM0IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxMTExIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfTUFYMTYxOSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19NQVg2NjM5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19NQVg2Njk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19OQ1Q2Nzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzM2 MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19TSFQxNSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf U0hUMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NJUzU1OTUgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX1NNTTY2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRE1F MTczNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0CiMg Q09ORklHX1NFTlNPUlNfRU1DMjEwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1D NlcyMDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19TTVNDNDdNMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19TTVNDNDdCMzk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1P TiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0NINTYyNyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfU0NINTYzNiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTMTAx NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTNzgyOCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfQURTNzg3MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQU1DNjgy MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSU5BMjA5IGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19JTkEyWFggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RITUM1MCBp cyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1RNUDEwMj15CiMgQ09ORklHX1NFTlNPUlNfVE1Q NDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVA0MjEgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX1ZJQTY4NkEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1ZUMTIx MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQ4MjMxIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTFE IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTJEIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODM3OTMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5NSBp cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODNMNzg2TkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4MzYy N0hGIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMgbm90IHNldApD T05GSUdfVEhFUk1BTD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxf T0Y9eQpDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9TVEVQX1dJU0U9eQojIENPTkZJR19U SEVSTUFMX0RFRkFVTFRfR09WX0ZBSVJfU0hBUkUgaXMgbm90IHNldAojIENPTkZJR19USEVS TUFMX0RFRkFVTFRfR09WX1VTRVJfU1BBQ0UgaXMgbm90IHNldApDT05GSUdfVEhFUk1BTF9H T1ZfRkFJUl9TSEFSRT15CkNPTkZJR19USEVSTUFMX0dPVl9TVEVQX1dJU0U9eQpDT05GSUdf VEhFUk1BTF9HT1ZfVVNFUl9TUEFDRT15CkNPTkZJR19DUFVfVEhFUk1BTD15CiMgQ09ORklH X1RIRVJNQUxfRU1VTEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSU1YX1RIRVJNQUwgaXMg bm90IHNldAoKIwojIFRleGFzIEluc3RydW1lbnRzIHRoZXJtYWwgZHJpdmVycwojCkNPTkZJ R19USV9TT0NfVEhFUk1BTD15CkNPTkZJR19USV9USEVSTUFMPXkKQ09ORklHX0RSQTc1Ml9U SEVSTUFMPXkKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX0NPUkU9eQojIENP TkZJR19XQVRDSERPR19OT1dBWU9VVCBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNl IERyaXZlcnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdf R1BJT19XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX0RXX1dBVENIRE9HIGlzIG5vdCBz ZXQKQ09ORklHX09NQVBfV0FUQ0hET0c9eQojIENPTkZJR19NQVg2M1hYX1dBVENIRE9HIGlz IG5vdCBzZXQKIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTYz MDBFU0JfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVOX0EyMV9XRFQgaXMgbm90IHNldAoj IENPTkZJR19YRU5fV0RUIGlzIG5vdCBzZXQKCiMKIyBQQ0ktYmFzZWQgV2F0Y2hkb2cgQ2Fy ZHMKIwojIENPTkZJR19QQ0lQQ1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfV0RUUENJ IGlzIG5vdCBzZXQKCiMKIyBVU0ItYmFzZWQgV2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19V U0JQQ1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1NTQl9QT1NTSUJMRT15CgojCiMgU29u aWNzIFNpbGljb24gQmFja3BsYW5lCiMKIyBDT05GSUdfU1NCIGlzIG5vdCBzZXQKQ09ORklH X0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwojIENPTkZJ R19CQ01BIGlzIG5vdCBzZXQKCiMKIyBNdWx0aWZ1bmN0aW9uIGRldmljZSBkcml2ZXJzCiMK Q09ORklHX01GRF9DT1JFPXkKIyBDT05GSUdfTUZEX0FTMzcxMSBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9BUzM3MjIgaXMgbm90IHNldAojIENPTkZJR19QTUlDX0FEUDU1MjAgaXMgbm90 IHNldAojIENPTkZJR19NRkRfQUFUMjg3MF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X0NST1NfRUMgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVNJQzMgaXMgbm90IHNldAojIENP TkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9EQTkwNTJfU1BJIGlz IG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1Ml9JMkMgaXMgbm90IHNldAojIENPTkZJR19N RkRfREE5MDU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA2MyBpcyBub3Qgc2V0CiMg Q09ORklHX01GRF9NQzEzWFhYX1NQSSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhY X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hUQ19FR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklH X0hUQ19QQVNJQzMgaXMgbm90IHNldAojIENPTkZJR19IVENfSTJDUExEIGlzIG5vdCBzZXQK IyBDT05GSUdfTFBDX0lDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0xQQ19TQ0ggaXMgbm90IHNl dAojIENPTkZJR19NRkRfSkFOWl9DTU9ESU8gaXMgbm90IHNldAojIENPTkZJR19NRkRfS0VN UExEIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEXzg4UE04MDAgaXMgbm90IHNldAojIENPTkZJ R19NRkRfODhQTTgwNSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF84OFBNODYwWCBpcyBub3Qg c2V0CiMgQ09ORklHX01GRF9NQVgxNDU3NyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3 NzY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3NzY5MyBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9NQVg4OTA3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01BWDg5MjUgaXMgbm90 IHNldAojIENPTkZJR19NRkRfTUFYODk5NyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4 OTk4IGlzIG5vdCBzZXQKIyBDT05GSUdfRVpYX1BDQVAgaXMgbm90IHNldAojIENPTkZJR19N RkRfVklQRVJCT0FSRCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9SRVRVIGlzIG5vdCBzZXQK IyBDT05GSUdfTUZEX1BDRjUwNjMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JEQzMyMVgg aXMgbm90IHNldAojIENPTkZJR19NRkRfUlRTWF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19N RkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TRUNfQ09SRSBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9TSTQ3NlhfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTTUw MSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJY NTAwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfU1RNUEUgaXMgbm90IHNldApDT05G SUdfTUZEX1NZU0NPTj15CkNPTkZJR19NRkRfVElfQU0zMzVYX1RTQ0FEQz15CiMgQ09ORklH X01GRF9MUDM5NDMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTFA4Nzg4IGlzIG5vdCBzZXQK Q09ORklHX01GRF9PTUFQX1VTQl9IT1NUPXkKQ09ORklHX01GRF9QQUxNQVM9eQojIENPTkZJ R19UUFM2MTA1WCBpcyBub3Qgc2V0CiMgQ09ORklHX1RQUzY1MDEwIGlzIG5vdCBzZXQKIyBD T05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjUwOTAgaXMgbm90 IHNldApDT05GSUdfTUZEX1RQUzY1MjE3PXkKQ09ORklHX01GRF9UUFM2NTIxOD15CiMgQ09O RklHX01GRF9UUFM2NTg2WCBpcyBub3Qgc2V0CkNPTkZJR19NRkRfVFBTNjU5MTA9eQojIENP TkZJR19NRkRfVFBTNjU5MTIgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjU5MTJfSTJD IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEyX1NQSSBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9UUFM4MDAzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDQwMzBfQ09SRSBpcyBu b3Qgc2V0CkNPTkZJR19UV0w2MDQwX0NPUkU9eQojIENPTkZJR19NRkRfV0wxMjczX0NPUkUg aXMgbm90IHNldAojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5WCBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1Q3TDY2WEIgaXMg bm90IHNldAojIENPTkZJR19NRkRfVEM2Mzg3WEIgaXMgbm90IHNldAojIENPTkZJR19NRkRf VEM2MzkzWEIgaXMgbm90IHNldAojIENPTkZJR19NRkRfVlg4NTUgaXMgbm90IHNldAojIENP TkZJR19NRkRfQVJJWk9OQV9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVJJWk9OQV9T UEkgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004NDAwIGlzIG5vdCBzZXQKIyBDT05GSUdf TUZEX1dNODMxWF9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004MzFYX1NQSSBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzNTBfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X1dNODk5NCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZFWFBSRVNTX0NPTkZJRyBpcyBub3Qgc2V0 CkNPTkZJR19SRUdVTEFUT1I9eQojIENPTkZJR19SRUdVTEFUT1JfREVCVUcgaXMgbm90IHNl dApDT05GSUdfUkVHVUxBVE9SX0ZJWEVEX1ZPTFRBR0U9eQojIENPTkZJR19SRUdVTEFUT1Jf VklSVFVBTF9DT05TVU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9VU0VSU1BB Q0VfQ09OU1VNRVIgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfQUNUODg2NSBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9BRDUzOTggaXMgbm90IHNldAojIENPTkZJR19S RUdVTEFUT1JfQU5BVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0RBOTIxMCBp cyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9GQU41MzU1NSBpcyBub3Qgc2V0CkNPTkZJ R19SRUdVTEFUT1JfR1BJTz15CiMgQ09ORklHX1JFR1VMQVRPUl9JU0w2MjcxQSBpcyBub3Qg c2V0CiMgQ09ORklHX1JFR1VMQVRPUl9MUDM5NzEgaXMgbm90IHNldAojIENPTkZJR19SRUdV TEFUT1JfTFAzOTcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0xQODcyWCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9MUDg3NTUgaXMgbm90IHNldAojIENPTkZJR19S RUdVTEFUT1JfTUFYMTU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9NQVg4NjQ5 IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX01BWDg2NjAgaXMgbm90IHNldAojIENP TkZJR19SRUdVTEFUT1JfTUFYODk1MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9N QVg4OTczIGlzIG5vdCBzZXQKQ09ORklHX1JFR1VMQVRPUl9QQUxNQVM9eQpDT05GSUdfUkVH VUxBVE9SX1BCSUFTPXkKIyBDT05GSUdfUkVHVUxBVE9SX1BGVVpFMTAwIGlzIG5vdCBzZXQK Q09ORklHX1JFR1VMQVRPUl9USV9BQkI9eQojIENPTkZJR19SRUdVTEFUT1JfVFBTNTE2MzIg aXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfVFBTNjIzNjAgaXMgbm90IHNldApDT05G SUdfUkVHVUxBVE9SX1RQUzY1MDIzPXkKQ09ORklHX1JFR1VMQVRPUl9UUFM2NTA3WD15CkNP TkZJR19SRUdVTEFUT1JfVFBTNjUyMTc9eQpDT05GSUdfUkVHVUxBVE9SX1RQUzY1MjE4PXkK IyBDT05GSUdfUkVHVUxBVE9SX1RQUzY1MjRYIGlzIG5vdCBzZXQKQ09ORklHX1JFR1VMQVRP Ul9UUFM2NTkxMD15CkNPTkZJR19NRURJQV9TVVBQT1JUPXkKCiMKIyBNdWx0aW1lZGlhIGNv cmUgc3VwcG9ydAojCkNPTkZJR19NRURJQV9DQU1FUkFfU1VQUE9SVD15CiMgQ09ORklHX01F RElBX0FOQUxPR19UVl9TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVESUFfRElHSVRB TF9UVl9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9eQoj IENPTkZJR19NRURJQV9SQ19TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX0NPTlRS T0xMRVI9eQpDT05GSUdfVklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDJfU1VCREVWX0FQ ST15CkNPTkZJR19WSURFT19WNEwyPXkKIyBDT05GSUdfVklERU9fQURWX0RFQlVHIGlzIG5v dCBzZXQKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBzZXQKQ09O RklHX1Y0TDJfTUVNMk1FTV9ERVY9bQpDT05GSUdfVklERU9CVUYyX0NPUkU9bQpDT05GSUdf VklERU9CVUYyX01FTU9QUz1tCkNPTkZJR19WSURFT0JVRjJfRE1BX0NPTlRJRz1tCkNPTkZJ R19WSURFT0JVRjJfVk1BTExPQz1tCiMgQ09ORklHX1RUUENJX0VFUFJPTSBpcyBub3Qgc2V0 CgojCiMgTWVkaWEgZHJpdmVycwojCkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMg V2ViY2FtIGRldmljZXMKIwpDT05GSUdfVVNCX1ZJREVPX0NMQVNTPW0KQ09ORklHX1VTQl9W SURFT19DTEFTU19JTlBVVF9FVkRFVj15CkNPTkZJR19VU0JfR1NQQ0E9bQojIENPTkZJR19V U0JfTTU2MDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RWMDZYWCBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9HTDg2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9CRU5RIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0NPTkVYIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX0NQSUExIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0VUT01TIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0ZJTkVQSVggaXMgbm90IHNldAojIENPTkZJ R19VU0JfR1NQQ0FfSkVJTElOSiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9KTDIw MDVCQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfS0lORUNUIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0dTUENBX0tPTklDQSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BD QV9NQVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX01SOTczMTBBIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX05XODBYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dT UENBX09WNTE5IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX09WNTM0IGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX09WNTM0XzkgaXMgbm90IHNldAojIENPTkZJR19VU0Jf R1NQQ0FfUEFDMjA3IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1BBQzczMDIgaXMg bm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfUEFDNzMxMSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9HU1BDQV9TRTQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TTjlDMjAy OCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TTjlDMjBYIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX0dTUENBX1NPTklYQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9T T05JWEogaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTUwMCBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dT UENBX1NQQ0E1MDUgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTUwNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTA4IGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX1NQQ0E1NjEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTE1 MjggaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1E5MDUgaXMgbm90IHNldAojIENP TkZJR19VU0JfR1NQQ0FfU1E5MDVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NR OTMwWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TVEswMTQgaXMgbm90IHNldAoj IENPTkZJR19VU0JfR1NQQ0FfU1RLMTEzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BD QV9TVFYwNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NVTlBMVVMgaXMgbm90 IHNldAojIENPTkZJR19VU0JfR1NQQ0FfVDYxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9H U1BDQV9UT1BSTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9UVjg1MzIgaXMgbm90 IHNldAojIENPTkZJR19VU0JfR1NQQ0FfVkMwMzJYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0dTUENBX1ZJQ0FNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1hJUkxJTktfQ0lU IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1pDM1hYIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1BXQyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NQSUEyIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1pSMzY0WFggaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RLV0VCQ0FN IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1MyMjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVVNCVFYgaXMgbm90IHNldAoKIwojIFdlYmNhbSwgVFYgKGFuYWxvZy9kaWdpdGFsKSBV U0IgZGV2aWNlcwojCiMgQ09ORklHX1ZJREVPX0VNMjhYWCBpcyBub3Qgc2V0CiMgQ09ORklH X01FRElBX1BDSV9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX1Y0TF9QTEFURk9STV9EUklW RVJTPXkKIyBDT05GSUdfVklERU9fQ0FGRV9DQ0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVElNQkVSREFMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NPQ19DQU1FUkEgaXMgbm90IHNl dApDT05GSUdfVklERU9fVElfVklQPW0KQ09ORklHX1Y0TF9NRU0yTUVNX0RSSVZFUlM9eQoj IENPTkZJR19WSURFT19NRU0yTUVNX0RFSU5URVJMQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdf VklERU9fU0hfVkVVIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUkVORVNBU19WU1AxIGlz IG5vdCBzZXQKQ09ORklHX1ZJREVPX1RJX1ZQRT1tCiMgQ09ORklHX1ZJREVPX1RJX1ZQRV9E RUJVRyBpcyBub3Qgc2V0CkNPTkZJR19WSURFT19USV9WUERNQV9IRUxQRVI9bQojIENPTkZJ R19WSURFT19USV9WUERNQV9MT0FEX0ZXIGlzIG5vdCBzZXQKIyBDT05GSUdfVjRMX1RFU1Rf RFJJVkVSUyBpcyBub3Qgc2V0CgojCiMgU3VwcG9ydGVkIE1NQy9TRElPIGFkYXB0ZXJzCiMK Q09ORklHX1JBRElPX0FEQVBURVJTPXkKIyBDT05GSUdfUkFESU9fU0k0NzBYIGlzIG5vdCBz ZXQKQ09ORklHX0RSQTdYWF9SQURJT19IRUxQRVI9eQojIENPTkZJR19SQURJT19TSTQ3MTMg aXMgbm90IHNldAojIENPTkZJR19VU0JfTVI4MDAgaXMgbm90IHNldAojIENPTkZJR19VU0Jf RFNCUiBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX01BWElSQURJTyBpcyBub3Qgc2V0CiMg Q09ORklHX1JBRElPX1NIQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fU0hBUksyIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0tFRU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JB UkVNT05PIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01BOTAxIGlzIG5vdCBzZXQKIyBDT05G SUdfUkFESU9fVEVBNTc2NCBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX1NBQTc3MDZIIGlz IG5vdCBzZXQKIyBDT05GSUdfUkFESU9fVEVGNjg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JB RElPX1dMMTI3MyBpcyBub3Qgc2V0CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgV0wxMjh4IEZN IGRyaXZlciAoU1QgYmFzZWQpCiMKIyBDT05GSUdfUkFESU9fV0wxMjhYIGlzIG5vdCBzZXQK IyBDT05GSUdfQ1lQUkVTU19GSVJNV0FSRSBpcyBub3Qgc2V0CgojCiMgTWVkaWEgYW5jaWxs YXJ5IGRyaXZlcnMgKHR1bmVycywgc2Vuc29ycywgaTJjLCBmcm9udGVuZHMpCiMKIyBDT05G SUdfTUVESUFfU1VCRFJWX0FVVE9TRUxFQ1QgaXMgbm90IHNldApDT05GSUdfTUVESUFfQVRU QUNIPXkKCiMKIyBFbmNvZGVycywgZGVjb2RlcnMsIHNlbnNvcnMgYW5kIG90aGVyIGhlbHBl ciBjaGlwcwojCgojCiMgQXVkaW8gZGVjb2RlcnMsIHByb2Nlc3NvcnMgYW5kIG1peGVycwoj CiMgQ09ORklHX1ZJREVPX1RWQVVESU8gaXMgbm90IHNldAojIENPTkZJR19WSURFT19UREE3 NDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVERBOTg0MCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1RFQTY0MTVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVEVBNjQyMCBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01TUDM0MDAgaXMgbm90IHNldAojIENPTkZJR19W SURFT19DUzUzNDUgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DUzUzTDMyQSBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX1RMVjMyMEFJQzIzQiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX1VEQTEzNDIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19XTTg3NzUgaXMgbm90IHNl dAojIENPTkZJR19WSURFT19XTTg3MzkgaXMgbm90IHNldAojIENPTkZJR19WSURFT19WUDI3 U01QWCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NPTllfQlRGX01QWCBpcyBub3Qgc2V0 CgojCiMgUkRTIGRlY29kZXJzCiMKIyBDT05GSUdfVklERU9fU0FBNjU4OCBpcyBub3Qgc2V0 CgojCiMgVmlkZW8gZGVjb2RlcnMKIwojIENPTkZJR19WSURFT19BRFY3MTgwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fQURWNzE4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0FE Vjc2MDQgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BRFY3ODQyIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fQlQ4MTkgaXMgbm90IHNldAojIENPTkZJR19WSURFT19CVDg1NiBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX0JUODY2IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f S1MwMTI3IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTUw4NlY3NjY3IGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fU0FBNzExMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NBQTcx MVggaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTkxIGlzIG5vdCBzZXQKIyBDT05G SUdfVklERU9fVFZQNTE0WCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RWUDUxNTAgaXMg bm90IHNldAojIENPTkZJR19WSURFT19UVlA3MDAyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVFcyODA0IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVFc5OTAzIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fVFc5OTA2IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVlBYMzIy MCBpcyBub3Qgc2V0CgojCiMgVmlkZW8gYW5kIGF1ZGlvIGRlY29kZXJzCiMKIyBDT05GSUdf VklERU9fU0FBNzE3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NYMjU4NDAgaXMgbm90 IHNldAoKIwojIFZpZGVvIGVuY29kZXJzCiMKIyBDT05GSUdfVklERU9fU0FBNzEyNyBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NBQTcxODUgaXMgbm90IHNldAojIENPTkZJR19WSURF T19BRFY3MTcwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzE3NSBpcyBub3Qgc2V0 CiMgQ09ORklHX1ZJREVPX0FEVjczNDMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BRFY3 MzkzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzUxMSBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX0FEOTM4OUIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BSzg4MVggaXMg bm90IHNldAojIENPTkZJR19WSURFT19USFM4MjAwIGlzIG5vdCBzZXQKCiMKIyBDYW1lcmEg c2Vuc29yIGRldmljZXMKIwpDT05GSUdfVklERU9fT1YyNjU5PW0KIyBDT05GSUdfVklERU9f T1Y3NjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y3NjcwIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fT1Y5NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVlM2NjI0IGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fTVQ5TTAzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX01UOVAwMzEgaXMgbm90IHNldAojIENPTkZJR19WSURFT19NVDlUMDAxIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fTVQ5VjAxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01U OVYwMzIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19TUjAzMFBDMzAgaXMgbm90IHNldAoj IENPTkZJR19WSURFT19OT09OMDEwUEMzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX001 TU9MUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1M1SzZBQSBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1M1SzRFQ0dYIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUzVLNUJBRiBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NNSUFQUCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX1M1QzczTTMgaXMgbm90IHNldAoKIwojIEZsYXNoIGRldmljZXMKIwojIENPTkZJR19W SURFT19BRFAxNjUzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQVMzNjQ1QSBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX0xNMzU2MCBpcyBub3Qgc2V0CgojCiMgVmlkZW8gaW1wcm92 ZW1lbnQgY2hpcHMKIwojIENPTkZJR19WSURFT19VUEQ2NDAzMUEgaXMgbm90IHNldAojIENP TkZJR19WSURFT19VUEQ2NDA4MyBpcyBub3Qgc2V0CgojCiMgQXVkaW8vVmlkZW8gY29tcHJl c3Npb24gY2hpcHMKIwojIENPTkZJR19WSURFT19TQUE2NzUySFMgaXMgbm90IHNldAoKIwoj IE1pc2NlbGxhbmVvdXMgaGVscGVyIGNoaXBzCiMKIyBDT05GSUdfVklERU9fVEhTNzMwMyBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX001Mjc5MCBpcyBub3Qgc2V0CgojCiMgU2Vuc29y cyB1c2VkIG9uIHNvY19jYW1lcmEgZHJpdmVyCiMKQ09ORklHX01FRElBX1RVTkVSPXkKCiMK IyBDdXN0b21pemUgVFYgdHVuZXJzCiMKQ09ORklHX01FRElBX1RVTkVSX1NJTVBMRT1tCkNP TkZJR19NRURJQV9UVU5FUl9UREE4MjkwPW0KQ09ORklHX01FRElBX1RVTkVSX1REQTgyN1g9 bQpDT05GSUdfTUVESUFfVFVORVJfVERBMTgyNzE9bQpDT05GSUdfTUVESUFfVFVORVJfVERB OTg4Nz1tCkNPTkZJR19NRURJQV9UVU5FUl9URUE1NzYxPW0KQ09ORklHX01FRElBX1RVTkVS X1RFQTU3Njc9bQpDT05GSUdfTUVESUFfVFVORVJfTVQyMFhYPW0KQ09ORklHX01FRElBX1RV TkVSX01UMjA2MD1tCkNPTkZJR19NRURJQV9UVU5FUl9NVDIwNjM9bQpDT05GSUdfTUVESUFf VFVORVJfTVQyMjY2PW0KQ09ORklHX01FRElBX1RVTkVSX01UMjEzMT1tCkNPTkZJR19NRURJ QV9UVU5FUl9RVDEwMTA9bQpDT05GSUdfTUVESUFfVFVORVJfWEMyMDI4PW0KQ09ORklHX01F RElBX1RVTkVSX1hDNTAwMD1tCkNPTkZJR19NRURJQV9UVU5FUl9YQzQwMDA9bQpDT05GSUdf TUVESUFfVFVORVJfTVhMNTAwNVM9bQpDT05GSUdfTUVESUFfVFVORVJfTVhMNTAwN1Q9bQpD T05GSUdfTUVESUFfVFVORVJfTUM0NFM4MDM9bQpDT05GSUdfTUVESUFfVFVORVJfTUFYMjE2 NT1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODIxOD1tCkNPTkZJR19NRURJQV9UVU5FUl9G QzAwMTE9bQpDT05GSUdfTUVESUFfVFVORVJfRkMwMDEyPW0KQ09ORklHX01FRElBX1RVTkVS X0ZDMDAxMz1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODIxMj1tCkNPTkZJR19NRURJQV9U VU5FUl9FNDAwMD1tCkNPTkZJR19NRURJQV9UVU5FUl9GQzI1ODA9bQpDT05GSUdfTUVESUFf VFVORVJfTTg4VFMyMDIyPW0KQ09ORklHX01FRElBX1RVTkVSX1RVQTkwMDE9bQpDT05GSUdf TUVESUFfVFVORVJfSVQ5MTNYPW0KQ09ORklHX01FRElBX1RVTkVSX1I4MjBUPW0KCiMKIyBD dXN0b21pc2UgRFZCIEZyb250ZW5kcwojCkNPTkZJR19EVkJfQVU4NTIyPW0KQ09ORklHX0RW Ql9BVTg1MjJfVjRMPW0KQ09ORklHX0RWQl9UVU5FUl9ESUIwMDcwPW0KQ09ORklHX0RWQl9U VU5FUl9ESUIwMDkwPW0KCiMKIyBUb29scyB0byBkZXZlbG9wIG5ldyBmcm9udGVuZHMKIwoj IENPTkZJR19EVkJfRFVNTVlfRkUgaXMgbm90IHNldAoKIwojIEdyYXBoaWNzIHN1cHBvcnQK IwpDT05GSUdfVkdBX0FSQj15CkNPTkZJR19WR0FfQVJCX01BWF9HUFVTPTE2CgojCiMgRGly ZWN0IFJlbmRlcmluZyBNYW5hZ2VyCiMKQ09ORklHX0RSTT15CkNPTkZJR19EUk1fS01TX0hF TFBFUj15CkNPTkZJR19EUk1fS01TX0ZCX0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FEX0VE SURfRklSTVdBUkUgaXMgbm90IHNldApDT05GSUdfRFJNX0dFTV9DTUFfSEVMUEVSPXkKQ09O RklHX0RSTV9LTVNfQ01BX0hFTFBFUj15CgojCiMgSTJDIGVuY29kZXIgb3IgaGVscGVyIGNo aXBzCiMKIyBDT05GSUdfRFJNX0kyQ19DSDcwMDYgaXMgbm90IHNldAojIENPTkZJR19EUk1f STJDX1NJTDE2NCBpcyBub3Qgc2V0CkNPTkZJR19EUk1fSTJDX05YUF9UREE5OThYPXkKIyBD T05GSUdfRFJNX1RERlggaXMgbm90IHNldAojIENPTkZJR19EUk1fUjEyOCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RSTV9SQURFT04gaXMgbm90IHNldAojIENPTkZJR19EUk1fTk9VVkVBVSBp cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9NR0EgaXMgbm90IHNldAojIENPTkZJR19EUk1fVklB IGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1NBVkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RS TV9FWFlOT1MgaXMgbm90IHNldAojIENPTkZJR19EUk1fVk1XR0ZYIGlzIG5vdCBzZXQKIyBD T05GSUdfRFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BU1QgaXMgbm90IHNldAoj IENPTkZJR19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9DSVJSVVNfUUVN VSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BUk1BREEgaXMgbm90IHNldAojIENPTkZJR19E Uk1fUkNBUl9EVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TSE1PQklMRSBpcyBub3Qgc2V0 CkNPTkZJR19EUk1fT01BUD15CkNPTkZJR19EUk1fT01BUF9OVU1fQ1JUQ1M9MgpDT05GSUdf RFJNX1RJTENEQz15CiMgQ09ORklHX0RSTV9RWEwgaXMgbm90IHNldAojIENPTkZJR19EUk1f Qk9DSFMgaXMgbm90IHNldAoKIwojIEZyYW1lIGJ1ZmZlciBEZXZpY2VzCiMKQ09ORklHX0ZC PXkKQ09ORklHX0ZJUk1XQVJFX0VESUQ9eQojIENPTkZJR19GQl9EREMgaXMgbm90IHNldAoj IENPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NG Ql9GSUxMUkVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NGQl9DT1BZQVJFQSBpcyBub3Qg c2V0CiMgQ09ORklHX0ZCX0NGQl9JTUFHRUJMSVQgaXMgbm90IHNldAojIENPTkZJR19GQl9D RkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVD VD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05GSUdfRkJfU1lTX0lNQUdFQkxJVD15 CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19G T1BTPXkKQ09ORklHX0ZCX0RFRkVSUkVEX0lPPXkKIyBDT05GSUdfRkJfU1ZHQUxJQiBpcyBu b3Qgc2V0CiMgQ09ORklHX0ZCX01BQ01PREVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQkFD S0xJR0hUIGlzIG5vdCBzZXQKQ09ORklHX0ZCX01PREVfSEVMUEVSUz15CkNPTkZJR19GQl9U SUxFQkxJVFRJTkc9eQoKIwojIEZyYW1lIGJ1ZmZlciBoYXJkd2FyZSBkcml2ZXJzCiMKIyBD T05GSUdfRkJfQ0lSUlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0yIGlzIG5vdCBzZXQK IyBDT05GSUdfRkJfQ1lCRVIyMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVNJTElBTlQg aXMgbm90IHNldAojIENPTkZJR19GQl9JTVNUVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VW RVNBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfT1BFTkNPUkVTIGlzIG5vdCBzZXQKIyBDT05G SUdfRkJfUzFEMTNYWFggaXMgbm90IHNldAojIENPTkZJR19GQl9OVklESUEgaXMgbm90IHNl dAojIENPTkZJR19GQl9SSVZBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSTc0MCBpcyBub3Qg c2V0CiMgQ09ORklHX0ZCX01BVFJPWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1JBREVPTiBp cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FUWTEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FU WSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MzIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0FW QUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf TkVPTUFHSUMgaXMgbm90IHNldAojIENPTkZJR19GQl9LWVJPIGlzIG5vdCBzZXQKIyBDT05G SUdfRkJfM0RGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZPT0RPTzEgaXMgbm90IHNldAoj IENPTkZJR19GQl9WVDg2MjMgaXMgbm90IHNldAojIENPTkZJR19GQl9UUklERU5UIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0zIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ0FSTUlORSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RNSU8g aXMgbm90IHNldAojIENPTkZJR19GQl9TTVNDVUZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf VURMIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR09MREZJU0ggaXMgbm90IHNldAojIENPTkZJ R19GQl9WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CiMg Q09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMg bm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf QVVPX0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lNUExFIGlzIG5vdCBzZXQKQ09O RklHX09NQVAyX0RTU19JTklUPXkKQ09ORklHX09NQVAyX0RTUz15CiMgQ09ORklHX09NQVAy X0RTU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX09NQVAyX0RTU19ERUJVR0ZTIGlzIG5v dCBzZXQKQ09ORklHX09NQVAyX0RTU19EUEk9eQpDT05GSUdfT01BUDJfRFNTX1ZFTkM9eQpD T05GSUdfT01BUDJfRFNTX0hETUlfQ09NTU9OPXkKQ09ORklHX09NQVBfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDRfRFNTX0hETUk9eQpDT05GSUdfT01BUDRfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDVfRFNTX0hETUk9eQpDT05GSUdfT01BUDVfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDJfRFNTX1NEST15CkNPTkZJR19PTUFQMl9EU1NfRFNJPXkKQ09O RklHX09NQVAyX0RTU19NSU5fRkNLX1BFUl9QQ0s9MApDT05GSUdfT01BUDJfRFNTX1NMRUVQ X0FGVEVSX1ZFTkNfUkVTRVQ9eQoKIwojIE9NQVAgRGlzcGxheSBEZXZpY2UgRHJpdmVycyAo bmV3IGRldmljZSBtb2RlbCkKIwpDT05GSUdfRElTUExBWV9FTkNPREVSX1RGUDQxMD1tCkNP TkZJR19ESVNQTEFZX0VOQ09ERVJfVFBEMTJTMDE1PXkKQ09ORklHX0RJU1BMQVlfRFJBN0VW TV9FTkNPREVSX1RQRDEyUzAxNT15CkNPTkZJR19ESVNQTEFZX0VOQ09ERVJfU0lJOTAyMj15 CkNPTkZJR19ESVNQTEFZX0VOQ09ERVJfU0lJOTAyMl9BVURJT19DT0RFQz15CkNPTkZJR19E SVNQTEFZX0NPTk5FQ1RPUl9EVkk9bQpDT05GSUdfRElTUExBWV9DT05ORUNUT1JfSERNST15 CiMgQ09ORklHX0RJU1BMQVlfQ09OTkVDVE9SX0FOQUxPR19UViBpcyBub3Qgc2V0CkNPTkZJ R19ESVNQTEFZX1BBTkVMX0RQST15CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfRFNJX0NNIGlz IG5vdCBzZXQKIyBDT05GSUdfRElTUExBWV9QQU5FTF9TT05ZX0FDWDU2NUFLTSBpcyBub3Qg c2V0CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfTEdQSElMSVBTX0xCMDM1UTAyIGlzIG5vdCBz ZXQKIyBDT05GSUdfRElTUExBWV9QQU5FTF9TSEFSUF9MUzAzN1Y3RFcwMSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfVFBPX1REMDI4VFRFQzEgaXMgbm90IHNldAojIENP TkZJR19ESVNQTEFZX1BBTkVMX1RQT19URDA0M01URUExIGlzIG5vdCBzZXQKIyBDT05GSUdf RElTUExBWV9QQU5FTF9ORUNfTkw4MDQ4SEwxMSBpcyBub3Qgc2V0CkNPTkZJR19ESVNQTEFZ X1BBTkVMX1RMQzU5MTA4PXkKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBzZXQKIyBD T05GSUdfRkJfU1NEMTMwNyBpcyBub3Qgc2V0CkNPTkZJR19CQUNLTElHSFRfTENEX1NVUFBP UlQ9eQpDT05GSUdfTENEX0NMQVNTX0RFVklDRT15CiMgQ09ORklHX0xDRF9MNEYwMDI0MlQw MyBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9MTVMyODNHRjA1IGlzIG5vdCBzZXQKIyBDT05G SUdfTENEX0xUVjM1MFFWIGlzIG5vdCBzZXQKIyBDT05GSUdfTENEX0lMSTkyMlggaXMgbm90 IHNldAojIENPTkZJR19MQ0RfSUxJOTMyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9URE8y NE0gaXMgbm90IHNldAojIENPTkZJR19MQ0RfVkdHMjQzMkE0IGlzIG5vdCBzZXQKQ09ORklH X0xDRF9QTEFURk9STT15CiMgQ09ORklHX0xDRF9TNkU2M00wIGlzIG5vdCBzZXQKIyBDT05G SUdfTENEX0xEOTA0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9BTVMzNjlGRzA2IGlzIG5v dCBzZXQKIyBDT05GSUdfTENEX0xNUzUwMUtGMDMgaXMgbm90IHNldAojIENPTkZJR19MQ0Rf SFg4MzU3IGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9DTEFTU19ERVZJQ0U9eQpDT05G SUdfQkFDS0xJR0hUX0dFTkVSSUM9eQpDT05GSUdfQkFDS0xJR0hUX1BXTT15CiMgQ09ORklH X0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FEUDg4 NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjMwQSBpcyBub3Qgc2V0CiMg Q09ORklHX0JBQ0tMSUdIVF9MTTM2MzkgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRf TFA4NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1RQUzY1MjE3IGlzIG5vdCBz ZXQKQ09ORklHX0JBQ0tMSUdIVF9HUElPPXkKIyBDT05GSUdfQkFDS0xJR0hUX0xWNTIwN0xQ IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0JENjEwNyBpcyBub3Qgc2V0CiMgQ09O RklHX1ZHQVNUQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1VUUFVUX0NPTlRST0wg aXMgbm90IHNldApDT05GSUdfVklERU9NT0RFX0hFTFBFUlM9eQpDT05GSUdfSERNST15Cgoj CiMgQ29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX0RVTU1ZX0NPTlNP TEU9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRT15CkNPTkZJR19GUkFNRUJVRkZFUl9D T05TT0xFX0RFVEVDVF9QUklNQVJZPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEVfUk9U QVRJT049eQpDT05GSUdfTE9HTz15CkNPTkZJR19MT0dPX0xJTlVYX01PTk89eQpDT05GSUdf TE9HT19MSU5VWF9WR0ExNj15CkNPTkZJR19MT0dPX0xJTlVYX0NMVVQyMjQ9eQpDT05GSUdf U09VTkQ9eQpDT05GSUdfU09VTkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVf UFJFQ0xBSU09eQpDT05GSUdfU05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRf UENNPXkKQ09ORklHX1NORF9ETUFFTkdJTkVfUENNPXkKQ09ORklHX1NORF9IV0RFUD1tCkNP TkZJR19TTkRfUkFXTUlEST1tCkNPTkZJR19TTkRfQ09NUFJFU1NfT0ZGTE9BRD15CkNPTkZJ R19TTkRfSkFDSz15CiMgQ09ORklHX1NORF9TRVFVRU5DRVIgaXMgbm90IHNldApDT05GSUdf U05EX09TU0VNVUw9eQpDT05GSUdfU05EX01JWEVSX09TUz1tCkNPTkZJR19TTkRfUENNX09T Uz1tCkNPTkZJR19TTkRfUENNX09TU19QTFVHSU5TPXkKIyBDT05GSUdfU05EX0hSVElNRVIg aXMgbm90IHNldAojIENPTkZJR19TTkRfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldApDT05G SUdfU05EX1NVUFBPUlRfT0xEX0FQST15CkNPTkZJR19TTkRfVkVSQk9TRV9QUk9DRlM9eQpD T05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLPXkKQ09ORklHX1NORF9ERUJVRz15CiMgQ09ORklH X1NORF9ERUJVR19WRVJCT1NFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1BDTV9YUlVOX0RF QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JBV01JRElfU0VRIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX09QTDNfTElCX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9PUEw0X0xJ Ql9TRVEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0JBV0VfU0VRIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0VNVTEwSzFfU0VRIGlzIG5vdCBzZXQKQ09ORklHX1NORF9EUklWRVJTPXkK IyBDT05GSUdfU05EX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FMT09QIGlzIG5v dCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NFUklB TF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBVNDAxIGlzIG5vdCBzZXQKQ09O RklHX1NORF9QQ0k9eQojIENPTkZJR19TTkRfQUQxODg5IGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX0FMUzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTEk1NDUxIGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVElJWFBfTU9E RU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODEwIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX0FVODgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVTg4MzAgaXMgbm90IHNldAoj IENPTkZJR19TTkRfQVcyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FaVDMzMjggaXMgbm90 IHNldAojIENPTkZJR19TTkRfQlQ4N1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfQ0EwMTA2 IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NNSVBDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9PWFlHRU4gaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1M0MjgxIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0NTNDZYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzVBVURJTyBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9DVFhGSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E QVJMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9MQVlMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0RBUkxBMjQgaXMgbm90 IHNldAojIENPTkZJR19TTkRfR0lOQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xBWUxB MjQgaXMgbm90IHNldAojIENPTkZJR19TTkRfTU9OQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9NSUEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRUNITzNHIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX0lORElHTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJR09JTyBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9JTkRJR09ESiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJ R09JT1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPREpYIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0VNVTEwSzEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMVggaXMg bm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9F TlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VTMTkzOCBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNl dAojIENPTkZJR19TTkRfSERBX0lOVEVMIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEU1Ag aXMgbm90IHNldAojIENPTkZJR19TTkRfSERTUE0gaXMgbm90IHNldAojIENPTkZJR19TTkRf SUNFMTcxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0lOVEVMOFgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lOVEVMOFgwTSBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9LT1JHMTIxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9MT0xBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xYNjQ2NEVTIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX01BRVNUUk8zIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9OTTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9QQ1hI UiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9SSVBUSURFIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX1JNRTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTk2IGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX1JNRTk2NTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9UUklERU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1ZJQTgyWFggaXMgbm90IHNldAojIENPTkZJR19TTkRfVklBODJYWF9NT0RFTSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9WSVJUVU9TTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WWDIy MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9ZTUZQQ0kgaXMgbm90IHNldApDT05GSUdfU05E X0FSTT15CkNPTkZJR19TTkRfU1BJPXkKQ09ORklHX1NORF9VU0I9eQpDT05GSUdfU05EX1VT Ql9BVURJTz1tCiMgQ09ORklHX1NORF9VU0JfVUExMDEgaXMgbm90IHNldAojIENPTkZJR19T TkRfVVNCX0NBSUFRIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1VTQl82RklSRSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9VU0JfSElGQUNFIGlzIG5vdCBzZXQKQ09ORklHX1NORF9TT0M9 eQojIENPTkZJR19TTkRfQVRNRUxfU09DIGlzIG5vdCBzZXQKQ09ORklHX1NORF9EQVZJTkNJ X1NPQ19NQ0FTUD15CkNPTkZJR19TTkRfREFWSU5DSV9TT0NfR0VORVJJQ19FVk09eQojIENP TkZJR19TTkRfREVTSUdOV0FSRV9JMlMgaXMgbm90IHNldApDT05GSUdfU05EX09NQVBfU09D PXkKQ09ORklHX1NORF9PTUFQX1NPQ19IRE1JX0FVRElPPXkKQ09ORklHX1NORF9PTUFQX1NP Q19EUkE3RVZNPXkKQ09ORklHX1NORF9TT0NfSTJDX0FORF9TUEk9eQoKIwojIENPREVDIGRy aXZlcnMKIwojIENPTkZJR19TTkRfU09DX0FEQVUxNzAxIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX1NPQ19BSzQxMDQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FLNDU1NCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQUs0NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NPQ19BSzUzODYgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNTIgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNzMgaXMgbm90IHNldAojIENPTkZJR19TTkRf U09DX0NTNDI3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1M0MjcxIGlzIG5vdCBz ZXQKQ09ORklHX1NORF9TT0NfSERNSV9DT0RFQz15CiMgQ09ORklHX1NORF9TT0NfUENNMTY4 MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfUENNMTc5MkEgaXMgbm90IHNldAojIENP TkZJR19TTkRfU09DX1NHVEw1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TUERJ RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfVEFTNTA4NiBpcyBub3Qgc2V0CkNPTkZJ R19TTkRfU09DX1RMVjMyMEFJQzMxWFg9eQpDT05GSUdfU05EX1NPQ19UTFYzMjBBSUMzWD15 CiMgQ09ORklHX1NORF9TT0NfV004NTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19X TTg1MjMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODU4MCBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfV004NzExIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3 MjggaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODczMSBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9TT0NfV004NzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NDEg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODc1MCBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TT0NfV004NzUzIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NzAgaXMg bm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODc3NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9TT0NfV004ODA0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg5MDMgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX1dNODk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9T T0NfVFBBNjEzMEEyIGlzIG5vdCBzZXQKQ09ORklHX1NORF9TSU1QTEVfQ0FSRD15CiMgQ09O RklHX1NPVU5EX1BSSU1FIGlzIG5vdCBzZXQKCiMKIyBISUQgc3VwcG9ydAojCkNPTkZJR19I SUQ9eQojIENPTkZJR19ISURfQkFUVEVSWV9TVFJFTkdUSCBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRFJBVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VISUQgaXMgbm90IHNldApDT05GSUdfSElE X0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElEIGRyaXZlcnMKIwojIENPTkZJR19ISURfQTRU RUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0FDUlVYIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0FQUExFSVIgaXMgbm90IHNldAoj IENPTkZJR19ISURfQVVSRUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0JFTEtJTiBpcyBu b3Qgc2V0CiMgQ09ORklHX0hJRF9DSEVSUlkgaXMgbm90IHNldAojIENPTkZJR19ISURfQ0hJ Q09OWSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUk9ESUtFWVMgaXMgbm90IHNldAojIENP TkZJR19ISURfQ1lQUkVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlz IG5vdCBzZXQKIyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9F TEVDT00gaXMgbm90IHNldAojIENPTkZJR19ISURfRUxPIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX0VaS0VZIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0hPTFRFSyBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9IVUlPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LRVlUT1VDSCBpcyBu b3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMgbm90IHNldAojIENPTkZJR19ISURfVUNMT0dJ QyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxUT1AgaXMgbm90IHNldAojIENPTkZJR19I SURfR1lSQVRJT04gaXMgbm90IHNldAojIENPTkZJR19ISURfSUNBREUgaXMgbm90IHNldAoj IENPTkZJR19ISURfVFdJTkhBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LRU5TSU5HVE9O IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19I SURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0xPR0lURUNIIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX01BR0lDTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19ISURf TUlDUk9TT0ZUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX01PTlRFUkVZIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX01VTFRJVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19ISURfTlRSSUcg aXMgbm90IHNldAojIENPTkZJR19ISURfT1JURUsgaXMgbm90IHNldAojIENPTkZJR19ISURf UEFOVEhFUkxPUkQgaXMgbm90IHNldAojIENPTkZJR19ISURfUEVUQUxZTlggaXMgbm90IHNl dAojIENPTkZJR19ISURfUElDT0xDRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUklNQVgg aXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1NBSVRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBD T05GSUdfSElEX1NPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX1NURUVMU0VSSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1NVTlBMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfR1JFRU5BU0lBIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX1NNQVJUSk9ZUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USVZP IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RPUFNFRUQgaXMgbm90IHNldAojIENPTkZJR19I SURfVEhJTkdNIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RIUlVTVE1BU1RFUiBpcyBub3Qg c2V0CiMgQ09ORklHX0hJRF9XQUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XSUlNT1RF IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1hJTk1PIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1pFUk9QTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1pZREFDUk9OIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX1NFTlNPUl9IVUIgaXMgbm90IHNldAoKIwojIFVTQiBISUQgc3VwcG9y dAojCkNPTkZJR19VU0JfSElEPXkKIyBDT05GSUdfSElEX1BJRCBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9ISURERVYgaXMgbm90IHNldAoKIwojIEkyQyBISUQgc3VwcG9ydAojCiMgQ09O RklHX0kyQ19ISUQgaXMgbm90IHNldApDT05GSUdfVVNCX09IQ0lfTElUVExFX0VORElBTj15 CkNPTkZJR19VU0JfU1VQUE9SVD15CkNPTkZJR19VU0JfQ09NTU9OPXkKQ09ORklHX0RSRF9M SUI9eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQojIENPTkZJR19V U0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0FOTk9VTkNFX05FV19ERVZJQ0VTPXkK CiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKQ09ORklHX1VTQl9ERUZBVUxUX1BF UlNJU1Q9eQojIENPTkZJR19VU0JfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldAojIENPTkZJ R19VU0JfT1RHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09UR19XSElURUxJU1QgaXMgbm90 IHNldAojIENPTkZJR19VU0JfT1RHX0JMQUNLTElTVF9IVUIgaXMgbm90IHNldApDT05GSUdf VVNCX01PTj15CiMgQ09ORklHX1VTQl9XVVNCX0NCQUYgaXMgbm90IHNldAoKIwojIFVTQiBI b3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1VTQl9DNjdYMDBfSENEIGlzIG5v dCBzZXQKQ09ORklHX1VTQl9YSENJX0hDRD1tCkNPTkZJR19VU0JfWEhDSV9QTEFURk9STT1t CkNPTkZJR19VU0JfRUhDSV9IQ0Q9eQojIENPTkZJR19VU0JfRUhDSV9ST09UX0hVQl9UVCBp cyBub3Qgc2V0CkNPTkZJR19VU0JfRUhDSV9UVF9ORVdTQ0hFRD15CkNPTkZJR19VU0JfRUhD SV9QQ0k9eQpDT05GSUdfVVNCX0VIQ0lfSENEX09NQVA9eQojIENPTkZJR19VU0JfRUhDSV9I Q0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfT1hVMjEwSFBfSENEIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0lTUDExNlhfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0lTUDE3NjBfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lTUDEzNjJfSENEIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0ZVU0JIMjAwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9GT1RHMjEwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PSENJX0hDRCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9VSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TTDgx MV9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0hDRF9URVNUX01PREUgaXMgbm90IHNldAojIENPTkZJR19VU0JfUkVO RVNBU19VU0JIUyBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzCiMK Q09ORklHX1VTQl9BQ009bQpDT05GSUdfVVNCX1BSSU5URVI9bQpDT05GSUdfVVNCX1dETT15 CiMgQ09ORklHX1VTQl9UTUMgaXMgbm90IHNldAoKIwojIE5PVEU6IFVTQl9TVE9SQUdFIGRl cGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkKIwoKIwojIGFsc28gYmUgbmVlZGVk OyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZvCiMKQ09ORklHX1VTQl9TVE9S QUdFPXkKIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19V U0JfU1RPUkFHRV9SRUFMVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfREFU QUZBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNl dAojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAojIENPTkZJR19VU0Jf U1RPUkFHRV9VU0JBVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFIwOSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9TVE9SQUdFX0pVTVBTSE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JB R0VfQUxBVURBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfT05FVE9VQ0ggaXMg bm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9LQVJNQSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TVE9SQUdFX0NZUFJFU1NfQVRBQ0IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RP UkFHRV9FTkVfVUI2MjUwIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBkZXZpY2VzCiMK IyBDT05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NSUNST1RFSyBp cyBub3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9IRFJDPW0KIyBDT05GSUdfVVNCX01VU0JfSE9T VCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NVVNCX0dBREdFVCBpcyBub3Qgc2V0CkNPTkZJ R19VU0JfTVVTQl9EVUFMX1JPTEU9eQojIENPTkZJR19VU0JfTVVTQl9UVVNCNjAxMCBpcyBu b3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9PTUFQMlBMVVM9bQojIENPTkZJR19VU0JfTVVTQl9B TTM1WCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9EU1BTPW0KIyBDT05GSUdfVVNCX01V U0JfVVg1MDAgaXMgbm90IHNldApDT05GSUdfVVNCX01VU0JfQU0zMzVYX0NISUxEPW0KIyBD T05GSUdfVVNCX0lOVkVOVFJBX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfVElfQ1BQSTQx X0RNQT15CiMgQ09ORklHX01VU0JfUElPX09OTFkgaXMgbm90IHNldApDT05GSUdfVVNCX0RX QzM9bQojIENPTkZJR19VU0JfRFdDM19IT1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RX QzNfR0FER0VUIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9EV0MzX0RVQUxfUk9MRT15CgojCiMg UGxhdGZvcm0gR2x1ZSBEcml2ZXIgU3VwcG9ydAojCkNPTkZJR19VU0JfRFdDM19PTUFQPW0K Q09ORklHX1VTQl9EV0MzX1BDST1tCgojCiMgRGVidWdnaW5nIGZlYXR1cmVzCiMKIyBDT05G SUdfVVNCX0RXQzNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19EV0MzX0hPU1RfVVNCM19M UE1fRU5BQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RXQzIgaXMgbm90IHNldAojIENP TkZJR19VU0JfQ0hJUElERUEgaXMgbm90IHNldAoKIwojIFVTQiBwb3J0IGRyaXZlcnMKIwpD T05GSUdfVVNCX1NFUklBTD1tCiMgQ09ORklHX1VTQl9TRVJJQUxfR0VORVJJQyBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU0lNUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9BSVJDQUJMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfQVJLMzEx NiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfQkVMS0lOIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9DSDM0MSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxf V0hJVEVIRUFUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9ESUdJX0FDQ0VMRVBP UlQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0NQMjEwWCBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TRVJJQUxfQ1lQUkVTU19NOCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfRU1QRUcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0ZURElfU0lPIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9WSVNPUiBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfSVBBUSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfSVIgaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0VER0VQT1JUIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NFUklBTF9FREdFUE9SVF9USSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ QUxfRjgxMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9HQVJNSU4gaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lQVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfSVVVIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1BEQSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTiBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9TRVJJQUxfS0xTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfS09C SUxfU0NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9NQ1RfVTIzMiBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfTUVUUk8gaXMgbm90IHNldAojIENPTkZJR19VU0Jf U0VSSUFMX01PUzc3MjAgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01PUzc4NDAg aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01YVVBPUlQgaXMgbm90IHNldAojIENP TkZJR19VU0JfU0VSSUFMX05BVk1BTiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX1BM MjMwMz1tCiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OCBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1FVQUxD T01NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1IGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklB TF9TSUVSUkFXSVJFTEVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU1lNQk9M IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9USSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfQ1lCRVJKQUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9Y SVJDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX09QVElPTiBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9TRVJJQUxfT01OSU5FVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfT1BUSUNPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWFNFTlNfTVQg aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1dJU0hCT05FIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9aVEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NT VTEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfUVQyIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9ERUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVv dXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENP TkZJR19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENE IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9D WVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9F TEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMgbm90 IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJR19V U0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9URVNUPW0KIyBDT05GSUdfVVNC X0VIU0VUX1RFU1RfRklYVFVSRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU0lHSFRGVyBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJFWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9F WlVTQl9GWDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfSFNJQ19VU0IzNTAzIGlzIG5vdCBz ZXQKCiMKIyBVU0IgUGh5c2ljYWwgTGF5ZXIgZHJpdmVycwojCkNPTkZJR19VU0JfUEhZPXkK IyBDT05GSUdfVVNCX09UR19GU00gaXMgbm90IHNldAojIENPTkZJR19VU0JfT1RHX1dBS0VM T0NLIGlzIG5vdCBzZXQKQ09ORklHX05PUF9VU0JfWENFSVY9eQpDT05GSUdfQU0zMzVYX0NP TlRST0xfVVNCPXkKQ09ORklHX0FNMzM1WF9QSFlfVVNCPXkKIyBDT05GSUdfU0FNU1VOR19V U0IyUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNU1VOR19VU0IzUEhZIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0dQSU9fVkJVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzAx IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JDQVJfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1VMUEkgaXMgbm90IHNldApDT05GSUdfVVNCX0dBREdFVD15CkNPTkZJR19VU0JfR0FE R0VUX0RFQlVHPXkKIyBDT05GSUdfVVNCX0dBREdFVF9WRVJCT1NFIGlzIG5vdCBzZXQKQ09O RklHX1VTQl9HQURHRVRfREVCVUdfRklMRVM9eQpDT05GSUdfVVNCX0dBREdFVF9ERUJVR19G Uz15CkNPTkZJR19VU0JfR0FER0VUX1ZCVVNfRFJBVz0yCkNPTkZJR19VU0JfR0FER0VUX1NU T1JBR0VfTlVNX0JVRkZFUlM9MgoKIwojIFVTQiBQZXJpcGhlcmFsIENvbnRyb2xsZXIKIwoj IENPTkZJR19VU0JfRk9URzIxMF9VREMgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1JfVURD IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1I4QTY2NTk3IGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1BYQTI3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TM0NfSFNPVEcgaXMgbm90IHNl dAojIENPTkZJR19VU0JfTVZfVURDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01WX1UzRCBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NNjY1OTIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf QU1ENTUzNlVEQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVQyMjcyIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX05FVDIyODAgaXMgbm90IHNldAojIENPTkZJR19VU0JfR09LVSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9FRzIwVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EVU1N WV9IQ0QgaXMgbm90IHNldApDT05GSUdfVVNCX0xJQkNPTVBPU0lURT1tCkNPTkZJR19VU0Jf Rl9BQ009bQpDT05GSUdfVVNCX0ZfU1NfTEI9bQpDT05GSUdfVVNCX1VfU0VSSUFMPW0KQ09O RklHX1VTQl9VX0VUSEVSPW0KQ09ORklHX1VTQl9GX1NFUklBTD1tCkNPTkZJR19VU0JfRl9P QkVYPW0KQ09ORklHX1VTQl9GX05DTT1tCkNPTkZJR19VU0JfRl9FQ009bQpDT05GSUdfVVNC X0ZfU1VCU0VUPW0KQ09ORklHX1VTQl9GX1JORElTPW0KQ09ORklHX1VTQl9GX01BU1NfU1RP UkFHRT1tCkNPTkZJR19VU0JfRl9GUz1tCiMgQ09ORklHX1VTQl9DT05GSUdGUyBpcyBub3Qg c2V0CkNPTkZJR19VU0JfWkVSTz1tCkNPTkZJR19VU0JfQVVESU89bQojIENPTkZJR19HQURH RVRfVUFDMSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfRVRIPW0KQ09ORklHX1VTQl9FVEhfUk5E SVM9eQojIENPTkZJR19VU0JfRVRIX0VFTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfR19OQ009 bQpDT05GSUdfVVNCX0dBREdFVEZTPW0KQ09ORklHX1VTQl9GVU5DVElPTkZTPW0KQ09ORklH X1VTQl9GVU5DVElPTkZTX0VUSD15CkNPTkZJR19VU0JfRlVOQ1RJT05GU19STkRJUz15CkNP TkZJR19VU0JfRlVOQ1RJT05GU19HRU5FUklDPXkKQ09ORklHX1VTQl9NQVNTX1NUT1JBR0U9 bQpDT05GSUdfVVNCX0dfU0VSSUFMPW0KQ09ORklHX1VTQl9NSURJX0dBREdFVD1tCkNPTkZJ R19VU0JfR19QUklOVEVSPW0KQ09ORklHX1VTQl9DRENfQ09NUE9TSVRFPW0KQ09ORklHX1VT Ql9HX0FDTV9NUz1tCkNPTkZJR19VU0JfR19NVUxUST1tCkNPTkZJR19VU0JfR19NVUxUSV9S TkRJUz15CkNPTkZJR19VU0JfR19NVUxUSV9DREM9eQpDT05GSUdfVVNCX0dfSElEPW0KQ09O RklHX1VTQl9HX0RCR1A9bQojIENPTkZJR19VU0JfR19EQkdQX1BSSU5USyBpcyBub3Qgc2V0 CkNPTkZJR19VU0JfR19EQkdQX1NFUklBTD15CkNPTkZJR19VU0JfR19XRUJDQU09bQojIENP TkZJR19VV0IgaXMgbm90IHNldApDT05GSUdfTU1DPXkKIyBDT05GSUdfTU1DX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX01NQ19VTlNBRkVfUkVTVU1FPXkKIyBDT05GSUdfTU1DX0NMS0dB VEUgaXMgbm90IHNldAojIENPTkZJR19NTUNfRU1CRURERURfU0RJTyBpcyBub3Qgc2V0CiMg Q09ORklHX01NQ19QQVJBTk9JRF9TRF9JTklUIGlzIG5vdCBzZXQKCiMKIyBNTUMvU0QvU0RJ TyBDYXJkIERyaXZlcnMKIwpDT05GSUdfTU1DX0JMT0NLPXkKQ09ORklHX01NQ19CTE9DS19N SU5PUlM9OApDT05GSUdfTU1DX0JMT0NLX0JPVU5DRT15CiMgQ09ORklHX01NQ19CTE9DS19E RUZFUlJFRF9SRVNVTUUgaXMgbm90IHNldApDT05GSUdfU0RJT19VQVJUPXkKIyBDT05GSUdf TU1DX1RFU1QgaXMgbm90IHNldAoKIwojIE1NQy9TRC9TRElPIEhvc3QgQ29udHJvbGxlciBE cml2ZXJzCiMKIyBDT05GSUdfTU1DX1NESENJIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1NE SENJX1BYQVYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1NESENJX1BYQVYyIGlzIG5vdCBz ZXQKQ09ORklHX01NQ19PTUFQPXkKQ09ORklHX01NQ19PTUFQX0hTPXkKIyBDT05GSUdfTU1D X1RJRk1fU0QgaXMgbm90IHNldAojIENPTkZJR19NTUNfQ0I3MTAgaXMgbm90IHNldAojIENP TkZJR19NTUNfVklBX1NETU1DIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX0RXIGlzIG5vdCBz ZXQKIyBDT05GSUdfTU1DX1ZVQjMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01NQ19VU0hDIGlz IG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9 eQpDT05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURT X0xNMzUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBD T05GSUdfTEVEU19QQ0E5NTMyIGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfR1BJTz15CiMgQ09O RklHX0xFRFNfTFAzOTQ0IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDU1MjEgaXMgbm90 IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1 NTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDg1MDEgaXMgbm90IHNldAojIENPTkZJ R19MRURTX1BDQTk1NVggaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk2M1ggaXMgbm90 IHNldAojIENPTkZJR19MRURTX1BDQTk2ODUgaXMgbm90IHNldAojIENPTkZJR19MRURTX0RB QzEyNFMwODUgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BXTSBpcyBub3Qgc2V0CiMgQ09O RklHX0xFRFNfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMg bm90IHNldAojIENPTkZJR19MRURTX0xUMzU5MyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNf VENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQKIyBD T05GSUdfTEVEU19PVDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfQkxJTktNIGlzIG5v dCBzZXQKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSUz15CkNPTkZJ R19MRURTX1RSSUdHRVJfVElNRVI9eQpDT05GSUdfTEVEU19UUklHR0VSX09ORVNIT1Q9eQpD T05GSUdfTEVEU19UUklHR0VSX0hFQVJUQkVBVD15CkNPTkZJR19MRURTX1RSSUdHRVJfQkFD S0xJR0hUPXkKQ09ORklHX0xFRFNfVFJJR0dFUl9DUFU9eQpDT05GSUdfTEVEU19UUklHR0VS X0dQSU89eQpDT05GSUdfTEVEU19UUklHR0VSX0RFRkFVTFRfT049eQoKIwojIGlwdGFibGVz IHRyaWdnZXIgaXMgdW5kZXIgTmV0ZmlsdGVyIGNvbmZpZyAoTEVEIHRhcmdldCkKIwpDT05G SUdfTEVEU19UUklHR0VSX1RSQU5TSUVOVD15CkNPTkZJR19MRURTX1RSSUdHRVJfQ0FNRVJB PXkKIyBDT05GSUdfU1dJVENIIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNDRVNTSUJJTElUWSBp cyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkQgaXMgbm90IHNldAojIENPTkZJR19FREFD IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKQ09ORklH X1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19TWVNUT0hDPXkKQ09ORklHX1JUQ19IQ1RPU1lT X0RFVklDRT0icnRjMCIKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMg aW50ZXJmYWNlcwojCkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9Q Uk9DPXkKQ09ORklHX1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVf RU1VTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMg STJDIFJUQyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfRFMxMzA3PXkKIyBDT05GSUdfUlRD X0RSVl9EUzEzNzQgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTY3MiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMzMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9IWU04NTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NQVg2OTAwIGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9SUzVDMzcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9JU0wxMjA4IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9JU0wxMjAyMiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwNTcgaXMgbm90IHNldAojIENPTkZJR19SVENf RFJWX1gxMjA1IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZfUEFMTUFTPXkKIyBDT05GSUdf UlRDX0RSVl9QQ0YyMTI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTIzIGlz IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTYzIGlzIG5vdCBzZXQKIyBDT05GSUdf UlRDX0RSVl9QQ0Y4NTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDFUODAgaXMg bm90IHNldAojIENPTkZJR19SVENfRFJWX0JRMzJLIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9UUFM2NTkxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUzM1MzkwQSBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9SWDg1ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODAyNSBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9SVjMwMjlDMiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdf UlRDX0RSVl9NNDFUOTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000MVQ5NCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9EUzEzOTAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDY5MDIgaXMgbm90 IHNldAojIENPTkZJR19SVENfRFJWX1I5NzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9SUzVDMzQ4IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMyMzQgaXMgbm90IHNl dAojIENPTkZJR19SVENfRFJWX1BDRjIxMjMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW X1JYNDU4MSBpcyBub3Qgc2V0CgojCiMgUGxhdGZvcm0gUlRDIGRyaXZlcnMKIwojIENPTkZJ R19SVENfRFJWX0NNT1MgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTI4NiBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNTExIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9EUzE1NTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTc0MiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfU1RLMTdUQTggaXMgbm90IHNldAojIENPTkZJR19SVENf RFJWX000OFQ4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDM1IGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUNTkgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW X01TTTYyNDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRNDgwMiBpcyBub3Qgc2V0 CiMgQ09ORklHX1JUQ19EUlZfUlA1QzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9W MzAyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMyNDA0IGlzIG5vdCBzZXQKCiMK IyBvbi1DUFUgUlRDIGRyaXZlcnMKIwpDT05GSUdfUlRDX0RSVl9PTUFQPXkKIyBDT05GSUdf UlRDX0RSVl9TTlZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NT1hBUlQgaXMgbm90 IHNldAoKIwojIEhJRCBTZW5zb3IgUlRDIGRyaXZlcnMKIwojIENPTkZJR19SVENfRFJWX0hJ RF9TRU5TT1JfVElNRSBpcyBub3Qgc2V0CkNPTkZJR19ETUFERVZJQ0VTPXkKIyBDT05GSUdf RE1BREVWSUNFU19ERUJVRyBpcyBub3Qgc2V0CgojCiMgRE1BIERldmljZXMKIwojIENPTkZJ R19EV19ETUFDX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19EV19ETUFDIGlzIG5vdCBzZXQK IyBDT05GSUdfRFdfRE1BQ19QQ0kgaXMgbm90IHNldAojIENPTkZJR19USU1CX0RNQSBpcyBu b3Qgc2V0CkNPTkZJR19USV9FRE1BPXkKQ09ORklHX0RNQV9PTUFQPXkKQ09ORklHX1RJX0NQ UEk0MT15CkNPTkZJR19ETUFfRU5HSU5FPXkKQ09ORklHX0RNQV9WSVJUVUFMX0NIQU5ORUxT PXkKQ09ORklHX0RNQV9PRj15CgojCiMgRE1BIENsaWVudHMKIwojIENPTkZJR19BU1lOQ19U WF9ETUEgaXMgbm90IHNldAojIENPTkZJR19ETUFURVNUIGlzIG5vdCBzZXQKQ09ORklHX09N QVBfRE1BX0NST1NTQkFSPXkKIyBDT05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0CiMgQ09O RklHX1VJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZGSU8gaXMgbm90IHNldAojIENPTkZJR19W SVJUX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfVklSVElPPW0KCiMKIyBWaXJ0aW8gZHJp dmVycwojCiMgQ09ORklHX1ZJUlRJT19QQ0kgaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9f QkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRJT19NTUlPIGlzIG5vdCBzZXQKCiMK IyBNaWNyb3NvZnQgSHlwZXItViBndWVzdCBzdXBwb3J0CiMKCiMKIyBYZW4gZHJpdmVyIHN1 cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdfWEVOX1NDUlVCX1BBR0VTPXkK Q09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9CQUNLRU5EPXkKQ09ORklHX1hF TkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05GSUdfWEVOX1NZU19IWVBFUlZJ U09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9eQpDT05GSUdfWEVOX0dOVERFVj15 CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklHX1NXSU9UTEJfWEVOPXkKQ09O RklHX1hFTl9QUklWQ01EPXkKIyBDT05GSUdfU1RBR0lORyBpcyBub3Qgc2V0CkNPTkZJR19D TEtERVZfTE9PS1VQPXkKQ09ORklHX0hBVkVfQ0xLX1BSRVBBUkU9eQpDT05GSUdfQ09NTU9O X0NMSz15CgojCiMgQ29tbW9uIENsb2NrIEZyYW1ld29yawojCiMgQ09ORklHX0NPTU1PTl9D TEtfU0k1MzUxIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NMS19TSTU3MCBpcyBub3Qg c2V0CiMgQ09ORklHX0NMS19UV0w2MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NM S19RQ09NIGlzIG5vdCBzZXQKQ09ORklHX0hXU1BJTkxPQ0s9eQoKIwojIEhhcmR3YXJlIFNw aW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfSFdTUElOTE9DS19PTUFQPXkKQ09ORklHX0NMS1NS Q19PRj15CkNPTkZJR19DTEtTUkNfTU1JTz15CkNPTkZJR19BUk1fQVJDSF9USU1FUj15CkNP TkZJR19BUk1fQVJDSF9USU1FUl9FVlRTVFJFQU09eQpDT05GSUdfTUFJTEJPWD15CkNPTkZJ R19PTUFQMlBMVVNfTUJPWD15CkNPTkZJR19PTUFQX01CT1hfS0ZJRk9fU0laRT0yNTYKQ09O RklHX0lPTU1VX0FQST15CkNPTkZJR19JT01NVV9TVVBQT1JUPXkKQ09ORklHX09GX0lPTU1V PXkKQ09ORklHX09NQVBfSU9NTVU9eQpDT05GSUdfT01BUF9JT1ZNTT15CkNPTkZJR19PTUFQ X0lPTU1VX0RFQlVHPXkKIyBDT05GSUdfQVJNX1NNTVUgaXMgbm90IHNldAoKIwojIFJlbW90 ZXByb2MgZHJpdmVycwojCkNPTkZJR19SRU1PVEVQUk9DPW0KQ09ORklHX09NQVBfUkVNT1RF UFJPQz1tCkNPTkZJR19PTUFQX1JFTU9URVBST0NfV0FUQ0hET0c9eQojIENPTkZJR19TVEVf TU9ERU1fUlBST0MgaXMgbm90IHNldAojIENPTkZJR19QUlVTU19SRU1PVEVQUk9DIGlzIG5v dCBzZXQKCiMKIyBScG1zZyBkcml2ZXJzCiMKQ09ORklHX1JQTVNHPW0KQ09ORklHX1JQTVNH X1JQQz1tCiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNldApDT05GSUdfRVhUQ09OPXkK CiMKIyBFeHRjb24gRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfRVhUQ09OX0dQSU89eQojIENP TkZJR19FWFRDT05fQURDX0pBQ0sgaXMgbm90IHNldApDT05GSUdfRVhUQ09OX1BBTE1BUz15 CiMgQ09ORklHX01FTU9SWSBpcyBub3Qgc2V0CkNPTkZJR19JSU89bQpDT05GSUdfSUlPX0JV RkZFUj15CkNPTkZJR19JSU9fQlVGRkVSX0NCPXkKQ09ORklHX0lJT19LRklGT19CVUY9bQpD T05GSUdfSUlPX1RSSUdHRVI9eQpDT05GSUdfSUlPX0NPTlNVTUVSU19QRVJfVFJJR0dFUj0y CgojCiMgQWNjZWxlcm9tZXRlcnMKIwojIENPTkZJR19CTUExODAgaXMgbm90IHNldAojIENP TkZJR19JSU9fU1RfQUNDRUxfM0FYSVMgaXMgbm90IHNldAojIENPTkZJR19LWFNEOSBpcyBu b3Qgc2V0CgojCiMgQW5hbG9nIHRvIGRpZ2l0YWwgY29udmVydGVycwojCiMgQ09ORklHX0FE NzI2NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzI5OCBpcyBub3Qgc2V0CiMgQ09ORklHX0FE NzQ3NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzc5MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FE Nzc5MyBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzg4NyBpcyBub3Qgc2V0CiMgQ09ORklHX0FE NzkyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0VYWU5PU19BREMgaXMgbm90IHNldAojIENPTkZJ R19NQVgxMzYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNQMzIwWCBpcyBub3Qgc2V0CiMgQ09O RklHX01DUDM0MjIgaXMgbm90IHNldAojIENPTkZJR19OQVU3ODAyIGlzIG5vdCBzZXQKIyBD T05GSUdfVElfQURDMDgxQyBpcyBub3Qgc2V0CkNPTkZJR19USV9BTTMzNVhfQURDPW0KCiMK IyBBbXBsaWZpZXJzCiMKIyBDT05GSUdfQUQ4MzY2IGlzIG5vdCBzZXQKCiMKIyBIaWQgU2Vu c29yIElJTyBDb21tb24KIwoKIwojIERpZ2l0YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKIwoj IENPTkZJR19BRDUwNjQgaXMgbm90IHNldAojIENPTkZJR19BRDUzNjAgaXMgbm90IHNldAoj IENPTkZJR19BRDUzODAgaXMgbm90IHNldAojIENPTkZJR19BRDU0MjEgaXMgbm90IHNldAoj IENPTkZJR19BRDU0NDYgaXMgbm90IHNldAojIENPTkZJR19BRDU0NDkgaXMgbm90IHNldAoj IENPTkZJR19BRDU1MDQgaXMgbm90IHNldAojIENPTkZJR19BRDU2MjRSX1NQSSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENTY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc1NSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENTc2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc5MSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENzMwMyBpcyBub3Qgc2V0CiMgQ09ORklHX01BWDUxNyBpcyBub3Qg c2V0CiMgQ09ORklHX01DUDQ3MjUgaXMgbm90IHNldAoKIwojIEZyZXF1ZW5jeSBTeW50aGVz aXplcnMgRERTL1BMTAojCgojCiMgQ2xvY2sgR2VuZXJhdG9yL0Rpc3RyaWJ1dGlvbgojCiMg Q09ORklHX0FEOTUyMyBpcyBub3Qgc2V0CgojCiMgUGhhc2UtTG9ja2VkIExvb3AgKFBMTCkg ZnJlcXVlbmN5IHN5bnRoZXNpemVycwojCiMgQ09ORklHX0FERjQzNTAgaXMgbm90IHNldAoK IwojIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMKIwojIENPTkZJR19BRElTMTYwODAgaXMg bm90IHNldAojIENPTkZJR19BRElTMTYxMzAgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYx MzYgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYyNjAgaXMgbm90IHNldAojIENPTkZJR19B RFhSUzQ1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9HWVJPXzNBWElTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVRHMzIwMCBpcyBub3Qgc2V0CgojCiMgSHVtaWRpdHkgc2Vuc29ycwoj CiMgQ09ORklHX0RIVDExIGlzIG5vdCBzZXQKCiMKIyBJbmVydGlhbCBtZWFzdXJlbWVudCB1 bml0cwojCiMgQ09ORklHX0FESVMxNjQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0FESVMxNjQ4 MCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVl9NUFU2MDUwX0lJTyBpcyBub3Qgc2V0CgojCiMg TGlnaHQgc2Vuc29ycwojCiMgQ09ORklHX0FESkRfUzMxMSBpcyBub3Qgc2V0CiMgQ09ORklH X0FQRFM5MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ00zMjE4MSBpcyBub3Qgc2V0CiMgQ09O RklHX0NNMzY2NTEgaXMgbm90IHNldAojIENPTkZJR19HUDJBUDAyMEEwMEYgaXMgbm90IHNl dAojIENPTkZJR19UQ1MzNDcyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UU0wyNTYz IGlzIG5vdCBzZXQKIyBDT05GSUdfVFNMNDUzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZDTkw0 MDAwIGlzIG5vdCBzZXQKCiMKIyBNYWduZXRvbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0FL ODk3NSBpcyBub3Qgc2V0CiMgQ09ORklHX01BRzMxMTAgaXMgbm90IHNldAojIENPTkZJR19J SU9fU1RfTUFHTl8zQVhJUyBpcyBub3Qgc2V0CgojCiMgSW5jbGlub21ldGVyIHNlbnNvcnMK IwoKIwojIFRyaWdnZXJzIC0gc3RhbmRhbG9uZQojCiMgQ09ORklHX0lJT19JTlRFUlJVUFRf VFJJR0dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TWVNGU19UUklHR0VSIGlzIG5vdCBz ZXQKCiMKIyBQcmVzc3VyZSBzZW5zb3JzCiMKIyBDT05GSUdfTVBMMzExNSBpcyBub3Qgc2V0 CiMgQ09ORklHX0lJT19TVF9QUkVTUyBpcyBub3Qgc2V0CgojCiMgVGVtcGVyYXR1cmUgc2Vu c29ycwojCiMgQ09ORklHX1RNUDAwNiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMg bm90IHNldApDT05GSUdfUFdNPXkKQ09ORklHX1BXTV9TWVNGUz15CiMgQ09ORklHX1BXTV9Q Q0E5Njg1IGlzIG5vdCBzZXQKQ09ORklHX0lSUUNISVA9eQpDT05GSUdfQVJNX0dJQz15CkNP TkZJR19JUlFfQ1JPU1NCQVI9eQojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAojIENP TkZJR19SRVNFVF9DT05UUk9MTEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfRk1DIGlzIG5vdCBz ZXQKCiMKIyBQSFkgU3Vic3lzdGVtCiMKQ09ORklHX0dFTkVSSUNfUEhZPXkKIyBDT05GSUdf UEhZX0VYWU5PU19NSVBJX1ZJREVPIGlzIG5vdCBzZXQKQ09ORklHX09NQVBfQ09OVFJPTF9Q SFk9eQpDT05GSUdfT01BUF9VU0IyPXkKQ09ORklHX1RJX1BJUEUzPXkKIyBDT05GSUdfUEhZ X0VYWU5PU19EUF9WSURFTyBpcyBub3Qgc2V0CiMgQ09ORklHX0JDTV9LT05BX1VTQjJfUEhZ IGlzIG5vdCBzZXQKIyBDT05GSUdfUE9XRVJDQVAgaXMgbm90IHNldAoKIwojIEZpbGUgc3lz dGVtcwojCkNPTkZJR19EQ0FDSEVfV09SRF9BQ0NFU1M9eQpDT05GSUdfRVhUMl9GUz15CiMg Q09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQyX0ZTX1hJUCBp cyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTPXkKQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JE RVJFRD15CiMgQ09ORklHX0VYVDNfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfRVhUNF9G Uz15CiMgQ09ORklHX0VYVDRfRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhU NF9GU19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfREVCVUcgaXMgbm90IHNl dApDT05GSUdfSkJEPXkKIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pC RDI9eQojIENPTkZJR19KQkQyX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0ZTX01CQ0FDSEU9 eQojIENPTkZJR19SRUlTRVJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0pGU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0dGUzJfRlMgaXMg bm90IHNldAojIENPTkZJR19PQ0ZTMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JUUkZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfTklMRlMyX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BP U0lYX0FDTD15CkNPTkZJR19GSUxFX0xPQ0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05G SUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZX1VTRVI9eQojIENPTkZJR19GQU5PVElGWSBp cyBub3Qgc2V0CkNPTkZJR19RVU9UQT15CiMgQ09ORklHX1FVT1RBX05FVExJTktfSU5URVJG QUNFIGlzIG5vdCBzZXQKQ09ORklHX1BSSU5UX1FVT1RBX1dBUk5JTkc9eQojIENPTkZJR19R VU9UQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19RVU9UQV9UUkVFPXkKIyBDT05GSUdfUUZN VF9WMSBpcyBub3Qgc2V0CkNPTkZJR19RRk1UX1YyPXkKQ09ORklHX1FVT1RBQ1RMPXkKIyBD T05GSUdfQVVUT0ZTNF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZVU0VfRlMgaXMgbm90IHNl dAoKIwojIENhY2hlcwojCiMgQ09ORklHX0ZTQ0FDSEUgaXMgbm90IHNldAoKIwojIENELVJP TS9EVkQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19JU085NjYwX0ZTIGlzIG5vdCBzZXQKIyBD T05GSUdfVURGX0ZTIGlzIG5vdCBzZXQKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMK Q09ORklHX0ZBVF9GUz15CkNPTkZJR19NU0RPU19GUz15CkNPTkZJR19WRkFUX0ZTPXkKQ09O RklHX0ZBVF9ERUZBVUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFUX0RFRkFVTFRfSU9DSEFS U0VUPSJpc284ODU5LTEiCiMgQ09ORklHX05URlNfRlMgaXMgbm90IHNldAoKIwojIFBzZXVk byBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9DX0ZTPXkKQ09ORklHX1BST0NfU1lTQ1RMPXkK Q09ORklHX1BST0NfUEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkKQ09ORklHX1RNUEZT PXkKIyBDT05GSUdfVE1QRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfVE1QRlNf WEFUVFIgaXMgbm90IHNldAojIENPTkZJR19IVUdFVExCRlMgaXMgbm90IHNldAojIENPTkZJ R19IVUdFVExCX1BBR0UgaXMgbm90IHNldApDT05GSUdfQ09ORklHRlNfRlM9bQpDT05GSUdf TUlTQ19GSUxFU1lTVEVNUz15CiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldAojIENPTkZJ R19BRkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRUNSWVBUX0ZTIGlzIG5vdCBzZXQKIyBD T05GSUdfSEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSEZTUExVU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19CRlNfRlMgaXMgbm90IHNl dAojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldApDT05GSUdfSkZGUzJfRlM9eQpDT05GSUdf SkZGUzJfRlNfREVCVUc9MApDT05GSUdfSkZGUzJfRlNfV1JJVEVCVUZGRVI9eQojIENPTkZJ R19KRkZTMl9GU19XQlVGX1ZFUklGWSBpcyBub3Qgc2V0CkNPTkZJR19KRkZTMl9TVU1NQVJZ PXkKQ09ORklHX0pGRlMyX0ZTX1hBVFRSPXkKQ09ORklHX0pGRlMyX0ZTX1BPU0lYX0FDTD15 CkNPTkZJR19KRkZTMl9GU19TRUNVUklUWT15CkNPTkZJR19KRkZTMl9DT01QUkVTU0lPTl9P UFRJT05TPXkKQ09ORklHX0pGRlMyX1pMSUI9eQpDT05GSUdfSkZGUzJfTFpPPXkKQ09ORklH X0pGRlMyX1JUSU1FPXkKQ09ORklHX0pGRlMyX1JVQklOPXkKIyBDT05GSUdfSkZGUzJfQ01P REVfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19KRkZTMl9DTU9ERV9QUklPUklUWT15CiMgQ09O RklHX0pGRlMyX0NNT0RFX1NJWkUgaXMgbm90IHNldAojIENPTkZJR19KRkZTMl9DTU9ERV9G QVZPVVJMWk8gaXMgbm90IHNldApDT05GSUdfVUJJRlNfRlM9eQojIENPTkZJR19VQklGU19G U19BRFZBTkNFRF9DT01QUiBpcyBub3Qgc2V0CkNPTkZJR19VQklGU19GU19MWk89eQpDT05G SUdfVUJJRlNfRlNfWkxJQj15CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NS QU1GUz15CiMgQ09ORklHX1NRVUFTSEZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhGU19GUyBp cyBub3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT01GU19G UyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg0 RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg2RlNfRlMgaXMgbm90IHNldAojIENPTkZJ R19ST01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRSBpcyBub3Qgc2V0CiMgQ09O RklHX1NZU1ZfRlMgaXMgbm90IHNldAojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldAojIENP TkZJR19GMkZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVM9eQpD T05GSUdfTkZTX0ZTPXkKQ09ORklHX05GU19WMj15CkNPTkZJR19ORlNfVjM9eQpDT05GSUdf TkZTX1YzX0FDTD15CkNPTkZJR19ORlNfVjQ9eQojIENPTkZJR19ORlNfU1dBUCBpcyBub3Qg c2V0CiMgQ09ORklHX05GU19WNF8xIGlzIG5vdCBzZXQKQ09ORklHX1JPT1RfTkZTPXkKIyBD T05GSUdfTkZTX1VTRV9MRUdBQ1lfRE5TIGlzIG5vdCBzZXQKQ09ORklHX05GU19VU0VfS0VS TkVMX0ROUz15CiMgQ09ORklHX05GU0QgaXMgbm90IHNldApDT05GSUdfTE9DS0Q9eQpDT05G SUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPXkKQ09ORklHX05GU19DT01N T049eQpDT05GSUdfU1VOUlBDPXkKQ09ORklHX1NVTlJQQ19HU1M9eQojIENPTkZJR19TVU5S UENfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19DRVBIX0ZTIGlzIG5vdCBzZXQKIyBDT05G SUdfQ0lGUyBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklH X0NPREFfRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldApDT05GSUdf TkxTPXkKQ09ORklHX05MU19ERUZBVUxUPSJpc284ODU5LTEiCkNPTkZJR19OTFNfQ09ERVBB R0VfNDM3PXkKIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0CiMgQ09ORklH X05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODUw IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MiBpcyBub3Qgc2V0CiMgQ09O RklHX05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf ODU3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MCBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19DT0RFUEFHRV84NjEgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB R0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MyBpcyBub3Qgc2V0 CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E RVBBR0VfODY1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NiBpcyBub3Qg c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjkgaXMgbm90IHNldAojIENPTkZJR19OTFNf Q09ERVBBR0VfOTM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk1MCBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfOTQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzggaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfMTI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV8xMjUx IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0FTQ0lJIGlzIG5vdCBzZXQKQ09ORklHX05MU19J U084ODU5XzE9eQojIENPTkZJR19OTFNfSVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdf TkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzQgaXMgbm90 IHNldAojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lT Tzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzcgaXMgbm90IHNldAoj IENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlf MTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNCBpcyBub3Qgc2V0CiMgQ09O RklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0tPSThfUiBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFD X1JPTUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19DRUxUSUMgaXMgbm90IHNldAoj IENPTkZJR19OTFNfTUFDX0NFTlRFVVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19D Uk9BVElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ1lSSUxMSUMgaXMgbm90IHNl dAojIENPTkZJR19OTFNfTUFDX0dBRUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNf R1JFRUsgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0lDRUxBTkQgaXMgbm90IHNldAoj IENPTkZJR19OTFNfTUFDX0lOVUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19ST01B TklBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfVFVSS0lTSCBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19VVEY4IGlzIG5vdCBzZXQKIyBDT05GSUdfRExNIGlzIG5vdCBzZXQKCiMK IyBLZXJuZWwgaGFja2luZwojCgojCiMgcHJpbnRrIGFuZCBkbWVzZyBvcHRpb25zCiMKQ09O RklHX1BSSU5US19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD00CiMg Q09ORklHX0JPT1RfUFJJTlRLX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19E RUJVRyBpcyBub3Qgc2V0CgojCiMgQ29tcGlsZS10aW1lIGNoZWNrcyBhbmQgY29tcGlsZXIg b3B0aW9ucwojCkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdfREVCVUdfSU5GT19SRURV Q0VEIGlzIG5vdCBzZXQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQpDT05GSUdf RU5BQkxFX01VU1RfQ0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0xMDI0CiMgQ09ORklHX1NU UklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVBREFCTEVfQVNNIGlzIG5vdCBz ZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJPTFMgaXMgbm90IHNldApDT05GSUdfREVCVUdfRlM9 eQojIENPTkZJR19IRUFERVJTX0NIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0VD VElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkKIyBDT05G SUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX01BR0lDX1NZ U1JRPXkKQ09ORklHX01BR0lDX1NZU1JRX0RFRkFVTFRfRU5BQkxFPTB4MQpDT05GSUdfREVC VUdfS0VSTkVMPXkKCiMKIyBNZW1vcnkgRGVidWdnaW5nCiMKIyBDT05GSUdfREVCVUdfUEFH RUFMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX1NMQUIgaXMgbm90IHNldApDT05GSUdfSEFWRV9ERUJVR19LTUVNTEVB Sz15CiMgQ09ORklHX0RFQlVHX0tNRU1MRUFLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf U1RBQ0tfVVNBR0UgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19WTSBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX01FTU9SWV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfUEVS X0NQVV9NQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfSElHSE1FTSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RFQlVHX1NISVJRIGlzIG5vdCBzZXQKCiMKIyBEZWJ1ZyBMb2NrdXBzIGFu ZCBIYW5ncwojCiMgQ09ORklHX0xPQ0tVUF9ERVRFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklH X0RFVEVDVF9IVU5HX1RBU0sgaXMgbm90IHNldAojIENPTkZJR19QQU5JQ19PTl9PT1BTIGlz IG5vdCBzZXQKQ09ORklHX1BBTklDX09OX09PUFNfVkFMVUU9MApDT05GSUdfUEFOSUNfVElN RU9VVD0wCiMgQ09ORklHX1NDSEVEX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURT VEFUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJTUVSX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklH X0RFQlVHX1BSRUVNUFQ9eQoKIwojIExvY2sgRGVidWdnaW5nIChzcGlubG9ja3MsIG11dGV4 ZXMsIGV0Yy4uLikKIwojIENPTkZJR19ERUJVR19SVF9NVVRFWEVTIGlzIG5vdCBzZXQKIyBD T05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1BJTkxP Q0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19NVVRFWEVTIGlzIG5vdCBzZXQKIyBDT05G SUdfREVCVUdfV1dfTVVURVhfU0xPV1BBVEggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19M T0NLX0FMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJPVkVfTE9DS0lORyBpcyBub3Qgc2V0 CiMgQ09ORklHX0xPQ0tfU1RBVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0FUT01JQ19T TEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NUQUNLVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19ERUJV R19LT0JKRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQlVHVkVSQk9TRSBpcyBub3Qg c2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldAojIENPTkZJR19ERUJV R19MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJ R19ERUJVR19OT1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFM UyBpcyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1BST1ZFX1JDVV9E RUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NQQVJTRV9SQ1VfUE9JTlRFUiBpcyBub3Qgc2V0 CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQVV9T VEFMTF9USU1FT1VUPTIxCkNPTkZJR19SQ1VfQ1BVX1NUQUxMX1ZFUkJPU0U9eQojIENPTkZJ R19SQ1VfQ1BVX1NUQUxMX0lORk8gaXMgbm90IHNldAojIENPTkZJR19SQ1VfVFJBQ0UgaXMg bm90IHNldAojIENPTkZJR19ERUJVR19CTE9DS19FWFRfREVWVCBpcyBub3Qgc2V0CiMgQ09O RklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZBVUxU X0lOSkVDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNP TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0RZTkFNSUNf RlRSQUNFPXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFW RV9TWVNDQUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpD T05GSUdfVFJBQ0VfQ0xPQ0s9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdfUklOR19C VUZGRVJfQUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HX1NVUFBPUlQ9eQojIENPTkZJR19G VFJBQ0UgaXMgbm90IHNldAoKIwojIFJ1bnRpbWUgVGVzdGluZwojCiMgQ09ORklHX0xLRFRN IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9MSVNUX1NPUlQgaXMgbm90IHNldAojIENPTkZJ R19LUFJPQkVTX1NBTklUWV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS1RSQUNFX1NF TEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JCVFJFRV9URVNUIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5URVJWQUxfVFJFRV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUEVSQ1BVX1RF U1QgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMg Q09ORklHX1RFU1RfU1RSSU5HX0hFTFBFUlMgaXMgbm90IHNldAojIENPTkZJR19URVNUX0tT VFJUT1ggaXMgbm90IHNldAojIENPTkZJR19ETUFfQVBJX0RFQlVHIGlzIG5vdCBzZXQKIyBD T05GSUdfVEVTVF9NT0RVTEUgaXMgbm90IHNldAojIENPTkZJR19URVNUX1VTRVJfQ09QWSBp cyBub3Qgc2V0CiMgQ09ORklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNI X0tHREI9eQojIENPTkZJR19LR0RCIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX1BURFVNUCBp cyBub3Qgc2V0CiMgQ09ORklHX1NUUklDVF9ERVZNRU0gaXMgbm90IHNldAojIENPTkZJR19B Uk1fVU5XSU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVVNFUiBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX0xMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0xMX0lOQ0xVREU9Im1h Y2gvZGVidWctbWFjcm8uUyIKIyBDT05GSUdfREVCVUdfVUFSVF9QTDAxWCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RFQlVHX1VBUlRfODI1MCBpcyBub3Qgc2V0CkNPTkZJR19VTkNPTVBSRVNT X0lOQ0xVREU9ImRlYnVnL3VuY29tcHJlc3MuaCIKIyBDT05GSUdfQVJNX0tQUk9CRVNfVEVT VCBpcyBub3Qgc2V0CiMgQ09ORklHX1BJRF9JTl9DT05URVhUSURSIGlzIG5vdCBzZXQKIyBD T05GSUdfREVCVUdfU0VUX01PRFVMRV9ST05YIGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBv cHRpb25zCiMKQ09ORklHX0tFWVM9eQojIENPTkZJR19QRVJTSVNURU5UX0tFWVJJTkdTIGlz IG5vdCBzZXQKIyBDT05GSUdfQklHX0tFWVMgaXMgbm90IHNldAojIENPTkZJR19FTkNSWVBU RURfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWVNfREVCVUdfUFJPQ19LRVlTIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1QgaXMgbm90IHNldApDT05G SUdfU0VDVVJJVFk9eQojIENPTkZJR19TRUNVUklUWUZTIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VDVVJJVFlfTkVUV09SSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX1BBVEggaXMg bm90IHNldAojIENPTkZJR19TRUNVUklUWV9TTUFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NF Q1VSSVRZX1RPTU9ZTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX0FQUEFSTU9SIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfWUFNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lN QSBpcyBub3Qgc2V0CiMgQ09ORklHX0VWTSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX1NF Q1VSSVRZX0RBQz15CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZPSIiCkNPTkZJR19DUllQVE89 eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19DUllQVE9fQUxHQVBJPXkK Q09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklHX0NSWVBUT19BRUFEPXkKQ09ORklHX0NS WVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19C TEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09ORklHX0NSWVBUT19IQVNIMj15 CkNPTkZJR19DUllQVE9fUk5HPXkKQ09ORklHX0NSWVBUT19STkcyPXkKQ09ORklHX0NSWVBU T19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdfQ1JZUFRPX01BTkFH RVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX01B TkFHRVJfRElTQUJMRV9URVNUUz15CiMgQ09ORklHX0NSWVBUT19HRjEyOE1VTCBpcyBub3Qg c2V0CiMgQ09ORklHX0NSWVBUT19OVUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1BD UllQVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FVRVVFPXkKIyBDT05GSUdfQ1JZ UFRPX0NSWVBURCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19BVVRIRU5DIGlzIG5vdCBz ZXQKQ09ORklHX0NSWVBUT19URVNUPW0KCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24g d2l0aCBBc3NvY2lhdGVkIERhdGEKIwpDT05GSUdfQ1JZUFRPX0NDTT15CiMgQ09ORklHX0NS WVBUT19HQ00gaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1NFUUlWPXkKCiMKIyBCbG9jayBt b2RlcwojCiMgQ09ORklHX0NSWVBUT19DQkMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0NU Uj15CiMgQ09ORklHX0NSWVBUT19DVFMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0VDQj15 CiMgQ09ORklHX0NSWVBUT19MUlcgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUENCQyBp cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19YVFMgaXMgbm90IHNldAoKIwojIEhhc2ggbW9k ZXMKIwojIENPTkZJR19DUllQVE9fQ01BQyBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fSE1B Qz15CiMgQ09ORklHX0NSWVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZN QUMgaXMgbm90IHNldAoKIwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKIyBD T05GSUdfQ1JZUFRPX0NSQzMyIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DUkNUMTBESUY9 eQojIENPTkZJR19DUllQVE9fR0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTUQ0 IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19NRDU9eQpDT05GSUdfQ1JZUFRPX01JQ0hBRUxf TUlDPXkKIyBDT05GSUdfQ1JZUFRPX1JNRDEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU T19STUQxNjAgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMjU2IGlzIG5vdCBzZXQK IyBDT05GSUdfQ1JZUFRPX1JNRDMyMCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBMT15 CiMgQ09ORklHX0NSWVBUT19TSEExX0FSTSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hB MjU2PXkKQ09ORklHX0NSWVBUT19TSEE1MTI9eQojIENPTkZJR19DUllQVE9fVEdSMTkyIGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1dQNTEyIGlzIG5vdCBzZXQKCiMKIyBDaXBoZXJz CiMKQ09ORklHX0NSWVBUT19BRVM9eQojIENPTkZJR19DUllQVE9fQUVTX0FSTSBpcyBub3Qg c2V0CiMgQ09ORklHX0NSWVBUT19BTlVCSVMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0FS QzQ9eQojIENPTkZJR19DUllQVE9fQkxPV0ZJU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQ VE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDUgaXMgbm90IHNl dAojIENPTkZJR19DUllQVE9fQ0FTVDYgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0RFUz15 CiMgQ09ORklHX0NSWVBUT19GQ1JZUFQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fS0hB WkFEIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NBTFNBMjAgaXMgbm90IHNldAojIENP TkZJR19DUllQVE9fU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TRVJQRU5UIGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RFQSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU T19UV09GSVNIIGlzIG5vdCBzZXQKCiMKIyBDb21wcmVzc2lvbgojCkNPTkZJR19DUllQVE9f REVGTEFURT15CiMgQ09ORklHX0NSWVBUT19aTElCIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBU T19MWk89eQojIENPTkZJR19DUllQVE9fTFo0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP X0xaNEhDIGlzIG5vdCBzZXQKCiMKIyBSYW5kb20gTnVtYmVyIEdlbmVyYXRpb24KIwojIENP TkZJR19DUllQVE9fQU5TSV9DUFJORyBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fVVNFUl9B UEk9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0g9eQpDT05GSUdfQ1JZUFRPX1VTRVJf QVBJX1NLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19IVz15CkNPTkZJR19DUllQVE9fREVWX09N QVBfU0hBTT15CkNPTkZJR19DUllQVE9fREVWX09NQVBfQUVTPXkKQ09ORklHX0NSWVBUT19E RVZfT01BUF9ERVM9eQojIENPTkZJR19BU1lNTUVUUklDX0tFWV9UWVBFIGlzIG5vdCBzZXQK IyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0CgojCiMgTGlicmFyeSByb3V0aW5l cwojCkNPTkZJR19CSVRSRVZFUlNFPXkKQ09ORklHX0dFTkVSSUNfU1RSTkNQWV9GUk9NX1VT RVI9eQpDT05GSUdfR0VORVJJQ19TVFJOTEVOX1VTRVI9eQpDT05GSUdfR0VORVJJQ19ORVRf VVRJTFM9eQpDT05GSUdfR0VORVJJQ19QQ0lfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JTz15 CkNPTkZJR19BUkNIX1VTRV9DTVBYQ0hHX0xPQ0tSRUY9eQpDT05GSUdfQ1JDX0NDSVRUPXkK Q09ORklHX0NSQzE2PXkKQ09ORklHX0NSQ19UMTBESUY9eQpDT05GSUdfQ1JDX0lUVV9UPXkK Q09ORklHX0NSQzMyPXkKIyBDT05GSUdfQ1JDMzJfU0VMRlRFU1QgaXMgbm90IHNldApDT05G SUdfQ1JDMzJfU0xJQ0VCWTg9eQojIENPTkZJR19DUkMzMl9TTElDRUJZNCBpcyBub3Qgc2V0 CiMgQ09ORklHX0NSQzMyX1NBUldBVEUgaXMgbm90IHNldAojIENPTkZJR19DUkMzMl9CSVQg aXMgbm90IHNldApDT05GSUdfQ1JDNz15CkNPTkZJR19MSUJDUkMzMkM9eQojIENPTkZJR19D UkM4IGlzIG5vdCBzZXQKIyBDT05GSUdfUkFORE9NMzJfU0VMRlRFU1QgaXMgbm90IHNldApD T05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklHX1pMSUJfREVGTEFURT15CkNPTkZJR19MWk9f Q09NUFJFU1M9eQpDT05GSUdfTFpPX0RFQ09NUFJFU1M9eQojIENPTkZJR19YWl9ERUMgaXMg bm90IHNldAojIENPTkZJR19YWl9ERUNfQkNKIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJF U1NfR1pJUD15CkNPTkZJR19CQ0g9eQpDT05GSUdfQVNTT0NJQVRJVkVfQVJSQVk9eQpDT05G SUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9eQpDT05GSUdfSEFTX0RNQT15CkNP TkZJR19DUFVfUk1BUD15CkNPTkZJR19EUUw9eQpDT05GSUdfTkxBVFRSPXkKQ09ORklHX0FS Q0hfSEFTX0FUT01JQzY0X0RFQ19JRl9QT1NJVElWRT15CiMgQ09ORklHX0FWRVJBR0UgaXMg bm90IHNldAojIENPTkZJR19DT1JESUMgaXMgbm90IHNldAojIENPTkZJR19ERFIgaXMgbm90 IHNldApDT05GSUdfT0lEX1JFR0lTVFJZPXkKQ09ORklHX0ZPTlRfU1VQUE9SVD15CkNPTkZJ R19GT05UUz15CkNPTkZJR19GT05UXzh4OD15CkNPTkZJR19GT05UXzh4MTY9eQojIENPTkZJ R19GT05UXzZ4MTEgaXMgbm90IHNldAojIENPTkZJR19GT05UXzd4MTQgaXMgbm90IHNldAoj IENPTkZJR19GT05UX1BFQVJMXzh4OCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRfQUNPUk5f OHg4IGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVF9NSU5JXzR4NiBpcyBub3Qgc2V0CiMgQ09O RklHX0ZPTlRfU1VOOHgxNiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRfU1VOMTJ4MjIgaXMg bm90IHNldAojIENPTkZJR19GT05UXzEweDE4IGlzIG5vdCBzZXQKQ09ORklHX1ZJUlRVQUxJ WkFUSU9OPXkKIyBDT05GSUdfS1ZNIGlzIG5vdCBzZXQK --------------020909000202020305090300 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020909000202020305090300-- From xen-users-bounces@lists.xen.org Thu Jul 09 16:19:03 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 16:19:03 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDEWU-00026A-0p; Thu, 09 Jul 2015 16:18:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDEWS-00025f-MC for xen-users@lists.xen.org; Thu, 09 Jul 2015 16:18:05 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 1B/9A-18676-CBE9E955; Thu, 09 Jul 2015 16:18:04 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1436458680!30671527!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22005 invoked from network); 9 Jul 2015 16:18:01 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 16:18:01 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69GHvhF015650; Thu, 9 Jul 2015 11:17:57 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69GHuRa019505; Thu, 9 Jul 2015 11:17:57 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 11:17:39 -0500 Message-ID: <559E90A7.7010809@ti.com> Date: Thu, 9 Jul 2015 11:17:59 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Julien Grall , Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> In-Reply-To: <559E9362.3000402@citrix.com> Content-Type: multipart/mixed; boundary="------------020909000202020305090300" X-Originating-IP: [128.247.93.131] Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020909000202020305090300 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit On 07/09/2015 11:29 AM, Julien Grall wrote: > Hi, > > On 09/07/2015 15:55, Brandon Perez wrote: >> On 07/09/2015 03:34 AM, Julien Grall wrote: >> > These rangesets list the interrupt and I/O memory assigned to the >> guest >> > (i.e passthrough). >> > >> > In the case of the timer interrupt (physical and virtual), they are >> > owned by Xen and Xen will emulated it for each guest. >> > >> > From the logs the LRs are empty (see VCPU_LR) and no interrupts are >> > currently pending. >> > >> > I would add some printk in function gic_handle_irq in Linux >> > (drivers/irqchip/irq-gic.c, assuming you are using GICv2) to see which >> > IRQ is coming. FYI, the virt timer PPI is 27 and phys timer 30. >> > >> >> I added that printk statement, and I never see any physical or >> virtual timer interrupts being delivered to the guest. I believe the >> guest is using the virtual timer, because when I do a more full register >> dump with trace32, I see that CNTV_CVAL is programmed to a non-zero >> value, but CNTP_CVAL is 0. > > Do you receive other interrupts in the guest? > >> >> I also noticed the following line during the Dom0 guest boot: >> >> (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz >> >> Is this expected to be different from the expected interrupt ID's >> for ARM core timers (these numbers are all offset by +5)? > > The timer IRQs for DOM0 and the guest may be different. DOM0 will use > the same as the hardware (i.e the one in your log), while guests have a > their interrupt defined in the guest layout (see > xen/include/public/arch-arm.h). > >> Correct me if I'm wrong, but it seems like gic_handle_irq() is not >> the control path taken by the PPI timers. It looks like the functions >> "vtimer_interrupt()" and "timer_interrupt()" (xen/arch/arm/time.c) >> handle those interrupts. > > I think you are mixing two different things here: > - gic_handle_irq is the Linux interrupt handler for GICv2 where > every IRQ is coming (PPIs, SPIs...) > - vtimer_interrupt and timer_interrupt are Xen handlers which > will take of the timer IRQs of the hardware. > > When the hardware fire a virtual interrupt it will be: > 1) Received by Xen via gic_interrupt > 2) do_IRQ will dispatch the IRQ > 3) virtual_interrupt will be called has it has been registered as > callback for the virtual timer > 4) The interrupt will be injected to the guest using the guest > virtual interrupt number. I.e the LRs will be setup > 5) The guest will receive the interrupt > 6) gic_handle_irq will dispatch the interrupt > >> >> Also, based on the following lines in xen/arch/arm/irq.c: 224-226, >> it seems like that the guests cannot be delivered PPI's from the >> function "do_IRQ()": >> >> /* the irq cannot be a PPI, we only support delivery of SPIs to >> * guests */ >> vgic_vcpu_inject_spi(info->d, info->virq); > > This call is only used for IRQ owned by the domain. > > In the case of the timer IRQs, they are owned by Xen and therefore not > directly injected to the guest. > >> >> Also, how do the functions in xen/arch/arm/vtimer.c fit into this >> picture? Would they be the ones responsible for delivering the vtimer >> interrupt to the guest? > > The file vtimer.c contains anything related to the guest timer: > emulation of the physical timer and context/restore of both virtual and > physical timer. > > The injection of the timer interrupts will be done in different place: > - virtual: this is done in vtimer_interrupt (xen/arch/arm/timer.c) > when the domain is running. If the domain is not running, we create a > timer and may inject an interrupt if the timer has expired (see > virt_timer_expired in xen/arch/arm/vtimer.c). > - physical: the timer is completely emulated. The injection of the > interrupt is done in phys_timer_expired (xen/arch/arm/vtimer.c). > > You can add printk in those place to check whether the interrupt is > injected to the guest or not. It may give you an insight of whether the > timer has been correctly setup by the guest or not. > > Note that you may want to only print when it's not domain 0 to avoid log > pollution. > >> Yes, I'm using the 3.14 kernel for both dom0 and domU. >> Unfortunately, I need the 3.14 kernel, but if these problems persist, I >> may try to update to a newer mainline kernel. > > May I ask you to provide > - the .config used to build the kernel > - a link to the git repo containing the branch (I wasn't able to > find it on your first mail) > > You also said you had local changes in both Linux and Xen. Can you tell > us what kind of changes? > > Regards, > Hi Julien, Thanks, for the clarifications on my questions on interrupt/timer code flow in Xen. That made it a lot clearer. I figured out what is causing the bug, and it turned out to be one of the local changes I had to Xen. On the DRA72x device, there are a large number of peripheral devices, more than can be handled by the SPI on the GIC. Therefore, there's an internal mechanism that allows the routing of these peripherals to the interrupt lines on the GIC. Unfortunately, this means that the "interrupt" property of devices in the device tree do not contain the interrupt ID of the device, but rather contain the index (ID) of the peripheral on the board. In the Linux kernel, the peripherals are mapped to SPI IRQ lines as they are needed. So, given the same device tree and configuration settings, the mapping will always be the same, but this cannot be easily inferred from the device tree. The mapping is not static, but once the interrupts are assigned, they do not change. Naturally, Xen is unaware of this interrupt ID remapping, so it maps interrupts prematurely, or assertions fail, as the "interrupt ID" found in the device tree is larger than the total number of GIC lines. To work-around this, I made the mapping of peripherals fully static, so Xen would accept the default configuration given to it by the bootloader, and the Linux kernel would not to attempt to create a new mapping from the devices in the device tree. The change I made essentially involved adding an extra layer of translation to "gic_irq_xlate()", where if the platform has defined irq remap function, then it performs this remapping. This lead to an issue because I assumed that all devices in the device tree were peripheral devices, tied to SPIs (thus requiring translation). PPIs, naturally, are independent of this peripheral remapping, since they are on the physical processor. Thus, there was a timer node in the device tree, and I was incorrectly translating these interrupt numbers, treating the like SPIs, instead of PPIs. So, I just had to make the simple change of performing the extra layer of translation only if it was an SPI. Then, since none of the timer interrupt functions were properly mapped to the correct IRQ lines, the timer interrupts were not handled properly, which showed up in my guest kernel boot as the Guest getting stuck in a hrtimer sleep forever, since no virtual timer interrupts were ever received. For the sake of completeness, I've attached my .config file for the kernel. It's a standard kernel configuration, with some extra parameters for Xen as outlined in [1]. The git repo is at git://git.omapzoom.org/kernel/omap.git, and the branch is "android-3.14-6AL.1.0". [1] http://wiki.xenproject.org/wiki/Xen_ARM_with_Virtualization_Extensions/OMAP5432_uEVM Brandon --------------020909000202020305090300 Content-Type: text/plain; charset="UTF-8"; name=".config" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=".config" IwojIEF1dG9tYXRpY2FsbHkgZ2VuZXJhdGVkIGZpbGU7IERPIE5PVCBFRElULgojIExpbnV4 L2FybSAzLjE0LjMxIEtlcm5lbCBDb25maWd1cmF0aW9uCiMKQ09ORklHX0FSTT15CkNPTkZJ R19NSUdIVF9IQVZFX1BDST15CkNPTkZJR19TWVNfU1VQUE9SVFNfQVBNX0VNVUxBVElPTj15 CkNPTkZJR19IQVZFX1BST0NfQ1BVPXkKQ09ORklHX1NUQUNLVFJBQ0VfU1VQUE9SVD15CkNP TkZJR19MT0NLREVQX1NVUFBPUlQ9eQpDT05GSUdfVFJBQ0VfSVJRRkxBR1NfU1VQUE9SVD15 CkNPTkZJR19SV1NFTV9HRU5FUklDX1NQSU5MT0NLPXkKQ09ORklHX0FSQ0hfSEFTX0NQVUZS RVE9eQpDT05GSUdfQVJDSF9IQVNfQkFOREdBUD15CkNPTkZJR19HRU5FUklDX0hXRUlHSFQ9 eQpDT05GSUdfR0VORVJJQ19DQUxJQlJBVEVfREVMQVk9eQpDT05GSUdfTkVFRF9ETUFfTUFQ X1NUQVRFPXkKQ09ORklHX1ZFQ1RPUlNfQkFTRT0weGZmZmYwMDAwCkNPTkZJR19BUk1fUEFU Q0hfUEhZU19WSVJUPXkKQ09ORklHX0dFTkVSSUNfQlVHPXkKQ09ORklHX0RFRkNPTkZJR19M SVNUPSIvbGliL21vZHVsZXMvJFVOQU1FX1JFTEVBU0UvLmNvbmZpZyIKQ09ORklHX0lSUV9X T1JLPXkKQ09ORklHX0JVSUxEVElNRV9FWFRBQkxFX1NPUlQ9eQoKIwojIEdlbmVyYWwgc2V0 dXAKIwpDT05GSUdfSU5JVF9FTlZfQVJHX0xJTUlUPTMyCkNPTkZJR19DUk9TU19DT01QSUxF PSIiCiMgQ09ORklHX0NPTVBJTEVfVEVTVCBpcyBub3Qgc2V0CkNPTkZJR19MT0NBTFZFUlNJ T049IiIKQ09ORklHX0xPQ0FMVkVSU0lPTl9BVVRPPXkKQ09ORklHX0hBVkVfS0VSTkVMX0da SVA9eQpDT05GSUdfSEFWRV9LRVJORUxfTFpNQT15CkNPTkZJR19IQVZFX0tFUk5FTF9YWj15 CkNPTkZJR19IQVZFX0tFUk5FTF9MWk89eQpDT05GSUdfSEFWRV9LRVJORUxfTFo0PXkKQ09O RklHX0tFUk5FTF9HWklQPXkKIyBDT05GSUdfS0VSTkVMX0xaTUEgaXMgbm90IHNldAojIENP TkZJR19LRVJORUxfWFogaXMgbm90IHNldAojIENPTkZJR19LRVJORUxfTFpPIGlzIG5vdCBz ZXQKIyBDT05GSUdfS0VSTkVMX0xaNCBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX0hPU1RO QU1FPSIobm9uZSkiCkNPTkZJR19TV0FQPXkKQ09ORklHX1NZU1ZJUEM9eQpDT05GSUdfU1lT VklQQ19TWVNDVEw9eQpDT05GSUdfUE9TSVhfTVFVRVVFPXkKQ09ORklHX1BPU0lYX01RVUVV RV9TWVNDVEw9eQojIENPTkZJR19GSEFORExFIGlzIG5vdCBzZXQKIyBDT05GSUdfQVVESVQg aXMgbm90IHNldAoKIwojIElSUSBzdWJzeXN0ZW0KIwpDT05GSUdfR0VORVJJQ19JUlFfUFJP QkU9eQpDT05GSUdfR0VORVJJQ19JUlFfU0hPVz15CkNPTkZJR19IQVJESVJRU19TV19SRVNF TkQ9eQpDT05GSUdfR0VORVJJQ19JUlFfQ0hJUD15CkNPTkZJR19JUlFfRE9NQUlOPXkKIyBD T05GSUdfSVJRX0RPTUFJTl9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19JUlFfRk9SQ0VEX1RI UkVBRElORz15CkNPTkZJR19TUEFSU0VfSVJRPXkKQ09ORklHX0tUSU1FX1NDQUxBUj15CkNP TkZJR19HRU5FUklDX0NMT0NLRVZFTlRTPXkKQ09ORklHX0dFTkVSSUNfQ0xPQ0tFVkVOVFNf QlVJTEQ9eQpDT05GSUdfQVJDSF9IQVNfVElDS19CUk9BRENBU1Q9eQpDT05GSUdfR0VORVJJ Q19DTE9DS0VWRU5UU19CUk9BRENBU1Q9eQoKIwojIFRpbWVycyBzdWJzeXN0ZW0KIwpDT05G SUdfVElDS19PTkVTSE9UPXkKQ09ORklHX05PX0haX0NPTU1PTj15CiMgQ09ORklHX0haX1BF UklPRElDIGlzIG5vdCBzZXQKQ09ORklHX05PX0haX0lETEU9eQojIENPTkZJR19OT19IWl9G VUxMIGlzIG5vdCBzZXQKQ09ORklHX05PX0haPXkKQ09ORklHX0hJR0hfUkVTX1RJTUVSUz15 CgojCiMgQ1BVL1Rhc2sgdGltZSBhbmQgc3RhdHMgYWNjb3VudGluZwojCkNPTkZJR19USUNL X0NQVV9BQ0NPVU5USU5HPXkKIyBDT05GSUdfVklSVF9DUFVfQUNDT1VOVElOR19HRU4gaXMg bm90IHNldAojIENPTkZJR19JUlFfVElNRV9BQ0NPVU5USU5HIGlzIG5vdCBzZXQKQ09ORklH X0JTRF9QUk9DRVNTX0FDQ1Q9eQojIENPTkZJR19CU0RfUFJPQ0VTU19BQ0NUX1YzIGlzIG5v dCBzZXQKIyBDT05GSUdfVEFTS1NUQVRTIGlzIG5vdCBzZXQKCiMKIyBSQ1UgU3Vic3lzdGVt CiMKQ09ORklHX1RSRUVfUFJFRU1QVF9SQ1U9eQpDT05GSUdfUFJFRU1QVF9SQ1U9eQpDT05G SUdfUkNVX1NUQUxMX0NPTU1PTj15CiMgQ09ORklHX1JDVV9VU0VSX1FTIGlzIG5vdCBzZXQK Q09ORklHX1JDVV9GQU5PVVQ9MzIKQ09ORklHX1JDVV9GQU5PVVRfTEVBRj0xNgojIENPTkZJ R19SQ1VfRkFOT1VUX0VYQUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUkNVX0ZBU1RfTk9fSFog aXMgbm90IHNldAojIENPTkZJR19UUkVFX1JDVV9UUkFDRSBpcyBub3Qgc2V0CiMgQ09ORklH X1JDVV9CT09TVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JDVV9OT0NCX0NQVSBpcyBub3Qgc2V0 CkNPTkZJR19JS0NPTkZJRz15CkNPTkZJR19JS0NPTkZJR19QUk9DPXkKQ09ORklHX0xPR19C VUZfU0hJRlQ9MTYKQ09ORklHX0dFTkVSSUNfU0NIRURfQ0xPQ0s9eQpDT05GSUdfQ0dST1VQ Uz15CiMgQ09ORklHX0NHUk9VUF9ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX0NHUk9VUF9G UkVFWkVSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQX0RFVklDRSBpcyBub3Qgc2V0CiMg Q09ORklHX0NQVVNFVFMgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfQ1BVQUNDVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFU09VUkNFX0NPVU5URVJTIGlzIG5vdCBzZXQKIyBDT05GSUdf Q0dST1VQX1BFUkYgaXMgbm90IHNldAojIENPTkZJR19DR1JPVVBfU0NIRUQgaXMgbm90IHNl dAojIENPTkZJR19CTEtfQ0dST1VQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hFQ0tQT0lOVF9S RVNUT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFNRVNQQUNFUyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDSEVEX0FVVE9HUk9VUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU0ZTX0RFUFJFQ0FU RUQgaXMgbm90IHNldAojIENPTkZJR19SRUxBWSBpcyBub3Qgc2V0CkNPTkZJR19CTEtfREVW X0lOSVRSRD15CkNPTkZJR19JTklUUkFNRlNfU09VUkNFPSIiCkNPTkZJR19SRF9HWklQPXkK IyBDT05GSUdfUkRfQlpJUDIgaXMgbm90IHNldAojIENPTkZJR19SRF9MWk1BIGlzIG5vdCBz ZXQKIyBDT05GSUdfUkRfWFogaXMgbm90IHNldAojIENPTkZJR19SRF9MWk8gaXMgbm90IHNl dAojIENPTkZJR19SRF9MWjQgaXMgbm90IHNldAojIENPTkZJR19DQ19PUFRJTUlaRV9GT1Jf U0laRSBpcyBub3Qgc2V0CkNPTkZJR19TWVNDVEw9eQpDT05GSUdfQU5PTl9JTk9ERVM9eQpD T05GSUdfSEFWRV9VSUQxNj15CkNPTkZJR19FWFBFUlQ9eQpDT05GSUdfVUlEMTY9eQojIENP TkZJR19TWVNDVExfU1lTQ0FMTCBpcyBub3Qgc2V0CkNPTkZJR19LQUxMU1lNUz15CiMgQ09O RklHX0tBTExTWU1TX0FMTCBpcyBub3Qgc2V0CkNPTkZJR19QUklOVEs9eQpDT05GSUdfQlVH PXkKQ09ORklHX0VMRl9DT1JFPXkKQ09ORklHX0JBU0VfRlVMTD15CkNPTkZJR19GVVRFWD15 CkNPTkZJR19FUE9MTD15CkNPTkZJR19TSUdOQUxGRD15CkNPTkZJR19USU1FUkZEPXkKQ09O RklHX0VWRU5URkQ9eQpDT05GSUdfU0hNRU09eQpDT05GSUdfQUlPPXkKQ09ORklHX1BDSV9R VUlSS1M9eQojIENPTkZJR19FTUJFRERFRCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX1BFUkZf RVZFTlRTPXkKQ09ORklHX1BFUkZfVVNFX1ZNQUxMT0M9eQoKIwojIEtlcm5lbCBQZXJmb3Jt YW5jZSBFdmVudHMgQW5kIENvdW50ZXJzCiMKQ09ORklHX1BFUkZfRVZFTlRTPXkKIyBDT05G SUdfREVCVUdfUEVSRl9VU0VfVk1BTExPQyBpcyBub3Qgc2V0CkNPTkZJR19WTV9FVkVOVF9D T1VOVEVSUz15CkNPTkZJR19DT01QQVRfQlJLPXkKQ09ORklHX1NMQUI9eQojIENPTkZJR19T TFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xPQiBpcyBub3Qgc2V0CiMgQ09ORklHX1NZU1RF TV9UUlVTVEVEX0tFWVJJTkcgaXMgbm90IHNldApDT05GSUdfUFJPRklMSU5HPXkKQ09ORklH X09QUk9GSUxFPXkKQ09ORklHX0hBVkVfT1BST0ZJTEU9eQpDT05GSUdfS1BST0JFUz15CkNP TkZJR19KVU1QX0xBQkVMPXkKIyBDT05GSUdfSEFWRV82NEJJVF9BTElHTkVEX0FDQ0VTUyBp cyBub3Qgc2V0CkNPTkZJR19IQVZFX0VGRklDSUVOVF9VTkFMSUdORURfQUNDRVNTPXkKQ09O RklHX0FSQ0hfVVNFX0JVSUxUSU5fQlNXQVA9eQpDT05GSUdfS1JFVFBST0JFUz15CkNPTkZJ R19IQVZFX0tQUk9CRVM9eQpDT05GSUdfSEFWRV9LUkVUUFJPQkVTPXkKQ09ORklHX0hBVkVf QVJDSF9UUkFDRUhPT0s9eQpDT05GSUdfSEFWRV9ETUFfQVRUUlM9eQpDT05GSUdfSEFWRV9E TUFfQ09OVElHVU9VUz15CkNPTkZJR19HRU5FUklDX1NNUF9JRExFX1RIUkVBRD15CkNPTkZJ R19HRU5FUklDX0lETEVfUE9MTF9TRVRVUD15CkNPTkZJR19IQVZFX1JFR1NfQU5EX1NUQUNL X0FDQ0VTU19BUEk9eQpDT05GSUdfSEFWRV9DTEs9eQpDT05GSUdfSEFWRV9ETUFfQVBJX0RF QlVHPXkKQ09ORklHX0hBVkVfSFdfQlJFQUtQT0lOVD15CkNPTkZJR19IQVZFX1BFUkZfUkVH Uz15CkNPTkZJR19IQVZFX1BFUkZfVVNFUl9TVEFDS19EVU1QPXkKQ09ORklHX0hBVkVfQVJD SF9KVU1QX0xBQkVMPXkKQ09ORklHX0FSQ0hfV0FOVF9JUENfUEFSU0VfVkVSU0lPTj15CkNP TkZJR19IQVZFX0FSQ0hfU0VDQ09NUF9GSUxURVI9eQpDT05GSUdfSEFWRV9DQ19TVEFDS1BS T1RFQ1RPUj15CiMgQ09ORklHX0NDX1NUQUNLUFJPVEVDVE9SIGlzIG5vdCBzZXQKQ09ORklH X0NDX1NUQUNLUFJPVEVDVE9SX05PTkU9eQojIENPTkZJR19DQ19TVEFDS1BST1RFQ1RPUl9S RUdVTEFSIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0NfU1RBQ0tQUk9URUNUT1JfU1RST05HIGlz IG5vdCBzZXQKQ09ORklHX0hBVkVfQ09OVEVYVF9UUkFDS0lORz15CkNPTkZJR19IQVZFX1ZJ UlRfQ1BVX0FDQ09VTlRJTkdfR0VOPXkKQ09ORklHX0hBVkVfSVJRX1RJTUVfQUNDT1VOVElO Rz15CkNPTkZJR19IQVZFX0FSQ0hfVFJBTlNQQVJFTlRfSFVHRVBBR0U9eQpDT05GSUdfTU9E VUxFU19VU0VfRUxGX1JFTD15CkNPTkZJR19DTE9ORV9CQUNLV0FSRFM9eQpDT05GSUdfT0xE X1NJR1NVU1BFTkQzPXkKQ09ORklHX09MRF9TSUdBQ1RJT049eQoKIwojIEdDT1YtYmFzZWQg a2VybmVsIHByb2ZpbGluZwojCiMgQ09ORklHX0dDT1ZfS0VSTkVMIGlzIG5vdCBzZXQKQ09O RklHX0hBVkVfR0VORVJJQ19ETUFfQ09IRVJFTlQ9eQpDT05GSUdfU0xBQklORk89eQpDT05G SUdfUlRfTVVURVhFUz15CkNPTkZJR19CQVNFX1NNQUxMPTAKQ09ORklHX01PRFVMRVM9eQpD T05GSUdfTU9EVUxFX0ZPUkNFX0xPQUQ9eQpDT05GSUdfTU9EVUxFX1VOTE9BRD15CkNPTkZJ R19NT0RVTEVfRk9SQ0VfVU5MT0FEPXkKQ09ORklHX01PRFZFUlNJT05TPXkKQ09ORklHX01P RFVMRV9TUkNWRVJTSU9OX0FMTD15CiMgQ09ORklHX01PRFVMRV9TSUcgaXMgbm90IHNldApD T05GSUdfU1RPUF9NQUNISU5FPXkKQ09ORklHX0JMT0NLPXkKQ09ORklHX0xCREFGPXkKIyBD T05GSUdfQkxLX0RFVl9CU0cgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0JTR0xJQiBp cyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZfSU5URUdSSVRZIGlzIG5vdCBzZXQKIyBDT05G SUdfQkxLX0NNRExJTkVfUEFSU0VSIGlzIG5vdCBzZXQKCiMKIyBQYXJ0aXRpb24gVHlwZXMK IwpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkKIyBDT05GSUdfQUNPUk5fUEFSVElUSU9O IGlzIG5vdCBzZXQKIyBDT05GSUdfQUlYX1BBUlRJVElPTiBpcyBub3Qgc2V0CiMgQ09ORklH X09TRl9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19BTUlHQV9QQVJUSVRJT04gaXMg bm90IHNldAojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19N QUNfUEFSVElUSU9OIGlzIG5vdCBzZXQKQ09ORklHX01TRE9TX1BBUlRJVElPTj15CiMgQ09O RklHX0JTRF9ESVNLTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19NSU5JWF9TVUJQQVJUSVRJ T04gaXMgbm90IHNldAojIENPTkZJR19TT0xBUklTX1g4Nl9QQVJUSVRJT04gaXMgbm90IHNl dAojIENPTkZJR19VTklYV0FSRV9ESVNLTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19MRE1f UEFSVElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfU0dJX1BBUlRJVElPTiBpcyBub3Qgc2V0 CiMgQ09ORklHX1VMVFJJWF9QQVJUSVRJT04gaXMgbm90IHNldAojIENPTkZJR19TVU5fUEFS VElUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfS0FSTUFfUEFSVElUSU9OIGlzIG5vdCBzZXQK Q09ORklHX0VGSV9QQVJUSVRJT049eQojIENPTkZJR19TWVNWNjhfUEFSVElUSU9OIGlzIG5v dCBzZXQKIyBDT05GSUdfQ01ETElORV9QQVJUSVRJT04gaXMgbm90IHNldAoKIwojIElPIFNj aGVkdWxlcnMKIwpDT05GSUdfSU9TQ0hFRF9OT09QPXkKQ09ORklHX0lPU0NIRURfREVBRExJ TkU9eQpDT05GSUdfSU9TQ0hFRF9DRlE9eQojIENPTkZJR19ERUZBVUxUX0RFQURMSU5FIGlz IG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfQ0ZRPXkKIyBDT05GSUdfREVGQVVMVF9OT09QIGlz IG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfSU9TQ0hFRD0iY2ZxIgpDT05GSUdfVU5JTkxJTkVf U1BJTl9VTkxPQ0s9eQpDT05GSUdfQVJDSF9TVVBQT1JUU19BVE9NSUNfUk1XPXkKQ09ORklH X01VVEVYX1NQSU5fT05fT1dORVI9eQpDT05GSUdfRlJFRVpFUj15CgojCiMgU3lzdGVtIFR5 cGUKIwpDT05GSUdfTU1VPXkKQ09ORklHX0FSQ0hfTVVMVElQTEFURk9STT15CiMgQ09ORklH X0FSQ0hfSU5URUdSQVRPUiBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfUkVBTFZJRVcgaXMg bm90IHNldAojIENPTkZJR19BUkNIX1ZFUlNBVElMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfQVQ5MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfQ0xQUzcxMVggaXMgbm90IHNldAoj IENPTkZJR19BUkNIX0dFTUlOSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfRUJTQTExMCBp cyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfRVA5M1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJD SF9GT09UQlJJREdFIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ORVRYIGlzIG5vdCBzZXQK IyBDT05GSUdfQVJDSF9JT1AxM1hYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9JT1AzMlgg aXMgbm90IHNldAojIENPTkZJR19BUkNIX0lPUDMzWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfSVhQNFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ET1ZFIGlzIG5vdCBzZXQKIyBD T05GSUdfQVJDSF9LSVJLV09PRCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVY3OFhYMCBp cyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfT1JJT041WCBpcyBub3Qgc2V0CiMgQ09ORklHX0FS Q0hfTU1QIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9LUzg2OTUgaXMgbm90IHNldAojIENP TkZJR19BUkNIX1c5MFg5MDAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX0xQQzMyWFggaXMg bm90IHNldAojIENPTkZJR19BUkNIX1BYQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVNN X05PRFQgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NITU9CSUxFX0xFR0FDWSBpcyBub3Qg c2V0CiMgQ09ORklHX0FSQ0hfUlBDIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9TQTExMDAg aXMgbm90IHNldAojIENPTkZJR19BUkNIX1MzQzI0WFggaXMgbm90IHNldAojIENPTkZJR19B UkNIX1MzQzY0WFggaXMgbm90IHNldAojIENPTkZJR19BUkNIX1M1UDY0WDAgaXMgbm90IHNl dAojIENPTkZJR19BUkNIX1M1UEMxMDAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1M1UFYy MTAgaXMgbm90IHNldAojIENPTkZJR19BUkNIX0VYWU5PUyBpcyBub3Qgc2V0CiMgQ09ORklH X0FSQ0hfREFWSU5DSSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfT01BUDEgaXMgbm90IHNl dAoKIwojIE11bHRpcGxlIHBsYXRmb3JtIHNlbGVjdGlvbgojCgojCiMgQ1BVIENvcmUgZmFt aWx5IHNlbGVjdGlvbgojCiMgQ09ORklHX0FSQ0hfTVVMVElfVjYgaXMgbm90IHNldApDT05G SUdfQVJDSF9NVUxUSV9WNz15CkNPTkZJR19BUkNIX01VTFRJX1Y2X1Y3PXkKIyBDT05GSUdf QVJDSF9NVUxUSV9DUFVfQVVUTyBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVZFQlUgaXMg bm90IHNldAojIENPTkZJR19BUkNIX0JDTSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfQkVS TElOIGlzIG5vdCBzZXQKQ09ORklHX0dQSU9fUENBOTUzWD15CiMgQ09ORklHX0tFWUJPQVJE X0dQSU9fUE9MTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9ISUdIQkFOSyBpcyBub3Qg c2V0CiMgQ09ORklHX0FSQ0hfSEkzeHh4IGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9LRVlT VE9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfTVNNX0RUIGlzIG5vdCBzZXQKIyBDT05G SUdfQVJDSF9NWEMgaXMgbm90IHNldAoKIwojIFRJIE9NQVAgQ29tbW9uIEZlYXR1cmVzCiMK CiMKIyBPTUFQIEZlYXR1cmUgU2VsZWN0aW9ucwojCkNPTkZJR19PTUFQX1JFU0VUX0NMT0NL Uz15CkNPTkZJR19PTUFQX01VWD15CkNPTkZJR19PTUFQX01VWF9ERUJVRz15CkNPTkZJR19P TUFQX01VWF9XQVJOSU5HUz15CkNPTkZJR19PTUFQXzMyS19USU1FUj15CkNPTkZJR19PTUFQ X0RNX1RJTUVSPXkKQ09ORklHX09NQVBfUE1fTk9PUD15CkNPTkZJR19NQUNIX09NQVBfR0VO RVJJQz15CkNPTkZJR19BUkNIX09NQVA9eQojIENPTkZJR19BUkNIX09NQVAzIGlzIG5vdCBz ZXQKIyBDT05GSUdfQVJDSF9PTUFQNCBpcyBub3Qgc2V0CiMgQ09ORklHX1NPQ19PTUFQNSBp cyBub3Qgc2V0CiMgQ09ORklHX1NPQ19BTTMzWFggaXMgbm90IHNldAojIENPTkZJR19TT0Nf QU00M1hYIGlzIG5vdCBzZXQKQ09ORklHX1NPQ19EUkE3WFg9eQpDT05GSUdfQVJDSF9PTUFQ MlBMVVM9eQoKIwojIFRJIE9NQVAyLzMvNCBTcGVjaWZpYyBGZWF0dXJlcwojCkNPTkZJR19B UkNIX09NQVAyUExVU19UWVBJQ0FMPXkKIyBDT05GSUdfU09DX0hBU19PTUFQMl9TRFJDIGlz IG5vdCBzZXQKQ09ORklHX1NPQ19IQVNfUkVBTFRJTUVfQ09VTlRFUj15CgojCiMgT01BUCBM ZWdhY3kgUGxhdGZvcm0gRGF0YSBCb2FyZCBUeXBlCiMKIyBDT05GSUdfQVJDSF9ST0NLQ0hJ UCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU09DRlBHQSBpcyBub3Qgc2V0CiMgQ09ORklH X1BMQVRfU1BFQVIgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NUSSBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfU0hNT0JJTEVfTVVMVEkgaXMgbm90IHNldAojIENPTkZJR19BUkNIX1NV TlhJIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9TSVJGIGlzIG5vdCBzZXQKIyBDT05GSUdf QVJDSF9URUdSQSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfVTg1MDAgaXMgbm90IHNldAoj IENPTkZJR19BUkNIX1ZFWFBSRVNTIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJDSF9WSVJUIGlz IG5vdCBzZXQKIyBDT05GSUdfQVJDSF9XTTg4NTAgaXMgbm90IHNldAojIENPTkZJR19BUkNI X1pZTlEgaXMgbm90IHNldAoKIwojIFByb2Nlc3NvciBUeXBlCiMKQ09ORklHX0NQVV9WNz15 CkNPTkZJR19DUFVfMzJ2Nks9eQpDT05GSUdfQ1BVXzMydjc9eQpDT05GSUdfQ1BVX0FCUlRf RVY3PXkKQ09ORklHX0NQVV9QQUJSVF9WNz15CkNPTkZJR19DUFVfQ0FDSEVfVjc9eQpDT05G SUdfQ1BVX0NBQ0hFX1ZJUFQ9eQpDT05GSUdfQ1BVX0NPUFlfVjY9eQpDT05GSUdfQ1BVX1RM Ql9WNz15CkNPTkZJR19DUFVfSEFTX0FTSUQ9eQpDT05GSUdfQ1BVX0NQMTU9eQpDT05GSUdf Q1BVX0NQMTVfTU1VPXkKCiMKIyBQcm9jZXNzb3IgRmVhdHVyZXMKIwpDT05GSUdfQVJNX0xQ QUU9eQpDT05GSUdfQVJDSF9QSFlTX0FERFJfVF82NEJJVD15CkNPTkZJR19BUkNIX0RNQV9B RERSX1RfNjRCSVQ9eQpDT05GSUdfQVJNX1RIVU1CPXkKQ09ORklHX0FSTV9USFVNQkVFPXkK Q09ORklHX0FSTV9WSVJUX0VYVD15CkNPTkZJR19TV1BfRU1VTEFURT15CiMgQ09ORklHX0NQ VV9JQ0FDSEVfRElTQUJMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9EQ0FDSEVfRElTQUJM RSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9CUFJFRElDVF9ESVNBQkxFIGlzIG5vdCBzZXQK Q09ORklHX0tVU0VSX0hFTFBFUlM9eQojIENPTkZJR19DQUNIRV9MMlgwIGlzIG5vdCBzZXQK Q09ORklHX0FSTV9MMV9DQUNIRV9TSElGVF82PXkKQ09ORklHX0FSTV9MMV9DQUNIRV9TSElG VD02CkNPTkZJR19BUk1fRE1BX01FTV9CVUZGRVJBQkxFPXkKQ09ORklHX0FSTV9OUl9CQU5L Uz04CkNPTkZJR19NVUxUSV9JUlFfSEFORExFUj15CiMgQ09ORklHX0FSTV9FUlJBVEFfNDMw OTczIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV82NDM3MTkgaXMgbm90IHNldAoj IENPTkZJR19BUk1fRVJSQVRBXzcyMDc4OSBpcyBub3Qgc2V0CiMgQ09ORklHX0FSTV9FUlJB VEFfNzU0MzIyIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV83NTQzMjcgaXMgbm90 IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzc2NDM2OSBpcyBub3Qgc2V0CiMgQ09ORklHX0FS TV9FUlJBVEFfNzc1NDIwIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX0VSUkFUQV83OTgxODEg aXMgbm90IHNldAojIENPTkZJR19BUk1fRVJSQVRBXzc3MzAyMiBpcyBub3Qgc2V0CkNPTkZJ R19USV9QUklWX0VETUE9eQoKIwojIEJ1cyBzdXBwb3J0CiMKQ09ORklHX1BDST15CkNPTkZJ R19QQ0lfU1lTQ0FMTD15CiMgQ09ORklHX1BDSV9NU0kgaXMgbm90IHNldAojIENPTkZJR19Q Q0lfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QQ0lfUkVBTExPQ19FTkFCTEVfQVVUTyBp cyBub3Qgc2V0CiMgQ09ORklHX1BDSV9TVFVCIGlzIG5vdCBzZXQKIyBDT05GSUdfUENJX0lP ViBpcyBub3Qgc2V0CiMgQ09ORklHX1BDSV9QUkkgaXMgbm90IHNldAojIENPTkZJR19QQ0lf UEFTSUQgaXMgbm90IHNldAoKIwojIFBDSSBob3N0IGNvbnRyb2xsZXIgZHJpdmVycwojCkNP TkZJR19QQ0lfRFJBN1hYPXkKQ09ORklHX1BDSUVfRFc9eQojIENPTkZJR19QQ0lFUE9SVEJV UyBpcyBub3Qgc2V0CiMgQ09ORklHX1BDQ0FSRCBpcyBub3Qgc2V0CgojCiMgS2VybmVsIEZl YXR1cmVzCiMKQ09ORklHX0hBVkVfU01QPXkKQ09ORklHX1NNUD15CkNPTkZJR19TTVBfT05f VVA9eQpDT05GSUdfQVJNX0NQVV9UT1BPTE9HWT15CiMgQ09ORklHX1NDSEVEX01DIGlzIG5v dCBzZXQKIyBDT05GSUdfU0NIRURfU01UIGlzIG5vdCBzZXQKQ09ORklHX0hBVkVfQVJNX0FS Q0hfVElNRVI9eQojIENPTkZJR19NQ1BNIGlzIG5vdCBzZXQKIyBDT05GSUdfQklHX0xJVFRM RSBpcyBub3Qgc2V0CkNPTkZJR19WTVNQTElUXzNHPXkKIyBDT05GSUdfVk1TUExJVF8yRyBp cyBub3Qgc2V0CiMgQ09ORklHX1ZNU1BMSVRfMUcgaXMgbm90IHNldApDT05GSUdfUEFHRV9P RkZTRVQ9MHhDMDAwMDAwMApDT05GSUdfTlJfQ1BVUz0yCkNPTkZJR19IT1RQTFVHX0NQVT15 CkNPTkZJR19BUk1fUFNDST15CkNPTkZJR19BUkNIX05SX0dQSU89NTEyCiMgQ09ORklHX1BS RUVNUFRfTk9ORSBpcyBub3Qgc2V0CiMgQ09ORklHX1BSRUVNUFRfVk9MVU5UQVJZIGlzIG5v dCBzZXQKQ09ORklHX1BSRUVNUFQ9eQpDT05GSUdfUFJFRU1QVF9DT1VOVD15CkNPTkZJR19I Wl9GSVhFRD0wCkNPTkZJR19IWl8xMDA9eQojIENPTkZJR19IWl8yMDAgaXMgbm90IHNldAoj IENPTkZJR19IWl8yNTAgaXMgbm90IHNldAojIENPTkZJR19IWl8zMDAgaXMgbm90IHNldAoj IENPTkZJR19IWl81MDAgaXMgbm90IHNldAojIENPTkZJR19IWl8xMDAwIGlzIG5vdCBzZXQK Q09ORklHX0haPTEwMApDT05GSUdfU0NIRURfSFJUSUNLPXkKIyBDT05GSUdfVEhVTUIyX0tF Uk5FTCBpcyBub3Qgc2V0CkNPTkZJR19BRUFCST15CiMgQ09ORklHX09BQklfQ09NUEFUIGlz IG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX0hPTEVTX01FTU9SWU1PREVMPXkKIyBDT05GSUdf QVJDSF9TUEFSU0VNRU1fREVGQVVMVCBpcyBub3Qgc2V0CiMgQ09ORklHX0FSQ0hfU0VMRUNU X01FTU9SWV9NT0RFTCBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0FSQ0hfUEZOX1ZBTElEPXkK Q09ORklHX0hJR0hNRU09eQojIENPTkZJR19ISUdIUFRFIGlzIG5vdCBzZXQKQ09ORklHX0hX X1BFUkZfRVZFTlRTPXkKQ09ORklHX1NZU19TVVBQT1JUU19IVUdFVExCRlM9eQpDT05GSUdf QVJDSF9XQU5UX0dFTkVSQUxfSFVHRVRMQj15CkNPTkZJR19GTEFUTUVNPXkKQ09ORklHX0ZM QVRfTk9ERV9NRU1fTUFQPXkKQ09ORklHX0hBVkVfTUVNQkxPQ0s9eQpDT05GSUdfTk9fQk9P VE1FTT15CkNPTkZJR19NRU1PUllfSVNPTEFUSU9OPXkKIyBDT05GSUdfSEFWRV9CT09UTUVN X0lORk9fTk9ERSBpcyBub3Qgc2V0CkNPTkZJR19QQUdFRkxBR1NfRVhURU5ERUQ9eQpDT05G SUdfU1BMSVRfUFRMT0NLX0NQVVM9NApDT05GSUdfQ09NUEFDVElPTj15CkNPTkZJR19NSUdS QVRJT049eQpDT05GSUdfUEhZU19BRERSX1RfNjRCSVQ9eQpDT05GSUdfWk9ORV9ETUFfRkxB Rz0wCkNPTkZJR19CT1VOQ0U9eQpDT05GSUdfTU1VX05PVElGSUVSPXkKIyBDT05GSUdfS1NN IGlzIG5vdCBzZXQKQ09ORklHX0RFRkFVTFRfTU1BUF9NSU5fQUREUj00MDk2CiMgQ09ORklH X1RSQU5TUEFSRU5UX0hVR0VQQUdFIGlzIG5vdCBzZXQKQ09ORklHX0NST1NTX01FTU9SWV9B VFRBQ0g9eQojIENPTkZJR19DTEVBTkNBQ0hFIGlzIG5vdCBzZXQKIyBDT05GSUdfRlJPTlRT V0FQIGlzIG5vdCBzZXQKQ09ORklHX0NNQT15CiMgQ09ORklHX0NNQV9ERUJVRyBpcyBub3Qg c2V0CiMgQ09ORklHX1pCVUQgaXMgbm90IHNldAojIENPTkZJR19aU01BTExPQyBpcyBub3Qg c2V0CkNPTkZJR19GT1JDRV9NQVhfWk9ORU9SREVSPTExCkNPTkZJR19BTElHTk1FTlRfVFJB UD15CiMgQ09ORklHX1VBQ0NFU1NfV0lUSF9NRU1DUFkgaXMgbm90IHNldAojIENPTkZJR19T RUNDT01QIGlzIG5vdCBzZXQKQ09ORklHX1NXSU9UTEI9eQpDT05GSUdfSU9NTVVfSEVMUEVS PXkKQ09ORklHX1hFTl9ET00wPXkKQ09ORklHX1hFTj15CiMgQ09ORklHX0FSTV9GTFVTSF9D T05TT0xFX09OX1JFU1RBUlQgaXMgbm90IHNldAoKIwojIEJvb3Qgb3B0aW9ucwojCkNPTkZJ R19VU0VfT0Y9eQpDT05GSUdfQVRBR1M9eQojIENPTkZJR19ERVBSRUNBVEVEX1BBUkFNX1NU UlVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX0JVSUxEX0FSTV9BUFBFTkRFRF9EVEJfSU1BR0Ug aXMgbm90IHNldApDT05GSUdfWkJPT1RfUk9NX1RFWFQ9MHgwCkNPTkZJR19aQk9PVF9ST01f QlNTPTB4MApDT05GSUdfQVJNX0FQUEVOREVEX0RUQj15CkNPTkZJR19BUk1fQVRBR19EVEJf Q09NUEFUPXkKQ09ORklHX0FSTV9BVEFHX0RUQl9DT01QQVRfQ01ETElORV9GUk9NX0JPT1RM T0FERVI9eQojIENPTkZJR19BUk1fQVRBR19EVEJfQ09NUEFUX0NNRExJTkVfRVhURU5EIGlz IG5vdCBzZXQKQ09ORklHX0NNRExJTkU9InJvb3Q9L2Rldi9tbWNibGswcDIgcm9vdHdhaXQg Y29uc29sZT10dHlPMiwxMTUyMDAiCkNPTkZJR19DTURMSU5FX0ZST01fQk9PVExPQURFUj15 CiMgQ09ORklHX0NNRExJTkVfRVhURU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfQ01ETElORV9G T1JDRSBpcyBub3Qgc2V0CkNPTkZJR19LRVhFQz15CkNPTkZJR19BVEFHU19QUk9DPXkKIyBD T05GSUdfQ1JBU0hfRFVNUCBpcyBub3Qgc2V0CkNPTkZJR19BVVRPX1pSRUxBRERSPXkKCiMK IyBDUFUgUG93ZXIgTWFuYWdlbWVudAojCgojCiMgQ1BVIEZyZXF1ZW5jeSBzY2FsaW5nCiMK Q09ORklHX0NQVV9GUkVRPXkKQ09ORklHX0NQVV9GUkVRX0dPVl9DT01NT049eQpDT05GSUdf Q1BVX0ZSRVFfU1RBVD15CkNPTkZJR19DUFVfRlJFUV9TVEFUX0RFVEFJTFM9eQojIENPTkZJ R19DUFVfRlJFUV9ERUZBVUxUX0dPVl9QRVJGT1JNQU5DRSBpcyBub3Qgc2V0CiMgQ09ORklH X0NQVV9GUkVRX0RFRkFVTFRfR09WX1BPV0VSU0FWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQ VV9GUkVRX0RFRkFVTFRfR09WX1VTRVJTUEFDRSBpcyBub3Qgc2V0CkNPTkZJR19DUFVfRlJF UV9ERUZBVUxUX0dPVl9PTkRFTUFORD15CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09W X0NPTlNFUlZBVElWRSBpcyBub3Qgc2V0CiMgQ09ORklHX0NQVV9GUkVRX0RFRkFVTFRfR09W X0lOVEVSQUNUSVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dPVl9QRVJGT1JNQU5D RT15CkNPTkZJR19DUFVfRlJFUV9HT1ZfUE9XRVJTQVZFPW0KQ09ORklHX0NQVV9GUkVRX0dP Vl9VU0VSU1BBQ0U9bQpDT05GSUdfQ1BVX0ZSRVFfR09WX09OREVNQU5EPXkKIyBDT05GSUdf Q1BVX0ZSRVFfR09WX0lOVEVSQUNUSVZFIGlzIG5vdCBzZXQKQ09ORklHX0NQVV9GUkVRX0dP Vl9DT05TRVJWQVRJVkU9bQpDT05GSUdfR0VORVJJQ19DUFVGUkVRX0NQVTA9eQoKIwojIEFS TSBDUFUgZnJlcXVlbmN5IHNjYWxpbmcgZHJpdmVycwojCiMgQ09ORklHX0FSTV9LSVJLV09P RF9DUFVGUkVRIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX09NQVAyUExVU19DUFVGUkVRIGlz IG5vdCBzZXQKCiMKIyBDUFUgSWRsZQojCkNPTkZJR19DUFVfSURMRT15CiMgQ09ORklHX0NQ VV9JRExFX01VTFRJUExFX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfQ1BVX0lETEVfR09W X0xBRERFUj15CkNPTkZJR19DUFVfSURMRV9HT1ZfTUVOVT15CgojCiMgQVJNIENQVSBJZGxl IERyaXZlcnMKIwojIENPTkZJR19BUk1fSElHSEJBTktfQ1BVSURMRSBpcyBub3Qgc2V0CiMg Q09ORklHX0FSQ0hfTkVFRFNfQ1BVX0lETEVfQ09VUExFRCBpcyBub3Qgc2V0CgojCiMgRmxv YXRpbmcgcG9pbnQgZW11bGF0aW9uCiMKCiMKIyBBdCBsZWFzdCBvbmUgZW11bGF0aW9uIG11 c3QgYmUgc2VsZWN0ZWQKIwpDT05GSUdfVkZQPXkKQ09ORklHX1ZGUHYzPXkKQ09ORklHX05F T049eQojIENPTkZJR19LRVJORUxfTU9ERV9ORU9OIGlzIG5vdCBzZXQKCiMKIyBVc2Vyc3Bh Y2UgYmluYXJ5IGZvcm1hdHMKIwpDT05GSUdfQklORk1UX0VMRj15CkNPTkZJR19BUkNIX0JJ TkZNVF9FTEZfUkFORE9NSVpFX1BJRT15CkNPTkZJR19DT1JFX0RVTVBfREVGQVVMVF9FTEZf SEVBREVSUz15CkNPTkZJR19CSU5GTVRfU0NSSVBUPXkKIyBDT05GSUdfSEFWRV9BT1VUIGlz IG5vdCBzZXQKQ09ORklHX0JJTkZNVF9NSVNDPXkKQ09ORklHX0NPUkVEVU1QPXkKCiMKIyBQ b3dlciBtYW5hZ2VtZW50IG9wdGlvbnMKIwpDT05GSUdfU1VTUEVORD15CkNPTkZJR19TVVNQ RU5EX0ZSRUVaRVI9eQpDT05GSUdfSEFTX1dBS0VMT0NLPXkKQ09ORklHX1dBS0VMT0NLPXkK Q09ORklHX1BNX1NMRUVQPXkKQ09ORklHX1BNX1NMRUVQX1NNUD15CiMgQ09ORklHX1BNX0FV VE9TTEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX1BNX1dBS0VMT0NLUyBpcyBub3Qgc2V0CkNP TkZJR19QTV9SVU5USU1FPXkKQ09ORklHX1BNPXkKQ09ORklHX1BNX0RFQlVHPXkKIyBDT05G SUdfUE1fQURWQU5DRURfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19QTV9URVNUX1NVU1BF TkQgaXMgbm90IHNldApDT05GSUdfUE1fU0xFRVBfREVCVUc9eQojIENPTkZJR19BUE1fRU1V TEFUSU9OIGlzIG5vdCBzZXQKQ09ORklHX0FSQ0hfSEFTX09QUD15CkNPTkZJR19QTV9PUFA9 eQpDT05GSUdfUE1fQ0xLPXkKIyBDT05GSUdfV1FfUE9XRVJfRUZGSUNJRU5UX0RFRkFVTFQg aXMgbm90IHNldApDT05GSUdfQ1BVX1BNPXkKIyBDT05GSUdfU1VTUEVORF9USU1FIGlzIG5v dCBzZXQKQ09ORklHX0FSQ0hfU1VTUEVORF9QT1NTSUJMRT15CkNPTkZJR19BUk1fQ1BVX1NV U1BFTkQ9eQpDT05GSUdfTkVUPXkKCiMKIyBOZXR3b3JraW5nIG9wdGlvbnMKIwpDT05GSUdf UEFDS0VUPXkKIyBDT05GSUdfUEFDS0VUX0RJQUcgaXMgbm90IHNldApDT05GSUdfVU5JWD15 CiMgQ09ORklHX1VOSVhfRElBRyBpcyBub3Qgc2V0CkNPTkZJR19YRlJNPXkKQ09ORklHX1hG Uk1fQUxHTz15CkNPTkZJR19YRlJNX1VTRVI9eQojIENPTkZJR19YRlJNX1NVQl9QT0xJQ1kg aXMgbm90IHNldApDT05GSUdfWEZSTV9NSUdSQVRFPXkKIyBDT05GSUdfWEZSTV9TVEFUSVNU SUNTIGlzIG5vdCBzZXQKQ09ORklHX05FVF9LRVk9eQpDT05GSUdfTkVUX0tFWV9NSUdSQVRF PXkKQ09ORklHX0lORVQ9eQpDT05GSUdfSVBfTVVMVElDQVNUPXkKIyBDT05GSUdfSVBfQURW QU5DRURfUk9VVEVSIGlzIG5vdCBzZXQKQ09ORklHX0lQX1BOUD15CkNPTkZJR19JUF9QTlBf REhDUD15CkNPTkZJR19JUF9QTlBfQk9PVFA9eQpDT05GSUdfSVBfUE5QX1JBUlA9eQojIENP TkZJR19ORVRfSVBJUCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9JUEdSRV9ERU1VWCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9JUF9UVU5ORUwgaXMgbm90IHNldAojIENPTkZJR19JUF9N Uk9VVEUgaXMgbm90IHNldAojIENPTkZJR19TWU5fQ09PS0lFUyBpcyBub3Qgc2V0CiMgQ09O RklHX05FVF9JUFZUSSBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfQUggaXMgbm90IHNldAoj IENPTkZJR19JTkVUX0VTUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lORVRfSVBDT01QIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5FVF9YRlJNX1RVTk5FTCBpcyBub3Qgc2V0CiMgQ09ORklHX0lO RVRfVFVOTkVMIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfWEZSTV9NT0RFX1RSQU5TUE9SVD15 CkNPTkZJR19JTkVUX1hGUk1fTU9ERV9UVU5ORUw9eQpDT05GSUdfSU5FVF9YRlJNX01PREVf QkVFVD15CiMgQ09ORklHX0lORVRfTFJPIGlzIG5vdCBzZXQKQ09ORklHX0lORVRfRElBRz15 CkNPTkZJR19JTkVUX1RDUF9ESUFHPXkKIyBDT05GSUdfSU5FVF9VRFBfRElBRyBpcyBub3Qg c2V0CiMgQ09ORklHX1RDUF9DT05HX0FEVkFOQ0VEIGlzIG5vdCBzZXQKQ09ORklHX1RDUF9D T05HX0NVQklDPXkKQ09ORklHX0RFRkFVTFRfVENQX0NPTkc9ImN1YmljIgojIENPTkZJR19U Q1BfTUQ1U0lHIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBWNiBpcyBub3Qgc2V0CiMgQ09ORklH X05FVExBQkVMIGlzIG5vdCBzZXQKQ09ORklHX0FORFJPSURfUEFSQU5PSURfTkVUV09SSz15 CkNPTkZJR19ORVRfQUNUSVZJVFlfU1RBVFM9eQojIENPTkZJR19ORVRXT1JLX1NFQ01BUksg aXMgbm90IHNldAojIENPTkZJR19ORVRXT1JLX1BIWV9USU1FU1RBTVBJTkcgaXMgbm90IHNl dApDT05GSUdfTkVURklMVEVSPXkKIyBDT05GSUdfTkVURklMVEVSX0RFQlVHIGlzIG5vdCBz ZXQKQ09ORklHX05FVEZJTFRFUl9BRFZBTkNFRD15CkNPTkZJR19CUklER0VfTkVURklMVEVS PXkKCiMKIyBDb3JlIE5ldGZpbHRlciBDb25maWd1cmF0aW9uCiMKIyBDT05GSUdfTkVURklM VEVSX05FVExJTktfQUNDVCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9ORVRMSU5L X1FVRVVFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX05FVExJTktfTE9HIGlzIG5v dCBzZXQKQ09ORklHX05GX0NPTk5UUkFDSz1tCiMgQ09ORklHX05GX0NPTk5UUkFDS19NQVJL IGlzIG5vdCBzZXQKQ09ORklHX05GX0NPTk5UUkFDS19QUk9DRlM9eQojIENPTkZJR19ORl9D T05OVFJBQ0tfRVZFTlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1RJTUVP VVQgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfVElNRVNUQU1QIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkZfQ1RfUFJPVE9fRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NU X1BST1RPX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9DVF9QUk9UT19VRFBMSVRFIGlz IG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX0FNQU5EQSBpcyBub3Qgc2V0CiMgQ09O RklHX05GX0NPTk5UUkFDS19GVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tf SDMyMyBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NPTk5UUkFDS19JUkMgaXMgbm90IHNldAoj IENPTkZJR19ORl9DT05OVFJBQ0tfTkVUQklPU19OUyBpcyBub3Qgc2V0CiMgQ09ORklHX05G X0NPTk5UUkFDS19TTk1QIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfQ09OTlRSQUNLX1BQVFAg aXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tfU0FORSBpcyBub3Qgc2V0CiMgQ09O RklHX05GX0NPTk5UUkFDS19TSVAgaXMgbm90IHNldAojIENPTkZJR19ORl9DT05OVFJBQ0tf VEZUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX0NUX05FVExJTksgaXMgbm90IHNldAojIENP TkZJR19ORl9DVF9ORVRMSU5LX1RJTUVPVVQgaXMgbm90IHNldApDT05GSUdfTkZfTkFUPW0K Q09ORklHX05GX05BVF9ORUVERUQ9eQojIENPTkZJR19ORl9OQVRfQU1BTkRBIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkZfTkFUX0ZUUCBpcyBub3Qgc2V0CiMgQ09ORklHX05GX05BVF9JUkMg aXMgbm90IHNldAojIENPTkZJR19ORl9OQVRfU0lQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZf TkFUX1RGVFAgaXMgbm90IHNldAojIENPTkZJR19ORl9UQUJMRVMgaXMgbm90IHNldApDT05G SUdfTkVURklMVEVSX1hUQUJMRVM9bQoKIwojIFh0YWJsZXMgY29tYmluZWQgbW9kdWxlcwoj CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklM VEVSX1hUX0NPTk5NQVJLIGlzIG5vdCBzZXQKCiMKIyBYdGFibGVzIHRhcmdldHMKIwojIENP TkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX0NMQVNTSUZZIGlzIG5vdCBzZXQKIyBDT05GSUdf TkVURklMVEVSX1hUX1RBUkdFVF9DT05OTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJ TFRFUl9YVF9UQVJHRVRfSE1BUksgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf VEFSR0VUX0lETEVUSU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9UQVJH RVRfTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9MT0cgaXMg bm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX01BUksgaXMgbm90IHNldAoj IENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX05FVE1BUCBpcyBub3Qgc2V0CiMgQ09ORklH X05FVEZJTFRFUl9YVF9UQVJHRVRfTkZMT0cgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxU RVJfWFRfVEFSR0VUX05GUVVFVUUgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf VEFSR0VUX1JBVEVFU1QgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VU X1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX1RBUkdFVF9URUUg aXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfVEFSR0VUX1RDUE1TUyBpcyBub3Qg c2V0CgojCiMgWHRhYmxlcyBtYXRjaGVzCiMKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X0FERFJUWVBFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0JQRiBp cyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DR1JPVVAgaXMgbm90IHNl dAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfQ0xVU1RFUiBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9DT01NRU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVU RklMVEVSX1hUX01BVENIX0NPTk5CWVRFUyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRF Ul9YVF9NQVRDSF9DT05OTEFCRUwgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfQ09OTkxJTUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X0NPTk5NQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0NPTk5U UkFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9DUFUgaXMgbm90 IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfRENDUCBpcyBub3Qgc2V0CiMgQ09O RklHX05FVEZJTFRFUl9YVF9NQVRDSF9ERVZHUk9VUCBpcyBub3Qgc2V0CiMgQ09ORklHX05F VEZJTFRFUl9YVF9NQVRDSF9EU0NQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hU X01BVENIX0VDTiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9FU1Ag aXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfSEFTSExJTUlUIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0hFTFBFUiBpcyBub3Qgc2V0CiMg Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9ITCBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJ TFRFUl9YVF9NQVRDSF9JUENPTVAgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfSVBSQU5HRSBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9M MlRQIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX0xFTkdUSCBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9MSU1JVCBpcyBub3Qgc2V0CiMg Q09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9NQUMgaXMgbm90IHNldAojIENPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfTUFSSyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9N QVRDSF9NVUxUSVBPUlQgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hf TkZBQ0NUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX09XTkVSIGlz IG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1BPTElDWSBpcyBub3Qgc2V0 CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9QSFlTREVWIGlzIG5vdCBzZXQKIyBDT05G SUdfTkVURklMVEVSX1hUX01BVENIX1BLVFRZUEUgaXMgbm90IHNldAojIENPTkZJR19ORVRG SUxURVJfWFRfTUFUQ0hfUVVPVEEgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRf TUFUQ0hfUVVPVEEyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1JB VEVFU1QgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVBTE0gaXMg bm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfUkVDRU5UIGlzIG5vdCBzZXQK IyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1NDVFAgaXMgbm90IHNldAojIENPTkZJR19O RVRGSUxURVJfWFRfTUFUQ0hfU09DS0VUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVS X1hUX01BVENIX1NUQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENI X1NUQVRJU1RJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05FVEZJTFRFUl9YVF9NQVRDSF9TVFJJ TkcgaXMgbm90IHNldAojIENPTkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVENQTVNTIGlzIG5v dCBzZXQKIyBDT05GSUdfTkVURklMVEVSX1hUX01BVENIX1RJTUUgaXMgbm90IHNldAojIENP TkZJR19ORVRGSUxURVJfWFRfTUFUQ0hfVTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfU0VU IGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfVlMgaXMgbm90IHNldAoKIwojIElQOiBOZXRmaWx0 ZXIgQ29uZmlndXJhdGlvbgojCkNPTkZJR19ORl9ERUZSQUdfSVBWND1tCkNPTkZJR19ORl9D T05OVFJBQ0tfSVBWND1tCkNPTkZJR19ORl9DT05OVFJBQ0tfUFJPQ19DT01QQVQ9eQpDT05G SUdfSVBfTkZfSVBUQUJMRVM9bQojIENPTkZJR19JUF9ORl9NQVRDSF9BSCBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQX05GX01BVENIX0VDTiBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX01B VENIX1RUTCBpcyBub3Qgc2V0CkNPTkZJR19JUF9ORl9GSUxURVI9bQojIENPTkZJR19JUF9O Rl9UQVJHRVRfUkVKRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfVEFSR0VUX1NZTlBS T1hZIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfVEFSR0VUX1VMT0cgaXMgbm90IHNldApD T05GSUdfTkZfTkFUX0lQVjQ9bQpDT05GSUdfSVBfTkZfVEFSR0VUX01BU1FVRVJBREU9bQoj IENPTkZJR19JUF9ORl9UQVJHRVRfTkVUTUFQIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZf VEFSR0VUX1JFRElSRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkZfTkFUX1BQVFAgaXMgbm90 IHNldAojIENPTkZJR19ORl9OQVRfSDMyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX01B TkdMRSBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX05GX1JBVyBpcyBub3Qgc2V0CiMgQ09ORklH X0lQX05GX1NFQ1VSSVRZIGlzIG5vdCBzZXQKIyBDT05GSUdfSVBfTkZfQVJQVEFCTEVTIGlz IG5vdCBzZXQKIyBDT05GSUdfQlJJREdFX05GX0VCVEFCTEVTIGlzIG5vdCBzZXQKIyBDT05G SUdfSVBfRENDUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lQX1NDVFAgaXMgbm90IHNldAojIENP TkZJR19SRFMgaXMgbm90IHNldAojIENPTkZJR19USVBDIGlzIG5vdCBzZXQKIyBDT05GSUdf QVRNIGlzIG5vdCBzZXQKIyBDT05GSUdfTDJUUCBpcyBub3Qgc2V0CkNPTkZJR19TVFA9bQpD T05GSUdfQlJJREdFPW0KQ09ORklHX0JSSURHRV9JR01QX1NOT09QSU5HPXkKQ09ORklHX0hB VkVfTkVUX0RTQT15CiMgQ09ORklHX1ZMQU5fODAyMVEgaXMgbm90IHNldAojIENPTkZJR19E RUNORVQgaXMgbm90IHNldApDT05GSUdfTExDPW0KIyBDT05GSUdfTExDMiBpcyBub3Qgc2V0 CiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0CiMgQ09ORklHX0FUQUxLIGlzIG5vdCBzZXQKIyBD T05GSUdfWDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfTEFQQiBpcyBub3Qgc2V0CiMgQ09ORklH X1BIT05FVCBpcyBub3Qgc2V0CiMgQ09ORklHX0lFRUU4MDIxNTQgaXMgbm90IHNldApDT05G SUdfNkxPV1BBTl9JUEhDPW0KIyBDT05GSUdfTkVUX1NDSEVEIGlzIG5vdCBzZXQKIyBDT05G SUdfRENCIGlzIG5vdCBzZXQKQ09ORklHX0ROU19SRVNPTFZFUj15CiMgQ09ORklHX0JBVE1B Tl9BRFYgaXMgbm90IHNldAojIENPTkZJR19PUEVOVlNXSVRDSCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZTT0NLRVRTIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUTElOS19NTUFQIGlzIG5vdCBz ZXQKIyBDT05GSUdfTkVUTElOS19ESUFHIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX01QTFNf R1NPIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNSIGlzIG5vdCBzZXQKQ09ORklHX1JQUz15CkNP TkZJR19SRlNfQUNDRUw9eQpDT05GSUdfWFBTPXkKIyBDT05GSUdfQ0dST1VQX05FVF9QUklP IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0dST1VQX05FVF9DTEFTU0lEIGlzIG5vdCBzZXQKQ09O RklHX05FVF9SWF9CVVNZX1BPTEw9eQpDT05GSUdfQlFMPXkKIyBDT05GSUdfQlBGX0pJVCBp cyBub3Qgc2V0CkNPTkZJR19ORVRfRkxPV19MSU1JVD15CgojCiMgTmV0d29yayB0ZXN0aW5n CiMKIyBDT05GSUdfTkVUX1BLVEdFTiBpcyBub3Qgc2V0CiMgQ09ORklHX05FVF9UQ1BQUk9C RSBpcyBub3Qgc2V0CiMgQ09ORklHX0hBTVJBRElPIGlzIG5vdCBzZXQKQ09ORklHX0NBTj1t CkNPTkZJR19DQU5fUkFXPW0KQ09ORklHX0NBTl9CQ009bQpDT05GSUdfQ0FOX0dXPW0KCiMK IyBDQU4gRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19DQU5fVkNBTiBpcyBub3Qgc2V0CiMg Q09ORklHX0NBTl9TTENBTiBpcyBub3Qgc2V0CkNPTkZJR19DQU5fREVWPW0KQ09ORklHX0NB Tl9DQUxDX0JJVFRJTUlORz15CiMgQ09ORklHX0NBTl9MRURTIGlzIG5vdCBzZXQKIyBDT05G SUdfQ0FOX0FUOTEgaXMgbm90IHNldAojIENPTkZJR19DQU5fVElfSEVDQyBpcyBub3Qgc2V0 CiMgQ09ORklHX0NBTl9NQ1AyNTFYIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0ZMRVhDQU4g aXMgbm90IHNldAojIENPTkZJR19QQ0hfQ0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0dS Q0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX1NKQTEwMDAgaXMgbm90IHNldApDT05GSUdf Q0FOX0NfQ0FOPW0KQ09ORklHX0NBTl9DX0NBTl9QTEFURk9STT1tCiMgQ09ORklHX0NBTl9D X0NBTl9QQ0kgaXMgbm90IHNldAojIENPTkZJR19DQU5fQ0M3NzAgaXMgbm90IHNldAoKIwoj IENBTiBVU0IgaW50ZXJmYWNlcwojCiMgQ09ORklHX0NBTl9FTVNfVVNCIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0FOX0VTRF9VU0IyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0FOX0tWQVNFUl9V U0IgaXMgbm90IHNldAojIENPTkZJR19DQU5fUEVBS19VU0IgaXMgbm90IHNldAojIENPTkZJ R19DQU5fOERFVl9VU0IgaXMgbm90IHNldAojIENPTkZJR19DQU5fU09GVElORyBpcyBub3Qg c2V0CiMgQ09ORklHX0NBTl9ERUJVR19ERVZJQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfSVJE QSBpcyBub3Qgc2V0CkNPTkZJR19CVD1tCiMgQ09ORklHX0JUX1JGQ09NTSBpcyBub3Qgc2V0 CiMgQ09ORklHX0JUX0JORVAgaXMgbm90IHNldAojIENPTkZJR19CVF9ISURQIGlzIG5vdCBz ZXQKCiMKIyBCbHVldG9vdGggZGV2aWNlIGRyaXZlcnMKIwojIENPTkZJR19CVF9IQ0lCVFVT QiBpcyBub3Qgc2V0CiMgQ09ORklHX0JUX0hDSUJUU0RJTyBpcyBub3Qgc2V0CkNPTkZJR19C VF9IQ0lVQVJUPW0KQ09ORklHX0JUX0hDSVVBUlRfSDQ9eQpDT05GSUdfQlRfSENJVUFSVF9C Q1NQPXkKIyBDT05GSUdfQlRfSENJVUFSVF9BVEgzSyBpcyBub3Qgc2V0CkNPTkZJR19CVF9I Q0lVQVJUX0xMPXkKIyBDT05GSUdfQlRfSENJVUFSVF8zV0lSRSBpcyBub3Qgc2V0CkNPTkZJ R19CVF9IQ0lCQ00yMDNYPW0KQ09ORklHX0JUX0hDSUJQQTEwWD1tCiMgQ09ORklHX0JUX0hD SUJGVVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfQlRfSENJVkhDSSBpcyBub3Qgc2V0CiMgQ09O RklHX0JUX01SVkwgaXMgbm90IHNldApDT05GSUdfQlRfV0lMSU5LPW0KIyBDT05GSUdfQUZf UlhSUEMgaXMgbm90IHNldApDT05GSUdfV0lSRUxFU1M9eQojIENPTkZJR19DRkc4MDIxMSBp cyBub3Qgc2V0CiMgQ09ORklHX0xJQjgwMjExIGlzIG5vdCBzZXQKCiMKIyBDRkc4MDIxMSBu ZWVkcyB0byBiZSBlbmFibGVkIGZvciBNQUM4MDIxMQojCiMgQ09ORklHX1dJTUFYIGlzIG5v dCBzZXQKQ09ORklHX1JGS0lMTD15CkNPTkZJR19SRktJTExfUE09eQpDT05GSUdfUkZLSUxM X0xFRFM9eQojIENPTkZJR19SRktJTExfSU5QVVQgaXMgbm90IHNldAojIENPTkZJR19SRktJ TExfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfUkZLSUxMX0dQSU8gaXMgbm90IHNl dAojIENPTkZJR19ORVRfOVAgaXMgbm90IHNldAojIENPTkZJR19DQUlGIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0VQSF9MSUIgaXMgbm90IHNldAojIENPTkZJR19ORkMgaXMgbm90IHNldApD T05GSUdfSEFWRV9CUEZfSklUPXkKCiMKIyBEZXZpY2UgRHJpdmVycwojCgojCiMgR2VuZXJp YyBEcml2ZXIgT3B0aW9ucwojCkNPTkZJR19VRVZFTlRfSEVMUEVSX1BBVEg9Ii9zYmluL2hv dHBsdWciCkNPTkZJR19ERVZUTVBGUz15CkNPTkZJR19ERVZUTVBGU19NT1VOVD15CkNPTkZJ R19TVEFOREFMT05FPXkKQ09ORklHX1BSRVZFTlRfRklSTVdBUkVfQlVJTEQ9eQpDT05GSUdf RldfTE9BREVSPXkKQ09ORklHX0ZJUk1XQVJFX0lOX0tFUk5FTD15CkNPTkZJR19FWFRSQV9G SVJNV0FSRT0iIgpDT05GSUdfRldfTE9BREVSX1VTRVJfSEVMUEVSPXkKIyBDT05GSUdfREVC VUdfRFJJVkVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfREVWUkVTIGlzIG5vdCBzZXQK Q09ORklHX1NZU19IWVBFUlZJU09SPXkKIyBDT05GSUdfR0VORVJJQ19DUFVfREVWSUNFUyBp cyBub3Qgc2V0CiMgQ09ORklHX0hBVkVfQ1BVX0FVVE9QUk9CRSBpcyBub3Qgc2V0CkNPTkZJ R19TT0NfQlVTPXkKQ09ORklHX1JFR01BUD15CkNPTkZJR19SRUdNQVBfSTJDPXkKQ09ORklH X1JFR01BUF9TUEk9eQpDT05GSUdfUkVHTUFQX01NSU89eQpDT05GSUdfUkVHTUFQX0lSUT15 CkNPTkZJR19ETUFfU0hBUkVEX0JVRkZFUj15CkNPTkZJR19ETUFfQ01BPXkKCiMKIyBEZWZh dWx0IGNvbnRpZ3VvdXMgbWVtb3J5IGFyZWEgc2l6ZToKIwpDT05GSUdfQ01BX1NJWkVfTUJZ VEVTPTI0CkNPTkZJR19DTUFfU0laRV9TRUxfTUJZVEVTPXkKIyBDT05GSUdfQ01BX1NJWkVf U0VMX1BFUkNFTlRBR0UgaXMgbm90IHNldAojIENPTkZJR19DTUFfU0laRV9TRUxfTUlOIGlz IG5vdCBzZXQKIyBDT05GSUdfQ01BX1NJWkVfU0VMX01BWCBpcyBub3Qgc2V0CkNPTkZJR19D TUFfQUxJR05NRU5UPTgKQ09ORklHX0NNQV9BUkVBUz03CgojCiMgQnVzIGRldmljZXMKIwpD T05GSUdfT01BUF9PQ1AyU0NQPXkKIyBDT05GSUdfT01BUF9JTlRFUkNPTk5FQ1QgaXMgbm90 IHNldAojIENPTkZJR19BUk1fQ0NJIGlzIG5vdCBzZXQKQ09ORklHX0NPTk5FQ1RPUj15CkNP TkZJR19QUk9DX0VWRU5UUz15CkNPTkZJR19NVEQ9eQpDT05GSUdfTVREX1RFU1RTPW0KIyBD T05GSUdfTVREX1JFREJPT1RfUEFSVFMgaXMgbm90IHNldApDT05GSUdfTVREX0NNRExJTkVf UEFSVFM9eQojIENPTkZJR19NVERfQUZTX1BBUlRTIGlzIG5vdCBzZXQKQ09ORklHX01URF9P Rl9QQVJUUz15CiMgQ09ORklHX01URF9BUjdfUEFSVFMgaXMgbm90IHNldAoKIwojIFVzZXIg TW9kdWxlcyBBbmQgVHJhbnNsYXRpb24gTGF5ZXJzCiMKQ09ORklHX01URF9CTEtERVZTPXkK Q09ORklHX01URF9CTE9DSz15CiMgQ09ORklHX0ZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX05G VEwgaXMgbm90IHNldAojIENPTkZJR19JTkZUTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JGRF9G VEwgaXMgbm90IHNldAojIENPTkZJR19TU0ZEQyBpcyBub3Qgc2V0CiMgQ09ORklHX1NNX0ZU TCBpcyBub3Qgc2V0CkNPTkZJR19NVERfT09QUz15CiMgQ09ORklHX01URF9TV0FQIGlzIG5v dCBzZXQKCiMKIyBSQU0vUk9NL0ZsYXNoIGNoaXAgZHJpdmVycwojCkNPTkZJR19NVERfQ0ZJ PXkKIyBDT05GSUdfTVREX0pFREVDUFJPQkUgaXMgbm90IHNldApDT05GSUdfTVREX0dFTl9Q Uk9CRT15CiMgQ09ORklHX01URF9DRklfQURWX09QVElPTlMgaXMgbm90IHNldApDT05GSUdf TVREX01BUF9CQU5LX1dJRFRIXzE9eQpDT05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzI9eQpD T05GSUdfTVREX01BUF9CQU5LX1dJRFRIXzQ9eQojIENPTkZJR19NVERfTUFQX0JBTktfV0lE VEhfOCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8xNiBpcyBub3Qg c2V0CiMgQ09ORklHX01URF9NQVBfQkFOS19XSURUSF8zMiBpcyBub3Qgc2V0CkNPTkZJR19N VERfQ0ZJX0kxPXkKQ09ORklHX01URF9DRklfSTI9eQojIENPTkZJR19NVERfQ0ZJX0k0IGlz IG5vdCBzZXQKIyBDT05GSUdfTVREX0NGSV9JOCBpcyBub3Qgc2V0CkNPTkZJR19NVERfQ0ZJ X0lOVEVMRVhUPXkKIyBDT05GSUdfTVREX0NGSV9BTURTVEQgaXMgbm90IHNldAojIENPTkZJ R19NVERfQ0ZJX1NUQUEgaXMgbm90IHNldApDT05GSUdfTVREX0NGSV9VVElMPXkKIyBDT05G SUdfTVREX1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9ST00gaXMgbm90IHNldAojIENP TkZJR19NVERfQUJTRU5UIGlzIG5vdCBzZXQKCiMKIyBNYXBwaW5nIGRyaXZlcnMgZm9yIGNo aXAgYWNjZXNzCiMKIyBDT05GSUdfTVREX0NPTVBMRVhfTUFQUElOR1MgaXMgbm90IHNldAoj IENPTkZJR19NVERfUEhZU01BUCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9QSFlTTUFQX09G IGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX0lOVEVMX1ZSX05PUiBpcyBub3Qgc2V0CiMgQ09O RklHX01URF9QTEFUUkFNIGlzIG5vdCBzZXQKCiMKIyBTZWxmLWNvbnRhaW5lZCBNVEQgZGV2 aWNlIGRyaXZlcnMKIwojIENPTkZJR19NVERfUE1DNTUxIGlzIG5vdCBzZXQKIyBDT05GSUdf TVREX0RBVEFGTEFTSCBpcyBub3Qgc2V0CkNPTkZJR19NVERfTTI1UDgwPW0KIyBDT05GSUdf TVREX1NTVDI1TCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9TTFJBTSBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9QSFJBTSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9NVERSQU0gaXMgbm90 IHNldAojIENPTkZJR19NVERfQkxPQ0syTVREIGlzIG5vdCBzZXQKCiMKIyBEaXNrLU9uLUNo aXAgRGV2aWNlIERyaXZlcnMKIwojIENPTkZJR19NVERfRE9DRzMgaXMgbm90IHNldApDT05G SUdfTVREX05BTkRfSURTPXkKQ09ORklHX01URF9OQU5EX0VDQz15CiMgQ09ORklHX01URF9O QU5EX0VDQ19TTUMgaXMgbm90IHNldApDT05GSUdfTVREX05BTkQ9eQojIENPTkZJR19NVERf TkFORF9FQ0NfQkNIIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX1NNX0NPTU1PTiBpcyBub3Qg c2V0CiMgQ09ORklHX01URF9OQU5EX0RFTkFMSSBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9O QU5EX0dQSU8gaXMgbm90IHNldApDT05GSUdfTVREX05BTkRfT01BUDI9eQpDT05GSUdfTVRE X05BTkRfT01BUF9CQ0g9eQojIENPTkZJR19NVERfTkFORF9SSUNPSCBpcyBub3Qgc2V0CiMg Q09ORklHX01URF9OQU5EX0RJU0tPTkNISVAgaXMgbm90IHNldAojIENPTkZJR19NVERfTkFO RF9ET0NHNCBpcyBub3Qgc2V0CiMgQ09ORklHX01URF9OQU5EX0NBRkUgaXMgbm90IHNldAoj IENPTkZJR19NVERfTkFORF9OQU5EU0lNIGlzIG5vdCBzZXQKIyBDT05GSUdfTVREX05BTkRf UExBVEZPUk0gaXMgbm90IHNldApDT05GSUdfTVREX09ORU5BTkQ9eQpDT05GSUdfTVREX09O RU5BTkRfVkVSSUZZX1dSSVRFPXkKIyBDT05GSUdfTVREX09ORU5BTkRfR0VORVJJQyBpcyBu b3Qgc2V0CiMgQ09ORklHX01URF9PTkVOQU5EX09UUCBpcyBub3Qgc2V0CiMgQ09ORklHX01U RF9PTkVOQU5EXzJYX1BST0dSQU0gaXMgbm90IHNldAoKIwojIExQRERSIGZsYXNoIG1lbW9y eSBkcml2ZXJzCiMKIyBDT05GSUdfTVREX0xQRERSIGlzIG5vdCBzZXQKQ09ORklHX01URF9V Qkk9eQpDT05GSUdfTVREX1VCSV9XTF9USFJFU0hPTEQ9NDA5NgpDT05GSUdfTVREX1VCSV9C RUJfTElNSVQ9MjAKIyBDT05GSUdfTVREX1VCSV9GQVNUTUFQIGlzIG5vdCBzZXQKIyBDT05G SUdfTVREX1VCSV9HTFVFQkkgaXMgbm90IHNldApDT05GSUdfRFRDPXkKQ09ORklHX09GPXkK CiMKIyBEZXZpY2UgVHJlZSBhbmQgT3BlbiBGaXJtd2FyZSBzdXBwb3J0CiMKQ09ORklHX1BS T0NfREVWSUNFVFJFRT15CiMgQ09ORklHX09GX1NFTEZURVNUIGlzIG5vdCBzZXQKQ09ORklH X09GX0ZMQVRUUkVFPXkKQ09ORklHX09GX0VBUkxZX0ZMQVRUUkVFPXkKQ09ORklHX09GX0FE RFJFU1M9eQpDT05GSUdfT0ZfSVJRPXkKQ09ORklHX09GX05FVD15CkNPTkZJR19PRl9NRElP PXkKQ09ORklHX09GX1BDST15CkNPTkZJR19PRl9QQ0lfSVJRPXkKQ09ORklHX09GX01URD15 CkNPTkZJR19PRl9SRVNFUlZFRF9NRU09eQpDT05GSUdfQVJDSF9NSUdIVF9IQVZFX1BDX1BB UlBPUlQ9eQojIENPTkZJR19QQVJQT1JUIGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVY9eQoj IENPTkZJR19CTEtfREVWX05VTExfQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9Q Q0lFU1NEX01USVAzMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0NQUV9DSVNTX0RBIGlz IG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9EQUM5NjAgaXMgbm90IHNldAojIENPTkZJR19C TEtfREVWX1VNRU0gaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0NPV19DT01NT04gaXMg bm90IHNldApDT05GSUdfQkxLX0RFVl9MT09QPXkKQ09ORklHX0JMS19ERVZfTE9PUF9NSU5f Q09VTlQ9OAojIENPTkZJR19CTEtfREVWX0NSWVBUT0xPT1AgaXMgbm90IHNldAojIENPTkZJ R19CTEtfREVWX0RSQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX05CRCBpcyBub3Qg c2V0CiMgQ09ORklHX0JMS19ERVZfTlZNRSBpcyBub3Qgc2V0CiMgQ09ORklHX0JMS19ERVZf U1g4IGlzIG5vdCBzZXQKQ09ORklHX0JMS19ERVZfUkFNPXkKQ09ORklHX0JMS19ERVZfUkFN X0NPVU5UPTE2CkNPTkZJR19CTEtfREVWX1JBTV9TSVpFPTE2Mzg0CiMgQ09ORklHX0JMS19E RVZfWElQIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0RST01fUEtUQ0RWRCBpcyBub3Qgc2V0CiMg Q09ORklHX0FUQV9PVkVSX0VUSCBpcyBub3Qgc2V0CiMgQ09ORklHX01HX0RJU0sgaXMgbm90 IHNldApDT05GSUdfWEVOX0JMS0RFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fQkxLREVWX0JB Q0tFTkQ9eQojIENPTkZJR19WSVJUSU9fQkxLIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RF Vl9SQkQgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX1JTWFggaXMgbm90IHNldAoKIwoj IE1pc2MgZGV2aWNlcwojCkNPTkZJR19TRU5TT1JTX0xJUzNMVjAyRD1tCiMgQ09ORklHX0FE NTI1WF9EUE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfQVRNRUxfUFdNIGlzIG5vdCBzZXQKIyBD T05GSUdfRFVNTVlfSVJRIGlzIG5vdCBzZXQKIyBDT05GSUdfUEhBTlRPTSBpcyBub3Qgc2V0 CiMgQ09ORklHX1NHSV9JT0M0IGlzIG5vdCBzZXQKIyBDT05GSUdfVElGTV9DT1JFIGlzIG5v dCBzZXQKIyBDT05GSUdfSUNTOTMyUzQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX0FUTUVMX1NT QyBpcyBub3Qgc2V0CiMgQ09ORklHX0VOQ0xPU1VSRV9TRVJWSUNFUyBpcyBub3Qgc2V0CiMg Q09ORklHX0hQX0lMTyBpcyBub3Qgc2V0CiMgQ09ORklHX0FQRFM5ODAyQUxTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVNMMjkwMDMgaXMgbm90IHNldAojIENPTkZJR19JU0wyOTAyMCBpcyBu b3Qgc2V0CkNPTkZJR19TRU5TT1JTX1RTTDI1NTA9bQojIENPTkZJR19TRU5TT1JTX0JIMTc4 MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQkgxNzcwIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19BUERTOTkwWCBpcyBub3Qgc2V0CiMgQ09ORklHX0hNQzYzNTIgaXMgbm90 IHNldAojIENPTkZJR19EUzE2ODIgaXMgbm90IHNldAojIENPTkZJR19USV9EQUM3NTEyIGlz IG5vdCBzZXQKIyBDT05GSUdfVUlEX1NUQVQgaXMgbm90IHNldApDT05GSUdfQk1QMDg1PXkK Q09ORklHX0JNUDA4NV9JMkM9bQojIENPTkZJR19CTVAwODVfU1BJIGlzIG5vdCBzZXQKIyBD T05GSUdfUENIX1BIVUIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1dJVENIX0ZTQTk0ODAg aXMgbm90IHNldAojIENPTkZJR19MQVRUSUNFX0VDUDNfQ09ORklHIGlzIG5vdCBzZXQKIyBD T05GSUdfU1JBTSBpcyBub3Qgc2V0CiMgQ09ORklHX0MyUE9SVCBpcyBub3Qgc2V0CgojCiMg RUVQUk9NIHN1cHBvcnQKIwojIENPTkZJR19FRVBST01fQVQyNCBpcyBub3Qgc2V0CiMgQ09O RklHX0VFUFJPTV9BVDI1IGlzIG5vdCBzZXQKIyBDT05GSUdfRUVQUk9NX0xFR0FDWSBpcyBu b3Qgc2V0CiMgQ09ORklHX0VFUFJPTV9NQVg2ODc1IGlzIG5vdCBzZXQKQ09ORklHX0VFUFJP TV85M0NYNj15CiMgQ09ORklHX0VFUFJPTV85M1hYNDYgaXMgbm90IHNldAojIENPTkZJR19D QjcxMF9DT1JFIGlzIG5vdCBzZXQKCiMKIyBUZXhhcyBJbnN0cnVtZW50cyBzaGFyZWQgdHJh bnNwb3J0IGxpbmUgZGlzY2lwbGluZQojCkNPTkZJR19USV9TVD15CkNPTkZJR19TVF9IQ0k9 eQojIENPTkZJR19TRU5TT1JTX0xJUzNfU1BJIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNf TElTM19JMkM9bQoKIwojIEFsdGVyYSBGUEdBIGZpcm13YXJlIGRvd25sb2FkIG1vZHVsZQoj CiMgQ09ORklHX0FMVEVSQV9TVEFQTCBpcyBub3Qgc2V0CgojCiMgSW50ZWwgTUlDIEhvc3Qg RHJpdmVyCiMKCiMKIyBJbnRlbCBNSUMgQ2FyZCBEcml2ZXIKIwpDT05GSUdfSEFWRV9JREU9 eQojIENPTkZJR19JREUgaXMgbm90IHNldAoKIwojIFNDU0kgZGV2aWNlIHN1cHBvcnQKIwpD T05GSUdfU0NTSV9NT0Q9eQojIENPTkZJR19SQUlEX0FUVFJTIGlzIG5vdCBzZXQKQ09ORklH X1NDU0k9eQpDT05GSUdfU0NTSV9ETUE9eQojIENPTkZJR19TQ1NJX1RHVCBpcyBub3Qgc2V0 CiMgQ09ORklHX1NDU0lfTkVUTElOSyBpcyBub3Qgc2V0CkNPTkZJR19TQ1NJX1BST0NfRlM9 eQoKIwojIFNDU0kgc3VwcG9ydCB0eXBlIChkaXNrLCB0YXBlLCBDRC1ST00pCiMKQ09ORklH X0JMS19ERVZfU0Q9eQojIENPTkZJR19DSFJfREVWX1NUIGlzIG5vdCBzZXQKIyBDT05GSUdf Q0hSX0RFVl9PU1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl9TUiBpcyBub3Qgc2V0 CiMgQ09ORklHX0NIUl9ERVZfU0cgaXMgbm90IHNldAojIENPTkZJR19DSFJfREVWX1NDSCBp cyBub3Qgc2V0CkNPTkZJR19TQ1NJX01VTFRJX0xVTj15CiMgQ09ORklHX1NDU0lfQ09OU1RB TlRTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9MT0dHSU5HIGlzIG5vdCBzZXQKQ09ORklH X1NDU0lfU0NBTl9BU1lOQz15CgojCiMgU0NTSSBUcmFuc3BvcnRzCiMKIyBDT05GSUdfU0NT SV9TUElfQVRUUlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0ZDX0FUVFJTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9JU0NTSV9BVFRSUyBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf U0FTX0FUVFJTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TQVNfTElCU0FTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9TUlBfQVRUUlMgaXMgbm90IHNldApDT05GSUdfU0NTSV9MT1dM RVZFTD15CiMgQ09ORklHX0lTQ1NJX1RDUCBpcyBub3Qgc2V0CiMgQ09ORklHX0lTQ1NJX0JP T1RfU1lTRlMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0NYR0IzX0lTQ1NJIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0NTSV9DWEdCNF9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lf Qk5YMl9JU0NTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQk5YMlhfRkNPRSBpcyBub3Qg c2V0CiMgQ09ORklHX0JFMklTQ1NJIGlzIG5vdCBzZXQKIyBDT05GSUdfQkxLX0RFVl8zV19Y WFhYX1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0hQU0EgaXMgbm90IHNldAojIENP TkZJR19TQ1NJXzNXXzlYWFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJXzNXX1NBUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfQUNBUkQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FB Q1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzdYWFggaXMgbm90IHNldAojIENP TkZJR19TQ1NJX0FJQzc5WFggaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0FJQzk0WFggaXMg bm90IHNldAojIENPTkZJR19TQ1NJX01WU0FTIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9N VlVNSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfQVJDTVNSIGlzIG5vdCBzZXQKIyBDT05G SUdfU0NTSV9FU0FTMlIgaXMgbm90IHNldAojIENPTkZJR19NRUdBUkFJRF9ORVdHRU4gaXMg bm90IHNldAojIENPTkZJR19NRUdBUkFJRF9MRUdBQ1kgaXMgbm90IHNldAojIENPTkZJR19N RUdBUkFJRF9TQVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX01QVDJTQVMgaXMgbm90IHNl dAojIENPTkZJR19TQ1NJX01QVDNTQVMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1VGU0hD RCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSFBUSU9QIGlzIG5vdCBzZXQKIyBDT05GSUdf TElCRkMgaXMgbm90IHNldAojIENPTkZJR19MSUJGQ09FIGlzIG5vdCBzZXQKIyBDT05GSUdf RkNPRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfRE1YMzE5MUQgaXMgbm90IHNldAojIENP TkZJR19TQ1NJX0ZVVFVSRV9ET01BSU4gaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0lQUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSU5JVElPIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NT SV9JTklBMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9TVEVYIGlzIG5vdCBzZXQKIyBD T05GSUdfU0NTSV9TWU01M0M4WFhfMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfSVBSIGlz IG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTE9HSUNfMTI4MCBpcyBub3Qgc2V0CiMgQ09ORklH X1NDU0lfUUxBX0ZDIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9RTEFfSVNDU0kgaXMgbm90 IHNldAojIENPTkZJR19TQ1NJX0xQRkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX0RDMzk1 eCBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREMzOTBUIGlzIG5vdCBzZXQKIyBDT05GSUdf U0NTSV9OU1AzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfREVCVUcgaXMgbm90IHNldAoj IENPTkZJR19TQ1NJX1BNQ1JBSUQgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1BNODAwMSBp cyBub3Qgc2V0CiMgQ09ORklHX1NDU0lfU1JQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9C RkFfRkMgaXMgbm90IHNldAojIENPTkZJR19TQ1NJX1ZJUlRJTyBpcyBub3Qgc2V0CiMgQ09O RklHX1NDU0lfQ0hFTFNJT19GQ09FIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NTSV9ESCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NDU0lfT1NEX0lOSVRJQVRPUiBpcyBub3Qgc2V0CkNPTkZJR19B VEE9eQojIENPTkZJR19BVEFfTk9OU1RBTkRBUkQgaXMgbm90IHNldApDT05GSUdfQVRBX1ZF UkJPU0VfRVJST1I9eQpDT05GSUdfU0FUQV9QTVA9eQoKIwojIENvbnRyb2xsZXJzIHdpdGgg bm9uLVNGRiBuYXRpdmUgaW50ZXJmYWNlCiMKIyBDT05GSUdfU0FUQV9BSENJIGlzIG5vdCBz ZXQKQ09ORklHX1NBVEFfQUhDSV9QTEFURk9STT15CiMgQ09ORklHX0FIQ0lfSU1YIGlzIG5v dCBzZXQKIyBDT05GSUdfU0FUQV9JTklDMTYyWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf QUNBUkRfQUhDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMMjQgaXMgbm90IHNldApD T05GSUdfQVRBX1NGRj15CgojCiMgU0ZGIGNvbnRyb2xsZXJzIHdpdGggY3VzdG9tIERNQSBp bnRlcmZhY2UKIwojIENPTkZJR19QRENfQURNQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf UVNUT1IgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NYNCBpcyBub3Qgc2V0CkNPTkZJR19B VEFfQk1ETUE9eQoKIwojIFNBVEEgU0ZGIGNvbnRyb2xsZXJzIHdpdGggQk1ETUEKIwojIENP TkZJR19BVEFfUElJWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfSElHSEJBTksgaXMgbm90 IHNldAojIENPTkZJR19TQVRBX01WIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9OViBpcyBu b3Qgc2V0CiMgQ09ORklHX1NBVEFfUFJPTUlTRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFf UkNBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NBVEFfU0lMIGlzIG5vdCBzZXQKIyBDT05GSUdf U0FUQV9TSVMgaXMgbm90IHNldAojIENPTkZJR19TQVRBX1NWVyBpcyBub3Qgc2V0CiMgQ09O RklHX1NBVEFfVUxJIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FUQV9WSUEgaXMgbm90IHNldAoj IENPTkZJR19TQVRBX1ZJVEVTU0UgaXMgbm90IHNldAoKIwojIFBBVEEgU0ZGIGNvbnRyb2xs ZXJzIHdpdGggQk1ETUEKIwojIENPTkZJR19QQVRBX0FMSSBpcyBub3Qgc2V0CiMgQ09ORklH X1BBVEFfQU1EIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BUkFTQU5fQ0YgaXMgbm90IHNl dAojIENPTkZJR19QQVRBX0FSVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9BVElJWFAg aXMgbm90IHNldAojIENPTkZJR19QQVRBX0FUUDg2N1ggaXMgbm90IHNldAojIENPTkZJR19Q QVRBX0NNRDY0WCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1M1NTIwIGlzIG5vdCBzZXQK IyBDT05GSUdfUEFUQV9DUzU1MzAgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0NTNTUzNiBp cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfQ1lQUkVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BB VEFfRUZBUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfSFBUMzY2IGlzIG5vdCBzZXQKIyBD T05GSUdfUEFUQV9IUFQzN1ggaXMgbm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMk4gaXMg bm90IHNldAojIENPTkZJR19QQVRBX0hQVDNYMyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf SVQ4MjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9JVDgyMVggaXMgbm90IHNldAojIENP TkZJR19QQVRBX0pNSUNST04gaXMgbm90IHNldAojIENPTkZJR19QQVRBX01BUlZFTEwgaXMg bm90IHNldAojIENPTkZJR19QQVRBX05FVENFTEwgaXMgbm90IHNldAojIENPTkZJR19QQVRB X05JTkpBMzIgaXMgbm90IHNldAojIENPTkZJR19QQVRBX05TODc0MTUgaXMgbm90IHNldAoj IENPTkZJR19QQVRBX09MRFBJSVggaXMgbm90IHNldAojIENPTkZJR19QQVRBX09QVElETUEg aXMgbm90IHNldAojIENPTkZJR19QQVRBX1BEQzIwMjdYIGlzIG5vdCBzZXQKIyBDT05GSUdf UEFUQV9QRENfT0xEIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9SQURJU1lTIGlzIG5vdCBz ZXQKIyBDT05GSUdfUEFUQV9SREMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1NDMTIwMCBp cyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0NIIGlzIG5vdCBzZXQKIyBDT05GSUdfUEFUQV9T RVJWRVJXT1JLUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfU0lMNjgwIGlzIG5vdCBzZXQK IyBDT05GSUdfUEFUQV9TSVMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX1RPU0hJQkEgaXMg bm90IHNldAojIENPTkZJR19QQVRBX1RSSUZMRVggaXMgbm90IHNldAojIENPTkZJR19QQVRB X1ZJQSBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfV0lOQk9ORCBpcyBub3Qgc2V0CgojCiMg UElPLW9ubHkgU0ZGIGNvbnRyb2xsZXJzCiMKIyBDT05GSUdfUEFUQV9DTUQ2NDBfUENJIGlz IG5vdCBzZXQKIyBDT05GSUdfUEFUQV9NUElJWCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFf TlM4NzQxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1BBVEFfT1BUSSBpcyBub3Qgc2V0CiMgQ09O RklHX1BBVEFfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19QQVRBX1JaMTAwMCBpcyBu b3Qgc2V0CgojCiMgR2VuZXJpYyBmYWxsYmFjayAvIGxlZ2FjeSBkcml2ZXJzCiMKIyBDT05G SUdfQVRBX0dFTkVSSUMgaXMgbm90IHNldAojIENPTkZJR19QQVRBX0xFR0FDWSBpcyBub3Qg c2V0CkNPTkZJR19NRD15CiMgQ09ORklHX0JMS19ERVZfTUQgaXMgbm90IHNldAojIENPTkZJ R19CQ0FDSEUgaXMgbm90IHNldAojIENPTkZJR19CTEtfREVWX0RNIGlzIG5vdCBzZXQKIyBD T05GSUdfVEFSR0VUX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19GVVNJT04gaXMgbm90IHNl dAoKIwojIElFRUUgMTM5NCAoRmlyZVdpcmUpIHN1cHBvcnQKIwojIENPTkZJR19GSVJFV0lS RSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZJUkVXSVJFX05PU1kgaXMgbm90IHNldAojIENPTkZJ R19JMk8gaXMgbm90IHNldApDT05GSUdfTkVUREVWSUNFUz15CkNPTkZJR19NSUk9eQpDT05G SUdfTkVUX0NPUkU9eQojIENPTkZJR19CT05ESU5HIGlzIG5vdCBzZXQKIyBDT05GSUdfRFVN TVkgaXMgbm90IHNldAojIENPTkZJR19FUVVBTElaRVIgaXMgbm90IHNldAojIENPTkZJR19O RVRfRkMgaXMgbm90IHNldAojIENPTkZJR19ORVRfVEVBTSBpcyBub3Qgc2V0CiMgQ09ORklH X01BQ1ZMQU4gaXMgbm90IHNldAojIENPTkZJR19WWExBTiBpcyBub3Qgc2V0CiMgQ09ORklH X05FVENPTlNPTEUgaXMgbm90IHNldAojIENPTkZJR19ORVRQT0xMIGlzIG5vdCBzZXQKIyBD T05GSUdfTkVUX1BPTExfQ09OVFJPTExFUiBpcyBub3Qgc2V0CiMgQ09ORklHX1RVTiBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZFVEggaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9fTkVUIGlz IG5vdCBzZXQKIyBDT05GSUdfTkxNT04gaXMgbm90IHNldAojIENPTkZJR19BUkNORVQgaXMg bm90IHNldAoKIwojIENBSUYgdHJhbnNwb3J0IGRyaXZlcnMKIwoKIwojIERpc3RyaWJ1dGVk IFN3aXRjaCBBcmNoaXRlY3R1cmUgZHJpdmVycwojCiMgQ09ORklHX05FVF9EU0FfTVY4OEU2 WFhYIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTYwNjAgaXMgbm90IHNldAoj IENPTkZJR19ORVRfRFNBX01WODhFNlhYWF9ORUVEX1BQVSBpcyBub3Qgc2V0CiMgQ09ORklH X05FVF9EU0FfTVY4OEU2MTMxIGlzIG5vdCBzZXQKIyBDT05GSUdfTkVUX0RTQV9NVjg4RTYx MjNfNjFfNjUgaXMgbm90IHNldApDT05GSUdfRVRIRVJORVQ9eQpDT05GSUdfTkVUX1ZFTkRP Ul8zQ09NPXkKIyBDT05GSUdfVk9SVEVYIGlzIG5vdCBzZXQKIyBDT05GSUdfVFlQSE9PTiBp cyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0FEQVBURUM9eQojIENPTkZJR19BREFQVEVD X1NUQVJGSVJFIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQUxURU9OPXkKIyBDT05G SUdfQUNFTklDIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQU1EPXkKIyBDT05GSUdf QU1EODExMV9FVEggaXMgbm90IHNldAojIENPTkZJR19QQ05FVDMyIGlzIG5vdCBzZXQKQ09O RklHX05FVF9WRU5ET1JfQVJDPXkKIyBDT05GSUdfQVJDX0VNQUMgaXMgbm90IHNldApDT05G SUdfTkVUX1ZFTkRPUl9BVEhFUk9TPXkKIyBDT05GSUdfQVRMMiBpcyBub3Qgc2V0CiMgQ09O RklHX0FUTDEgaXMgbm90IHNldAojIENPTkZJR19BVEwxRSBpcyBub3Qgc2V0CiMgQ09ORklH X0FUTDFDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUxYIGlzIG5vdCBzZXQKQ09ORklHX05FVF9D QURFTkNFPXkKIyBDT05GSUdfQVJNX0FUOTFfRVRIRVIgaXMgbm90IHNldAojIENPTkZJR19N QUNCIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQlJPQURDT009eQojIENPTkZJR19C NDQgaXMgbm90IHNldAojIENPTkZJR19CTlgyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ05JQyBp cyBub3Qgc2V0CiMgQ09ORklHX1RJR09OMyBpcyBub3Qgc2V0CiMgQ09ORklHX0JOWDJYIGlz IG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfQlJPQ0FERT15CiMgQ09ORklHX0JOQSBpcyBu b3Qgc2V0CiMgQ09ORklHX05FVF9DQUxYRURBX1hHTUFDIGlzIG5vdCBzZXQKQ09ORklHX05F VF9WRU5ET1JfQ0hFTFNJTz15CiMgQ09ORklHX0NIRUxTSU9fVDEgaXMgbm90IHNldAojIENP TkZJR19DSEVMU0lPX1QzIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hFTFNJT19UNCBpcyBub3Qg c2V0CiMgQ09ORklHX0NIRUxTSU9fVDRWRiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X0NJUlJVUz15CiMgQ09ORklHX0NTODl4MCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X0NJU0NPPXkKIyBDT05GSUdfRU5JQyBpcyBub3Qgc2V0CiMgQ09ORklHX0RNOTAwMCBpcyBu b3Qgc2V0CiMgQ09ORklHX0RORVQgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9ERUM9 eQojIENPTkZJR19ORVRfVFVMSVAgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9ETElO Sz15CiMgQ09ORklHX0RMMksgaXMgbm90IHNldAojIENPTkZJR19TVU5EQU5DRSBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0VNVUxFWD15CiMgQ09ORklHX0JFMk5FVCBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0VYQVI9eQojIENPTkZJR19TMklPIGlzIG5vdCBzZXQK IyBDT05GSUdfVlhHRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0ZBUkFEQVk9eQoj IENPTkZJR19GVE1BQzEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZUR01BQzEwMCBpcyBub3Qg c2V0CkNPTkZJR19ORVRfVkVORE9SX0hQPXkKIyBDT05GSUdfSFAxMDAgaXMgbm90IHNldApD T05GSUdfTkVUX1ZFTkRPUl9JTlRFTD15CiMgQ09ORklHX0UxMDAgaXMgbm90IHNldAojIENP TkZJR19FMTAwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0UxMDAwRSBpcyBub3Qgc2V0CiMgQ09O RklHX0lHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lHQlZGIGlzIG5vdCBzZXQKIyBDT05GSUdf SVhHQiBpcyBub3Qgc2V0CiMgQ09ORklHX0lYR0JFIGlzIG5vdCBzZXQKIyBDT05GSUdfSTQw RSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX0k4MjVYWD15CiMgQ09ORklHX0lQMTAw MCBpcyBub3Qgc2V0CiMgQ09ORklHX0pNRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9S X01BUlZFTEw9eQojIENPTkZJR19NVk1ESU8gaXMgbm90IHNldAojIENPTkZJR19TS0dFIGlz IG5vdCBzZXQKIyBDT05GSUdfU0tZMiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX01F TExBTk9YPXkKIyBDT05GSUdfTUxYNF9FTiBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDRfQ09S RSBpcyBub3Qgc2V0CiMgQ09ORklHX01MWDVfQ09SRSBpcyBub3Qgc2V0CkNPTkZJR19ORVRf VkVORE9SX01JQ1JFTD15CiMgQ09ORklHX0tTODg0MiBpcyBub3Qgc2V0CkNPTkZJR19LUzg4 NTE9eQpDT05GSUdfS1M4ODUxX01MTD15CiMgQ09ORklHX0tTWjg4NFhfUENJIGlzIG5vdCBz ZXQKQ09ORklHX05FVF9WRU5ET1JfTUlDUk9DSElQPXkKIyBDT05GSUdfRU5DMjhKNjAgaXMg bm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9NWVJJPXkKIyBDT05GSUdfTVlSSTEwR0UgaXMg bm90IHNldAojIENPTkZJR19GRUFMTlggaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9O QVRTRU1JPXkKIyBDT05GSUdfTkFUU0VNSSBpcyBub3Qgc2V0CiMgQ09ORklHX05TODM4MjAg aXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl84MzkwPXkKIyBDT05GSUdfQVg4ODc5NiBp cyBub3Qgc2V0CiMgQ09ORklHX05FMktfUENJIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5E T1JfTlZJRElBPXkKIyBDT05GSUdfRk9SQ0VERVRIIGlzIG5vdCBzZXQKQ09ORklHX05FVF9W RU5ET1JfT0tJPXkKIyBDT05GSUdfRVRIT0MgaXMgbm90IHNldApDT05GSUdfTkVUX1BBQ0tF VF9FTkdJTkU9eQojIENPTkZJR19IQU1BQ0hJIGlzIG5vdCBzZXQKIyBDT05GSUdfWUVMTE9X RklOIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfUUxPR0lDPXkKIyBDT05GSUdfUUxB M1hYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1FMQ05JQyBpcyBub3Qgc2V0CiMgQ09ORklHX1FM R0UgaXMgbm90IHNldAojIENPTkZJR19ORVRYRU5fTklDIGlzIG5vdCBzZXQKQ09ORklHX05F VF9WRU5ET1JfUkVBTFRFSz15CiMgQ09ORklHXzgxMzlDUCBpcyBub3Qgc2V0CiMgQ09ORklH XzgxMzlUT08gaXMgbm90IHNldAojIENPTkZJR19SODE2OSBpcyBub3Qgc2V0CiMgQ09ORklH X1NIX0VUSCBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1JEQz15CiMgQ09ORklHX1I2 MDQwIGlzIG5vdCBzZXQKQ09ORklHX05FVF9WRU5ET1JfU0VFUT15CkNPTkZJR19ORVRfVkVO RE9SX1NJTEFOPXkKIyBDT05GSUdfU0M5MjAzMSBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVO RE9SX1NJUz15CiMgQ09ORklHX1NJUzkwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NJUzE5MCBp cyBub3Qgc2V0CiMgQ09ORklHX1NGQyBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NN U0M9eQpDT05GSUdfU01DOTFYPXkKIyBDT05GSUdfRVBJQzEwMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NNQzkxMVggaXMgbm90IHNldApDT05GSUdfU01TQzkxMVg9eQojIENPTkZJR19TTVND OTExWF9BUkNIX0hPT0tTIGlzIG5vdCBzZXQKIyBDT05GSUdfU01TQzk0MjAgaXMgbm90IHNl dApDT05GSUdfTkVUX1ZFTkRPUl9TVE1JQ1JPPXkKIyBDT05GSUdfU1RNTUFDX0VUSCBpcyBu b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1NVTj15CiMgQ09ORklHX0hBUFBZTUVBTCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NVTkdFTSBpcyBub3Qgc2V0CiMgQ09ORklHX0NBU1NJTkkgaXMg bm90IHNldAojIENPTkZJR19OSVUgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9URUhV VEk9eQojIENPTkZJR19URUhVVEkgaXMgbm90IHNldApDT05GSUdfTkVUX1ZFTkRPUl9UST15 CkNPTkZJR19USV9EQVZJTkNJX01ESU89eQpDT05GSUdfVElfREFWSU5DSV9DUERNQT15CkNP TkZJR19USV9DUFNXX1BIWV9TRUw9eQpDT05GSUdfVElfQ1BTVz15CkNPTkZJR19USV9DUFRT PXkKIyBDT05GSUdfVExBTiBpcyBub3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1ZJQT15CiMg Q09ORklHX1ZJQV9SSElORSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJQV9WRUxPQ0lUWSBpcyBu b3Qgc2V0CkNPTkZJR19ORVRfVkVORE9SX1dJWk5FVD15CiMgQ09ORklHX1dJWk5FVF9XNTEw MCBpcyBub3Qgc2V0CiMgQ09ORklHX1dJWk5FVF9XNTMwMCBpcyBub3Qgc2V0CiMgQ09ORklH X0ZEREkgaXMgbm90IHNldAojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0CkNPTkZJR19QSFlM SUI9eQoKIwojIE1JSSBQSFkgZGV2aWNlIGRyaXZlcnMKIwpDT05GSUdfQVQ4MDNYX1BIWT15 CiMgQ09ORklHX0FNRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NQVJWRUxMX1BIWSBpcyBu b3Qgc2V0CiMgQ09ORklHX0RBVklDT01fUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfUVNFTUlf UEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTFhUX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX0NJ Q0FEQV9QSFkgaXMgbm90IHNldAojIENPTkZJR19WSVRFU1NFX1BIWSBpcyBub3Qgc2V0CkNP TkZJR19TTVNDX1BIWT15CiMgQ09ORklHX0JST0FEQ09NX1BIWSBpcyBub3Qgc2V0CiMgQ09O RklHX0JDTTg3WFhfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfSUNQTFVTX1BIWSBpcyBub3Qg c2V0CiMgQ09ORklHX1JFQUxURUtfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfTkFUSU9OQUxf UEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfU1RFMTBYUCBpcyBub3Qgc2V0CiMgQ09ORklHX0xT SV9FVDEwMTFDX1BIWSBpcyBub3Qgc2V0CiMgQ09ORklHX01JQ1JFTF9QSFkgaXMgbm90IHNl dAojIENPTkZJR19GSVhFRF9QSFkgaXMgbm90IHNldAojIENPTkZJR19NRElPX0JJVEJBTkcg aXMgbm90IHNldAojIENPTkZJR19NRElPX0JVU19NVVhfR1BJTyBpcyBub3Qgc2V0CiMgQ09O RklHX01ESU9fQlVTX01VWF9NTUlPUkVHIGlzIG5vdCBzZXQKIyBDT05GSUdfTUlDUkVMX0tT ODk5NU1BIGlzIG5vdCBzZXQKIyBDT05GSUdfUFBQIGlzIG5vdCBzZXQKIyBDT05GSUdfU0xJ UCBpcyBub3Qgc2V0CgojCiMgVVNCIE5ldHdvcmsgQWRhcHRlcnMKIwojIENPTkZJR19VU0Jf Q0FUQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9LQVdFVEggaXMgbm90IHNldAojIENPTkZJ R19VU0JfUEVHQVNVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9SVEw4MTUwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX1JUTDgxNTIgaXMgbm90IHNldApDT05GSUdfVVNCX1VTQk5FVD15 CkNPTkZJR19VU0JfTkVUX0FYODgxN1g9eQpDT05GSUdfVVNCX05FVF9BWDg4MTc5XzE3OEE9 eQpDT05GSUdfVVNCX05FVF9DRENFVEhFUj15CiMgQ09ORklHX1VTQl9ORVRfQ0RDX0VFTSBp cyBub3Qgc2V0CkNPTkZJR19VU0JfTkVUX0NEQ19OQ009eQojIENPTkZJR19VU0JfTkVUX0hV QVdFSV9DRENfTkNNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9DRENfTUJJTSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfRE05NjAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X05FVF9TUjk3MDAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1NSOTgwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9ORVRfU01TQzc1WFggaXMgbm90IHNldApDT05GSUdfVVNCX05F VF9TTVNDOTVYWD15CiMgQ09ORklHX1VTQl9ORVRfR0w2MjBBIGlzIG5vdCBzZXQKQ09ORklH X1VTQl9ORVRfTkVUMTA4MD15CiMgQ09ORklHX1VTQl9ORVRfUExVU0IgaXMgbm90IHNldAoj IENPTkZJR19VU0JfTkVUX01DUzc4MzAgaXMgbm90IHNldAojIENPTkZJR19VU0JfTkVUX1JO RElTX0hPU1QgaXMgbm90IHNldApDT05GSUdfVVNCX05FVF9DRENfU1VCU0VUPXkKQ09ORklH X1VTQl9BTElfTTU2MzI9eQpDT05GSUdfVVNCX0FOMjcyMD15CkNPTkZJR19VU0JfQkVMS0lO PXkKQ09ORklHX1VTQl9BUk1MSU5VWD15CkNPTkZJR19VU0JfRVBTT04yODg4PXkKQ09ORklH X1VTQl9LQzIxOTA9eQpDT05GSUdfVVNCX05FVF9aQVVSVVM9eQojIENPTkZJR19VU0JfTkVU X0NYODIzMTBfRVRIIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX05FVF9LQUxNSUEgaXMgbm90 IHNldAojIENPTkZJR19VU0JfTkVUX1FNSV9XV0FOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0hTTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVRfSU5UNTFYMSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9JUEhFVEggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0lFUlJBX05FVCBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9WTDYwMCBpcyBub3Qgc2V0CkNPTkZJR19XTEFOPXkK IyBDT05GSUdfQVRNRUwgaXMgbm90IHNldAojIENPTkZJR19QUklTTTU0IGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1pEMTIwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1dJRklfQ09OVFJPTF9G VU5DIGlzIG5vdCBzZXQKIyBDT05GSUdfSE9TVEFQIGlzIG5vdCBzZXQKIyBDT05GSUdfV0xf VEkgaXMgbm90IHNldAoKIwojIEVuYWJsZSBXaU1BWCAoTmV0d29ya2luZyBvcHRpb25zKSB0 byBzZWUgdGhlIFdpTUFYIGRyaXZlcnMKIwojIENPTkZJR19XQU4gaXMgbm90IHNldApDT05G SUdfWEVOX05FVERFVl9GUk9OVEVORD15CkNPTkZJR19YRU5fTkVUREVWX0JBQ0tFTkQ9eQoj IENPTkZJR19WTVhORVQzIGlzIG5vdCBzZXQKIyBDT05GSUdfSVNETiBpcyBub3Qgc2V0Cgoj CiMgSW5wdXQgZGV2aWNlIHN1cHBvcnQKIwpDT05GSUdfSU5QVVQ9eQojIENPTkZJR19JTlBV VF9GRl9NRU1MRVNTIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX1BPTExERVY9bQojIENPTkZJ R19JTlBVVF9TUEFSU0VLTUFQIGlzIG5vdCBzZXQKQ09ORklHX0lOUFVUX01BVFJJWEtNQVA9 bQoKIwojIFVzZXJsYW5kIGludGVyZmFjZXMKIwpDT05GSUdfSU5QVVRfTU9VU0VERVY9eQpD T05GSUdfSU5QVVRfTU9VU0VERVZfUFNBVVg9eQpDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NS RUVOX1g9MTAyNApDT05GSUdfSU5QVVRfTU9VU0VERVZfU0NSRUVOX1k9NzY4CkNPTkZJR19J TlBVVF9KT1lERVY9eQpDT05GSUdfSU5QVVRfRVZERVY9eQojIENPTkZJR19JTlBVVF9FVkJV RyBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0tFWVJFU0VUIGlzIG5vdCBzZXQKIyBDT05G SUdfSU5QVVRfS0VZQ09NQk8gaXMgbm90IHNldAoKIwojIElucHV0IERldmljZSBEcml2ZXJz CiMKQ09ORklHX0lOUFVUX0tFWUJPQVJEPXkKIyBDT05GSUdfS0VZQk9BUkRfQURQNTU4OCBp cyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX0FEUDU1ODkgaXMgbm90IHNldApDT05GSUdf S0VZQk9BUkRfQVRLQkQ9eQojIENPTkZJR19LRVlCT0FSRF9RVDEwNzAgaXMgbm90IHNldAoj IENPTkZJR19LRVlCT0FSRF9RVDIxNjAgaXMgbm90IHNldAojIENPTkZJR19LRVlCT0FSRF9M S0tCRCBpcyBub3Qgc2V0CkNPTkZJR19LRVlCT0FSRF9HUElPPXkKIyBDT05GSUdfS0VZQk9B UkRfVENBNjQxNiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1RDQTg0MTggaXMgbm90 IHNldApDT05GSUdfS0VZQk9BUkRfTUFUUklYPW0KIyBDT05GSUdfS0VZQk9BUkRfTE04MzIz IGlzIG5vdCBzZXQKIyBDT05GSUdfS0VZQk9BUkRfTE04MzMzIGlzIG5vdCBzZXQKIyBDT05G SUdfS0VZQk9BUkRfTUFYNzM1OSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01DUyBp cyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX01QUjEyMSBpcyBub3Qgc2V0CiMgQ09ORklH X0tFWUJPQVJEX05FV1RPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09QRU5DT1JF UyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NBTVNVTkcgaXMgbm90IHNldAojIENP TkZJR19LRVlCT0FSRF9TVE9XQVdBWSBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX1NV TktCRCBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWUJPQVJEX09NQVA0IGlzIG5vdCBzZXQKIyBD T05GSUdfS0VZQk9BUkRfWFRLQkQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfTU9VU0U9eQpD T05GSUdfTU9VU0VfUFMyPXkKQ09ORklHX01PVVNFX1BTMl9BTFBTPXkKQ09ORklHX01PVVNF X1BTMl9MT0dJUFMyUFA9eQpDT05GSUdfTU9VU0VfUFMyX1NZTkFQVElDUz15CkNPTkZJR19N T1VTRV9QUzJfQ1lQUkVTUz15CkNPTkZJR19NT1VTRV9QUzJfVFJBQ0tQT0lOVD15CiMgQ09O RklHX01PVVNFX1BTMl9FTEFOVEVDSCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1BTMl9T RU5URUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX1BTMl9UT1VDSEtJVCBpcyBub3Qg c2V0CiMgQ09ORklHX01PVVNFX1NFUklBTCBpcyBub3Qgc2V0CiMgQ09ORklHX01PVVNFX0FQ UExFVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9CQ001OTc0IGlzIG5vdCBzZXQK IyBDT05GSUdfTU9VU0VfQ1lBUEEgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9WU1hYWEFB IGlzIG5vdCBzZXQKIyBDT05GSUdfTU9VU0VfR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklHX01P VVNFX1NZTkFQVElDU19JMkMgaXMgbm90IHNldAojIENPTkZJR19NT1VTRV9TWU5BUFRJQ1Nf VVNCIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfSk9ZU1RJQ0sgaXMgbm90IHNldAojIENP TkZJR19JTlBVVF9UQUJMRVQgaXMgbm90IHNldApDT05GSUdfSU5QVVRfVE9VQ0hTQ1JFRU49 eQpDT05GSUdfVE9VQ0hTQ1JFRU5fQURTNzg0Nj15CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FE Nzg3NyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0FENzg3OSBpcyBub3Qgc2V0 CkNPTkZJR19UT1VDSFNDUkVFTl9BVE1FTF9NWFQ9eQojIENPTkZJR19UT1VDSFNDUkVFTl9B VU9fUElYQ0lSIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fQlUyMTAxMyBpcyBu b3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0NZOENUTUcxMTAgaXMgbm90IHNldAojIENP TkZJR19UT1VDSFNDUkVFTl9DWVRUU1BfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNI U0NSRUVOX0NZVFRTUDRfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0RZ TkFQUk8gaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9IQU1QU0hJUkUgaXMgbm90 IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9FRVRJIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fRUdBTEFYIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fRlVKSVRT VSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0lMSTIxMFggaXMgbm90IHNldAoj IENPTkZJR19UT1VDSFNDUkVFTl9HVU5aRSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NS RUVOX0VMTyBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1dBQ09NX1c4MDAxIGlz IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fV0FDT01fSTJDIGlzIG5vdCBzZXQKIyBD T05GSUdfVE9VQ0hTQ1JFRU5fTUFYMTE4MDEgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFND UkVFTl9NQ1M1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTU1TMTE0IGlz IG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fTVRPVUNIIGlzIG5vdCBzZXQKIyBDT05G SUdfVE9VQ0hTQ1JFRU5fSU5FWElPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5f TUs3MTIgaXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9QRU5NT1VOVCBpcyBub3Qg c2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX0VEVF9GVDVYMDYgaXMgbm90IHNldAojIENPTkZJ R19UT1VDSFNDUkVFTl9UT1VDSFJJR0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JF RU5fVE9VQ0hXSU4gaXMgbm90IHNldApDT05GSUdfVE9VQ0hTQ1JFRU5fVElfQU0zMzVYX1RT Qz15CkNPTkZJR19UT1VDSFNDUkVFTl9QSVhDSVI9bQpDT05GSUdfVE9VQ0hTQ1JFRU5fTERD MzAwMT15CiMgQ09ORklHX1RPVUNIU0NSRUVOX1VTQl9DT01QT1NJVEUgaXMgbm90IHNldAoj IENPTkZJR19UT1VDSFNDUkVFTl9UT1VDSElUMjEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fVFNDX1NFUklPIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fVFND MjAwNSBpcyBub3Qgc2V0CiMgQ09ORklHX1RPVUNIU0NSRUVOX1RTQzIwMDcgaXMgbm90IHNl dAojIENPTkZJR19UT1VDSFNDUkVFTl9XOTBYOTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9V Q0hTQ1JFRU5fU1QxMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVE9VQ0hTQ1JFRU5fU1VSNDAg aXMgbm90IHNldAojIENPTkZJR19UT1VDSFNDUkVFTl9UUFM2NTA3WCBpcyBub3Qgc2V0CiMg Q09ORklHX1RPVUNIU0NSRUVOX1pGT1JDRSBpcyBub3Qgc2V0CkNPTkZJR19JTlBVVF9NSVND PXkKIyBDT05GSUdfSU5QVVRfQUQ3MTRYIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQk1B MTUwIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfTU1BODQ1MCBpcyBub3Qgc2V0CiMgQ09O RklHX0lOUFVUX01QVTMwNTAgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9HUDJBIGlzIG5v dCBzZXQKIyBDT05GSUdfSU5QVVRfR1BJT19CRUVQRVIgaXMgbm90IHNldAojIENPTkZJR19J TlBVVF9HUElPX1RJTFRfUE9MTEVEIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQVRJX1JF TU9URTIgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9LRVlDSE9SRCBpcyBub3Qgc2V0CiMg Q09ORklHX0lOUFVUX0tFWVNQQU5fUkVNT1RFIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRf S1hUSjkgaXMgbm90IHNldAojIENPTkZJR19JTlBVVF9QT1dFUk1BVEUgaXMgbm90IHNldAoj IENPTkZJR19JTlBVVF9ZRUFMSU5LIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfQ00xMDkg aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9UV0w2MDQwX1ZJQlJBIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5QVVRfVUlOUFVUIGlzIG5vdCBzZXQKIyBDT05GSUdfSU5QVVRfR1BJTyBpcyBu b3Qgc2V0CkNPTkZJR19JTlBVVF9QQUxNQVNfUFdSQlVUVE9OPXkKIyBDT05GSUdfSU5QVVRf UENGODU3NCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0dQSU9fUk9UQVJZX0VOQ09ERVIg aXMgbm90IHNldAojIENPTkZJR19JTlBVVF9BRFhMMzRYIGlzIG5vdCBzZXQKIyBDT05GSUdf SU5QVVRfSU1TX1BDVSBpcyBub3Qgc2V0CiMgQ09ORklHX0lOUFVUX0NNQTMwMDAgaXMgbm90 IHNldApDT05GSUdfSU5QVVRfWEVOX0tCRERFVl9GUk9OVEVORD15CgojCiMgSGFyZHdhcmUg SS9PIHBvcnRzCiMKQ09ORklHX1NFUklPPXkKQ09ORklHX1NFUklPX1NFUlBPUlQ9eQojIENP TkZJR19TRVJJT19QQ0lQUzIgaXMgbm90IHNldApDT05GSUdfU0VSSU9fTElCUFMyPXkKIyBD T05GSUdfU0VSSU9fUkFXIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fQUxURVJBX1BTMiBp cyBub3Qgc2V0CiMgQ09ORklHX1NFUklPX1BTMk1VTFQgaXMgbm90IHNldAojIENPTkZJR19T RVJJT19BUkNfUFMyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSU9fQVBCUFMyIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VSSU9fT0xQQ19BUFNQIGlzIG5vdCBzZXQKIyBDT05GSUdfR0FNRVBP UlQgaXMgbm90IHNldAoKIwojIENoYXJhY3RlciBkZXZpY2VzCiMKQ09ORklHX1RUWT15CkNP TkZJR19WVD15CkNPTkZJR19DT05TT0xFX1RSQU5TTEFUSU9OUz15CkNPTkZJR19WVF9DT05T T0xFPXkKQ09ORklHX1ZUX0NPTlNPTEVfU0xFRVA9eQpDT05GSUdfSFdfQ09OU09MRT15CkNP TkZJR19WVF9IV19DT05TT0xFX0JJTkRJTkc9eQpDT05GSUdfVU5JWDk4X1BUWVM9eQojIENP TkZJR19ERVZQVFNfTVVMVElQTEVfSU5TVEFOQ0VTIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVH QUNZX1BUWVMgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfTk9OU1RBTkRBUkQgaXMgbm90 IHNldAojIENPTkZJR19OT1pPTUkgaXMgbm90IHNldAojIENPTkZJR19OX0dTTSBpcyBub3Qg c2V0CiMgQ09ORklHX1RSQUNFX1NJTksgaXMgbm90IHNldApDT05GSUdfREVWTUVNPXkKQ09O RklHX0RFVktNRU09eQoKIwojIFNlcmlhbCBkcml2ZXJzCiMKQ09ORklHX1NFUklBTF84MjUw PXkKQ09ORklHX1NFUklBTF84MjUwX0RFUFJFQ0FURURfT1BUSU9OUz15CkNPTkZJR19TRVJJ QUxfODI1MF9DT05TT0xFPXkKQ09ORklHX1NFUklBTF84MjUwX0RNQT15CkNPTkZJR19TRVJJ QUxfODI1MF9QQ0k9eQpDT05GSUdfU0VSSUFMXzgyNTBfTlJfVUFSVFM9MzIKQ09ORklHX1NF UklBTF84MjUwX1JVTlRJTUVfVUFSVFM9NApDT05GSUdfU0VSSUFMXzgyNTBfRVhURU5ERUQ9 eQpDT05GSUdfU0VSSUFMXzgyNTBfTUFOWV9QT1JUUz15CkNPTkZJR19TRVJJQUxfODI1MF9T SEFSRV9JUlE9eQpDT05GSUdfU0VSSUFMXzgyNTBfREVURUNUX0lSUT15CkNPTkZJR19TRVJJ QUxfODI1MF9SU0E9eQojIENPTkZJR19TRVJJQUxfODI1MF9EVyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFUklBTF84MjUwX0VNIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMXzgyNTBfT01B UCBpcyBub3Qgc2V0CgojCiMgTm9uLTgyNTAgc2VyaWFsIHBvcnQgc3VwcG9ydAojCiMgQ09O RklHX1NFUklBTF9NQVgzMTAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX01BWDMxMFgg aXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfTUZEX0hTVSBpcyBub3Qgc2V0CiMgQ09ORklH X1NFUklBTF9TSF9TQ0kgaXMgbm90IHNldApDT05GSUdfU0VSSUFMX0NPUkU9eQpDT05GSUdf U0VSSUFMX0NPUkVfQ09OU09MRT15CiMgQ09ORklHX1NFUklBTF9KU00gaXMgbm90IHNldApD T05GSUdfU0VSSUFMX09GX1BMQVRGT1JNPXkKQ09ORklHX1NFUklBTF9PTUFQPXkKQ09ORklH X1NFUklBTF9PTUFQX0NPTlNPTEU9eQojIENPTkZJR19TRVJJQUxfU0NDTlhQIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VSSUFMX1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19TRVJJ QUxfQUxURVJBX0pUQUdVQVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0FMVEVSQV9V QVJUIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX0lGWDZYNjAgaXMgbm90IHNldAojIENP TkZJR19TRVJJQUxfUENIX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfWElMSU5Y X1BTX1VBUlQgaXMgbm90IHNldAojIENPTkZJR19TRVJJQUxfQVJDIGlzIG5vdCBzZXQKIyBD T05GSUdfU0VSSUFMX1JQMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFUklBTF9GU0xfTFBVQVJU IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VSSUFMX1NUX0FTQyBpcyBub3Qgc2V0CiMgQ09ORklH X1RUWV9QUklOVEsgaXMgbm90IHNldApDT05GSUdfSFZDX0RSSVZFUj15CkNPTkZJR19IVkNf SVJRPXkKQ09ORklHX0hWQ19YRU49eQpDT05GSUdfSFZDX1hFTl9GUk9OVEVORD15CiMgQ09O RklHX0hWQ19EQ0MgaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9fQ09OU09MRSBpcyBub3Qg c2V0CiMgQ09ORklHX0lQTUlfSEFORExFUiBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET009 eQojIENPTkZJR19IV19SQU5ET01fVElNRVJJT01FTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hX X1JBTkRPTV9BVE1FTCBpcyBub3Qgc2V0CkNPTkZJR19IV19SQU5ET01fT01BUD15CiMgQ09O RklHX0hXX1JBTkRPTV9WSVJUSU8gaXMgbm90IHNldAojIENPTkZJR19IV19SQU5ET01fRVhZ Tk9TIGlzIG5vdCBzZXQKIyBDT05GSUdfUjM5NjQgaXMgbm90IHNldAojIENPTkZJR19BUFBM SUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX1JBV19EUklWRVIgaXMgbm90IHNldAojIENPTkZJ R19UQ0dfVFBNIGlzIG5vdCBzZXQKQ09ORklHX0RFVlBPUlQ9eQojIENPTkZJR19EQ0NfVFRZ IGlzIG5vdCBzZXQKQ09ORklHX0kyQz15CkNPTkZJR19JMkNfQk9BUkRJTkZPPXkKQ09ORklH X0kyQ19DT01QQVQ9eQpDT05GSUdfSTJDX0NIQVJERVY9eQojIENPTkZJR19JMkNfTVVYIGlz IG5vdCBzZXQKQ09ORklHX0kyQ19IRUxQRVJfQVVUTz15CkNPTkZJR19JMkNfQUxHT0JJVD15 CgojCiMgSTJDIEhhcmR3YXJlIEJ1cyBzdXBwb3J0CiMKCiMKIyBQQyBTTUJ1cyBob3N0IGNv bnRyb2xsZXIgZHJpdmVycwojCiMgQ09ORklHX0kyQ19BTEkxNTM1IGlzIG5vdCBzZXQKIyBD T05GSUdfSTJDX0FMSTE1NjMgaXMgbm90IHNldAojIENPTkZJR19JMkNfQUxJMTVYMyBpcyBu b3Qgc2V0CiMgQ09ORklHX0kyQ19BTUQ3NTYgaXMgbm90IHNldAojIENPTkZJR19JMkNfQU1E ODExMSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19JODAxIGlzIG5vdCBzZXQKIyBDT05GSUdf STJDX0lTQ0ggaXMgbm90IHNldAojIENPTkZJR19JMkNfUElJWDQgaXMgbm90IHNldAojIENP TkZJR19JMkNfTkZPUkNFMiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM1NTk1IGlzIG5v dCBzZXQKIyBDT05GSUdfSTJDX1NJUzYzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19TSVM5 NlggaXMgbm90IHNldAojIENPTkZJR19JMkNfVklBIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJD X1ZJQVBSTyBpcyBub3Qgc2V0CgojCiMgSTJDIHN5c3RlbSBidXMgZHJpdmVycyAobW9zdGx5 IGVtYmVkZGVkIC8gc3lzdGVtLW9uLWNoaXApCiMKIyBDT05GSUdfSTJDX0NCVVNfR1BJTyBp cyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERVNJR05XQVJFX1BMQVRGT1JNIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX0RFU0lHTldBUkVfUENJIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0VH MjBUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX0dQSU8gaXMgbm90IHNldAojIENPTkZJR19J MkNfT0NPUkVTIGlzIG5vdCBzZXQKQ09ORklHX0kyQ19PTUFQPXkKIyBDT05GSUdfSTJDX1BD QV9QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QWEFfUENJIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX1NJTVRFQyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19YSUxJTlggaXMg bm90IHNldAoKIwojIEV4dGVybmFsIEkyQy9TTUJ1cyBhZGFwdGVyIGRyaXZlcnMKIwojIENP TkZJR19JMkNfRElPTEFOX1UyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19QQVJQT1JUX0xJ R0hUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1JPQk9URlVaWl9PU0lGIGlzIG5vdCBzZXQK IyBDT05GSUdfSTJDX1RBT1NfRVZNIGlzIG5vdCBzZXQKIyBDT05GSUdfSTJDX1RJTllfVVNC IGlzIG5vdCBzZXQKCiMKIyBPdGhlciBJMkMvU01CdXMgYnVzIGRyaXZlcnMKIwojIENPTkZJ R19JMkNfU1RVQiBpcyBub3Qgc2V0CiMgQ09ORklHX0kyQ19ERUJVR19DT1JFIGlzIG5vdCBz ZXQKIyBDT05GSUdfSTJDX0RFQlVHX0FMR08gaXMgbm90IHNldAojIENPTkZJR19JMkNfREVC VUdfQlVTIGlzIG5vdCBzZXQKQ09ORklHX1NQST15CiMgQ09ORklHX1NQSV9ERUJVRyBpcyBu b3Qgc2V0CkNPTkZJR19TUElfTUFTVEVSPXkKCiMKIyBTUEkgTWFzdGVyIENvbnRyb2xsZXIg RHJpdmVycwojCiMgQ09ORklHX1NQSV9BTFRFUkEgaXMgbm90IHNldAojIENPTkZJR19TUElf QklUQkFORyBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9HUElPIGlzIG5vdCBzZXQKIyBDT05G SUdfU1BJX0ZTTF9TUEkgaXMgbm90IHNldAojIENPTkZJR19TUElfT0NfVElOWSBpcyBub3Qg c2V0CkNPTkZJR19TUElfT01BUDI0WFg9eQpDT05GSUdfU1BJX1RJX1FTUEk9eQojIENPTkZJ R19TUElfUFhBMlhYIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX1BYQTJYWF9QQ0kgaXMgbm90 IHNldAojIENPTkZJR19TUElfU0MxOElTNjAyIGlzIG5vdCBzZXQKIyBDT05GSUdfU1BJX1RP UENMSUZGX1BDSCBpcyBub3Qgc2V0CiMgQ09ORklHX1NQSV9YQ09NTSBpcyBub3Qgc2V0CiMg Q09ORklHX1NQSV9YSUxJTlggaXMgbm90IHNldAojIENPTkZJR19TUElfREVTSUdOV0FSRSBp cyBub3Qgc2V0CgojCiMgU1BJIFByb3RvY29sIE1hc3RlcnMKIwpDT05GSUdfU1BJX1NQSURF Vj15CiMgQ09ORklHX1NQSV9UTEU2MlgwIGlzIG5vdCBzZXQKIyBDT05GSUdfSFNJIGlzIG5v dCBzZXQKCiMKIyBQUFMgc3VwcG9ydAojCkNPTkZJR19QUFM9eQojIENPTkZJR19QUFNfREVC VUcgaXMgbm90IHNldAoKIwojIFBQUyBjbGllbnRzIHN1cHBvcnQKIwojIENPTkZJR19QUFNf Q0xJRU5UX0tUSU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX1BQU19DTElFTlRfTERJU0MgaXMg bm90IHNldAojIENPTkZJR19QUFNfQ0xJRU5UX0dQSU8gaXMgbm90IHNldAoKIwojIFBQUyBn ZW5lcmF0b3JzIHN1cHBvcnQKIwoKIwojIFBUUCBjbG9jayBzdXBwb3J0CiMKQ09ORklHX1BU UF8xNTg4X0NMT0NLPXkKCiMKIyBFbmFibGUgUEhZTElCIGFuZCBORVRXT1JLX1BIWV9USU1F U1RBTVBJTkcgdG8gc2VlIHRoZSBhZGRpdGlvbmFsIGNsb2Nrcy4KIwpDT05GSUdfUElOQ1RS TD15CgojCiMgUGluIGNvbnRyb2xsZXJzCiMKQ09ORklHX1BJTk1VWD15CkNPTkZJR19QSU5D T05GPXkKQ09ORklHX0dFTkVSSUNfUElOQ09ORj15CiMgQ09ORklHX0RFQlVHX1BJTkNUUkwg aXMgbm90IHNldAojIENPTkZJR19QSU5DVFJMX0NBUFJJIGlzIG5vdCBzZXQKQ09ORklHX1BJ TkNUUkxfVElfSU9ERUxBWT15CiMgQ09ORklHX1BJTkNUUkxfTVNNOFg3NCBpcyBub3Qgc2V0 CkNPTkZJR19QSU5DVFJMX1NJTkdMRT15CiMgQ09ORklHX1BJTkNUUkxfUEFMTUFTIGlzIG5v dCBzZXQKQ09ORklHX0FSQ0hfSEFWRV9DVVNUT01fR1BJT19IPXkKQ09ORklHX0FSQ0hfUkVR VUlSRV9HUElPTElCPXkKQ09ORklHX0dQSU9MSUI9eQpDT05GSUdfR1BJT19ERVZSRVM9eQpD T05GSUdfT0ZfR1BJTz15CkNPTkZJR19ERUJVR19HUElPPXkKQ09ORklHX0dQSU9fU1lTRlM9 eQoKIwojIE1lbW9yeSBtYXBwZWQgR1BJTyBkcml2ZXJzOgojCiMgQ09ORklHX0dQSU9fR0VO RVJJQ19QTEFURk9STSBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fRU0gaXMgbm90IHNldAoj IENPTkZJR19HUElPX1JDQVIgaXMgbm90IHNldAojIENPTkZJR19HUElPX1NDSDMxMVggaXMg bm90IHNldAojIENPTkZJR19HUElPX1RTNTUwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9f Vlg4NTUgaXMgbm90IHNldAojIENPTkZJR19HUElPX0dSR1BJTyBpcyBub3Qgc2V0CgojCiMg STJDIEdQSU8gZXhwYW5kZXJzOgojCiMgQ09ORklHX0dQSU9fTUFYNzMwMCBpcyBub3Qgc2V0 CiMgQ09ORklHX0dQSU9fTUFYNzMyWCBpcyBub3Qgc2V0CiMgQ09ORklHX0dQSU9fUENBOTUz WF9JUlEgaXMgbm90IHNldApDT05GSUdfR1BJT19QQ0Y4NTdYPXkKIyBDT05GSUdfR1BJT19T WDE1MFggaXMgbm90IHNldAojIENPTkZJR19HUElPX1RXTDYwNDAgaXMgbm90IHNldAojIENP TkZJR19HUElPX0FEUDU1ODggaXMgbm90IHNldAojIENPTkZJR19HUElPX0FETlAgaXMgbm90 IHNldAoKIwojIFBDSSBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19HUElPX0JUOFhYIGlz IG5vdCBzZXQKIyBDT05GSUdfR1BJT19BTUQ4MTExIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJ T19NTF9JT0ggaXMgbm90IHNldAojIENPTkZJR19HUElPX1JEQzMyMVggaXMgbm90IHNldAoK IwojIFNQSSBHUElPIGV4cGFuZGVyczoKIwojIENPTkZJR19HUElPX01BWDczMDEgaXMgbm90 IHNldAojIENPTkZJR19HUElPX01DUDIzUzA4IGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19N QzMzODgwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT183NFgxNjQgaXMgbm90IHNldAoKIwoj IEFDOTcgR1BJTyBleHBhbmRlcnM6CiMKCiMKIyBMUEMgR1BJTyBleHBhbmRlcnM6CiMKCiMK IyBNT0RVTGJ1cyBHUElPIGV4cGFuZGVyczoKIwpDT05GSUdfR1BJT19QQUxNQVM9eQojIENP TkZJR19HUElPX1RQUzY1OTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfR1BJT19CQ01fS09OQSBp cyBub3Qgc2V0CgojCiMgVVNCIEdQSU8gZXhwYW5kZXJzOgojCkNPTkZJR19XMT15CkNPTkZJ R19XMV9DT049eQoKIwojIDEtd2lyZSBCdXMgTWFzdGVycwojCiMgQ09ORklHX1cxX01BU1RF Ul9NQVRST1ggaXMgbm90IHNldAojIENPTkZJR19XMV9NQVNURVJfRFMyNDkwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfTUFTVEVSX0RTMjQ4MiBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX01B U1RFUl9EUzFXTSBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX01BU1RFUl9HUElPIGlzIG5vdCBz ZXQKIyBDT05GSUdfSERRX01BU1RFUl9PTUFQIGlzIG5vdCBzZXQKCiMKIyAxLXdpcmUgU2xh dmVzCiMKIyBDT05GSUdfVzFfU0xBVkVfVEhFUk0gaXMgbm90IHNldAojIENPTkZJR19XMV9T TEFWRV9TTUVNIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDA4IGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDEzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyNDIzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDMxIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNDMzIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyNzYwIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNzgwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVzFfU0xBVkVfRFMyNzgxIGlzIG5vdCBzZXQKIyBDT05GSUdfVzFfU0xB VkVfRFMyOEUwNCBpcyBub3Qgc2V0CiMgQ09ORklHX1cxX1NMQVZFX0JRMjcwMDAgaXMgbm90 IHNldApDT05GSUdfUE9XRVJfU1VQUExZPXkKIyBDT05GSUdfUE9XRVJfU1VQUExZX0RFQlVH IGlzIG5vdCBzZXQKIyBDT05GSUdfUERBX1BPV0VSIGlzIG5vdCBzZXQKIyBDT05GSUdfR0VO RVJJQ19BRENfQkFUVEVSWSBpcyBub3Qgc2V0CiMgQ09ORklHX1RFU1RfUE9XRVIgaXMgbm90 IHNldAojIENPTkZJR19CQVRURVJZX0RTMjc4MCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRF UllfRFMyNzgxIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFUVEVSWV9EUzI3ODIgaXMgbm90IHNl dAojIENPTkZJR19CQVRURVJZX1NCUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfQlEy N3gwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0JBVFRFUllfTUFYMTcwNDAgaXMgbm90IHNldAoj IENPTkZJR19CQVRURVJZX01BWDE3MDQyIGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9J U1AxNzA0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ0hBUkdFUl9NQVg4OTAzIGlzIG5vdCBzZXQK IyBDT05GSUdfQ0hBUkdFUl9MUDg3MjcgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0dQ SU8gaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX01BTkFHRVIgaXMgbm90IHNldAojIENP TkZJR19DSEFSR0VSX0JRMjQxNVggaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQx OTAgaXMgbm90IHNldAojIENPTkZJR19DSEFSR0VSX0JRMjQ3MzUgaXMgbm90IHNldAojIENP TkZJR19DSEFSR0VSX1NNQjM0NyBpcyBub3Qgc2V0CiMgQ09ORklHX1BPV0VSX1JFU0VUIGlz IG5vdCBzZXQKIyBDT05GSUdfUE9XRVJfUkVTRVRfUkVTVEFSVCBpcyBub3Qgc2V0CkNPTkZJ R19QT1dFUl9BVlM9eQpDT05GSUdfVk9MVEFHRV9ET01BSU49eQoKIwojIFZvbHRhZ2UgRG9t YWluIEZyYW1ld29yayBEcml2ZXJzCiMKQ09ORklHX1ZPTFRBR0VfRE9NQUlOX09NQVA9eQpD T05GSUdfVElfQ09QUk9DPXkKQ09ORklHX0hXTU9OPXkKIyBDT05GSUdfSFdNT05fVklEIGlz IG5vdCBzZXQKIyBDT05GSUdfSFdNT05fREVCVUdfQ0hJUCBpcyBub3Qgc2V0CgojCiMgTmF0 aXZlIGRyaXZlcnMKIwojIENPTkZJR19TRU5TT1JTX0FENzMxNCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfQUQ3NDE0IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRDc0MTgg aXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0FEQ1hYIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRE0xMDIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI1IGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDI2IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRE0xMDI5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE0xMDMxIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRE05MjQwIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRFQ3MzEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDEwIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDExIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BRFQ3NDYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDcwIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BRFQ3NDc1IGlzIG5vdCBzZXQKIyBDT05GSUdf U0VOU09SU19BU0M3NjIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19BVFhQMSBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRFM2MjAgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0RTMTYyMSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSTVLX0FNQiBpcyBub3Qg c2V0CiMgQ09ORklHX1NFTlNPUlNfRjcxODA1RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNP UlNfRjcxODgyRkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0Y3NTM3NVMgaXMgbm90 IHNldAojIENPTkZJR19TRU5TT1JTX0c3NjBBIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19HNzYyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19HTDUxOFNNIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19HTDUyMFNNIGlzIG5vdCBzZXQKQ09ORklHX1NFTlNPUlNfR1BJ T19GQU49eQojIENPTkZJR19TRU5TT1JTX0hJSDYxMzAgaXMgbm90IHNldAojIENPTkZJR19T RU5TT1JTX0hUVTIxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19JSU9fSFdNT04gaXMg bm90IHNldAojIENPTkZJR19TRU5TT1JTX0lUODcgaXMgbm90IHNldAojIENPTkZJR19TRU5T T1JTX0pDNDIgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xJTkVBR0UgaXMgbm90IHNl dAojIENPTkZJR19TRU5TT1JTX0xNNjMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xN NzAgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX0xNNzMgaXMgbm90IHNldApDT05GSUdf U0VOU09SU19MTTc1PW0KIyBDT05GSUdfU0VOU09SU19MTTc3IGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19MTTc4IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgwIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19MTTg1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTg3IGlzIG5vdCBzZXQKIyBD T05GSUdfU0VOU09SU19MTTkwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkyIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTkzIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MVEM0MTUxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjE1IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MVEM0MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MVEM0MjYxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjM0IGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19MTTk1MjQxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19MTTk1MjQ1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxMTExIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVgxNjA2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NF TlNPUlNfTUFYMTYxOSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTY2OCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfTUFYMTk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19NQVg2NjM5IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjQyIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19NQVg2NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19NQVg2Njk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19NQ1AzMDIxIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VOU09SU19OQ1Q2Nzc1IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VO U09SU19OVENfVEhFUk1JU1RPUiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzM2 MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfUEM4NzQyNyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfUENGODU5MSBpcyBub3Qgc2V0CiMgQ09ORklHX1BNQlVTIGlzIG5vdCBz ZXQKIyBDT05GSUdfU0VOU09SU19TSFQxNSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNf U0hUMjEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NJUzU1OTUgaXMgbm90IHNldAoj IENPTkZJR19TRU5TT1JTX1NNTTY2NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRE1F MTczNyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1DMTQwMyBpcyBub3Qgc2V0CiMg Q09ORklHX1NFTlNPUlNfRU1DMjEwMyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfRU1D NlcyMDEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1NNU0M0N00xIGlzIG5vdCBzZXQK IyBDT05GSUdfU0VOU09SU19TTVNDNDdNMTkyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09S U19TTVNDNDdCMzk3IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19TQ0g1NlhYX0NPTU1P TiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfU0NINTYyNyBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfU0NINTYzNiBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTMTAx NSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQURTNzgyOCBpcyBub3Qgc2V0CiMgQ09O RklHX1NFTlNPUlNfQURTNzg3MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfQU1DNjgy MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfSU5BMjA5IGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19JTkEyWFggaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1RITUM1MCBp cyBub3Qgc2V0CkNPTkZJR19TRU5TT1JTX1RNUDEwMj15CiMgQ09ORklHX1NFTlNPUlNfVE1Q NDAxIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UTVA0MjEgaXMgbm90IHNldAojIENP TkZJR19TRU5TT1JTX1ZJQTY4NkEgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1ZUMTIx MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVlQ4MjMxIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODM3ODFEIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTFE IGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM3OTJEIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODM3OTMgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4Mzc5NSBp cyBub3Qgc2V0CiMgQ09ORklHX1NFTlNPUlNfVzgzTDc4NVRTIGlzIG5vdCBzZXQKIyBDT05G SUdfU0VOU09SU19XODNMNzg2TkcgaXMgbm90IHNldAojIENPTkZJR19TRU5TT1JTX1c4MzYy N0hGIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19XODM2MjdFSEYgaXMgbm90IHNldApD T05GSUdfVEhFUk1BTD15CkNPTkZJR19USEVSTUFMX0hXTU9OPXkKQ09ORklHX1RIRVJNQUxf T0Y9eQpDT05GSUdfVEhFUk1BTF9ERUZBVUxUX0dPVl9TVEVQX1dJU0U9eQojIENPTkZJR19U SEVSTUFMX0RFRkFVTFRfR09WX0ZBSVJfU0hBUkUgaXMgbm90IHNldAojIENPTkZJR19USEVS TUFMX0RFRkFVTFRfR09WX1VTRVJfU1BBQ0UgaXMgbm90IHNldApDT05GSUdfVEhFUk1BTF9H T1ZfRkFJUl9TSEFSRT15CkNPTkZJR19USEVSTUFMX0dPVl9TVEVQX1dJU0U9eQpDT05GSUdf VEhFUk1BTF9HT1ZfVVNFUl9TUEFDRT15CkNPTkZJR19DUFVfVEhFUk1BTD15CiMgQ09ORklH X1RIRVJNQUxfRU1VTEFUSU9OIGlzIG5vdCBzZXQKIyBDT05GSUdfSU1YX1RIRVJNQUwgaXMg bm90IHNldAoKIwojIFRleGFzIEluc3RydW1lbnRzIHRoZXJtYWwgZHJpdmVycwojCkNPTkZJ R19USV9TT0NfVEhFUk1BTD15CkNPTkZJR19USV9USEVSTUFMPXkKQ09ORklHX0RSQTc1Ml9U SEVSTUFMPXkKQ09ORklHX1dBVENIRE9HPXkKQ09ORklHX1dBVENIRE9HX0NPUkU9eQojIENP TkZJR19XQVRDSERPR19OT1dBWU9VVCBpcyBub3Qgc2V0CgojCiMgV2F0Y2hkb2cgRGV2aWNl IERyaXZlcnMKIwojIENPTkZJR19TT0ZUX1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdf R1BJT19XQVRDSERPRyBpcyBub3Qgc2V0CiMgQ09ORklHX0RXX1dBVENIRE9HIGlzIG5vdCBz ZXQKQ09ORklHX09NQVBfV0FUQ0hET0c9eQojIENPTkZJR19NQVg2M1hYX1dBVENIRE9HIGlz IG5vdCBzZXQKIyBDT05GSUdfQUxJTTcxMDFfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfSTYz MDBFU0JfV0RUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVOX0EyMV9XRFQgaXMgbm90IHNldAoj IENPTkZJR19YRU5fV0RUIGlzIG5vdCBzZXQKCiMKIyBQQ0ktYmFzZWQgV2F0Y2hkb2cgQ2Fy ZHMKIwojIENPTkZJR19QQ0lQQ1dBVENIRE9HIGlzIG5vdCBzZXQKIyBDT05GSUdfV0RUUENJ IGlzIG5vdCBzZXQKCiMKIyBVU0ItYmFzZWQgV2F0Y2hkb2cgQ2FyZHMKIwojIENPTkZJR19V U0JQQ1dBVENIRE9HIGlzIG5vdCBzZXQKQ09ORklHX1NTQl9QT1NTSUJMRT15CgojCiMgU29u aWNzIFNpbGljb24gQmFja3BsYW5lCiMKIyBDT05GSUdfU1NCIGlzIG5vdCBzZXQKQ09ORklH X0JDTUFfUE9TU0lCTEU9eQoKIwojIEJyb2FkY29tIHNwZWNpZmljIEFNQkEKIwojIENPTkZJ R19CQ01BIGlzIG5vdCBzZXQKCiMKIyBNdWx0aWZ1bmN0aW9uIGRldmljZSBkcml2ZXJzCiMK Q09ORklHX01GRF9DT1JFPXkKIyBDT05GSUdfTUZEX0FTMzcxMSBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9BUzM3MjIgaXMgbm90IHNldAojIENPTkZJR19QTUlDX0FEUDU1MjAgaXMgbm90 IHNldAojIENPTkZJR19NRkRfQUFUMjg3MF9DT1JFIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X0NST1NfRUMgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVNJQzMgaXMgbm90IHNldAojIENP TkZJR19QTUlDX0RBOTAzWCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9EQTkwNTJfU1BJIGlz IG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA1Ml9JMkMgaXMgbm90IHNldAojIENPTkZJR19N RkRfREE5MDU1IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX0RBOTA2MyBpcyBub3Qgc2V0CiMg Q09ORklHX01GRF9NQzEzWFhYX1NQSSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQzEzWFhY X0kyQyBpcyBub3Qgc2V0CiMgQ09ORklHX0hUQ19FR1BJTyBpcyBub3Qgc2V0CiMgQ09ORklH X0hUQ19QQVNJQzMgaXMgbm90IHNldAojIENPTkZJR19IVENfSTJDUExEIGlzIG5vdCBzZXQK IyBDT05GSUdfTFBDX0lDSCBpcyBub3Qgc2V0CiMgQ09ORklHX0xQQ19TQ0ggaXMgbm90IHNl dAojIENPTkZJR19NRkRfSkFOWl9DTU9ESU8gaXMgbm90IHNldAojIENPTkZJR19NRkRfS0VN UExEIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEXzg4UE04MDAgaXMgbm90IHNldAojIENPTkZJ R19NRkRfODhQTTgwNSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF84OFBNODYwWCBpcyBub3Qg c2V0CiMgQ09ORklHX01GRF9NQVgxNDU3NyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3 NzY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg3NzY5MyBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9NQVg4OTA3IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX01BWDg5MjUgaXMgbm90 IHNldAojIENPTkZJR19NRkRfTUFYODk5NyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9NQVg4 OTk4IGlzIG5vdCBzZXQKIyBDT05GSUdfRVpYX1BDQVAgaXMgbm90IHNldAojIENPTkZJR19N RkRfVklQRVJCT0FSRCBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9SRVRVIGlzIG5vdCBzZXQK IyBDT05GSUdfTUZEX1BDRjUwNjMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1JEQzMyMVgg aXMgbm90IHNldAojIENPTkZJR19NRkRfUlRTWF9QQ0kgaXMgbm90IHNldAojIENPTkZJR19N RkRfUkM1VDU4MyBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TRUNfQ09SRSBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9TSTQ3NlhfQ09SRSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTTUw MSBpcyBub3Qgc2V0CiMgQ09ORklHX01GRF9TTVNDIGlzIG5vdCBzZXQKIyBDT05GSUdfQUJY NTAwX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19NRkRfU1RNUEUgaXMgbm90IHNldApDT05G SUdfTUZEX1NZU0NPTj15CkNPTkZJR19NRkRfVElfQU0zMzVYX1RTQ0FEQz15CiMgQ09ORklH X01GRF9MUDM5NDMgaXMgbm90IHNldAojIENPTkZJR19NRkRfTFA4Nzg4IGlzIG5vdCBzZXQK Q09ORklHX01GRF9PTUFQX1VTQl9IT1NUPXkKQ09ORklHX01GRF9QQUxNQVM9eQojIENPTkZJ R19UUFM2MTA1WCBpcyBub3Qgc2V0CiMgQ09ORklHX1RQUzY1MDEwIGlzIG5vdCBzZXQKIyBD T05GSUdfVFBTNjUwN1ggaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjUwOTAgaXMgbm90 IHNldApDT05GSUdfTUZEX1RQUzY1MjE3PXkKQ09ORklHX01GRF9UUFM2NTIxOD15CiMgQ09O RklHX01GRF9UUFM2NTg2WCBpcyBub3Qgc2V0CkNPTkZJR19NRkRfVFBTNjU5MTA9eQojIENP TkZJR19NRkRfVFBTNjU5MTIgaXMgbm90IHNldAojIENPTkZJR19NRkRfVFBTNjU5MTJfSTJD IGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1RQUzY1OTEyX1NQSSBpcyBub3Qgc2V0CiMgQ09O RklHX01GRF9UUFM4MDAzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1RXTDQwMzBfQ09SRSBpcyBu b3Qgc2V0CkNPTkZJR19UV0w2MDQwX0NPUkU9eQojIENPTkZJR19NRkRfV0wxMjczX0NPUkUg aXMgbm90IHNldAojIENPTkZJR19NRkRfTE0zNTMzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X1RJTUJFUkRBTEUgaXMgbm90IHNldAojIENPTkZJR19NRkRfVEMzNTg5WCBpcyBub3Qgc2V0 CiMgQ09ORklHX01GRF9UTUlPIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZEX1Q3TDY2WEIgaXMg bm90IHNldAojIENPTkZJR19NRkRfVEM2Mzg3WEIgaXMgbm90IHNldAojIENPTkZJR19NRkRf VEM2MzkzWEIgaXMgbm90IHNldAojIENPTkZJR19NRkRfVlg4NTUgaXMgbm90IHNldAojIENP TkZJR19NRkRfQVJJWk9OQV9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfQVJJWk9OQV9T UEkgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004NDAwIGlzIG5vdCBzZXQKIyBDT05GSUdf TUZEX1dNODMxWF9JMkMgaXMgbm90IHNldAojIENPTkZJR19NRkRfV004MzFYX1NQSSBpcyBu b3Qgc2V0CiMgQ09ORklHX01GRF9XTTgzNTBfSTJDIGlzIG5vdCBzZXQKIyBDT05GSUdfTUZE X1dNODk5NCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZFWFBSRVNTX0NPTkZJRyBpcyBub3Qgc2V0 CkNPTkZJR19SRUdVTEFUT1I9eQojIENPTkZJR19SRUdVTEFUT1JfREVCVUcgaXMgbm90IHNl dApDT05GSUdfUkVHVUxBVE9SX0ZJWEVEX1ZPTFRBR0U9eQojIENPTkZJR19SRUdVTEFUT1Jf VklSVFVBTF9DT05TVU1FUiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9VU0VSU1BB Q0VfQ09OU1VNRVIgaXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfQUNUODg2NSBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9BRDUzOTggaXMgbm90IHNldAojIENPTkZJR19S RUdVTEFUT1JfQU5BVE9QIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0RBOTIxMCBp cyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9GQU41MzU1NSBpcyBub3Qgc2V0CkNPTkZJ R19SRUdVTEFUT1JfR1BJTz15CiMgQ09ORklHX1JFR1VMQVRPUl9JU0w2MjcxQSBpcyBub3Qg c2V0CiMgQ09ORklHX1JFR1VMQVRPUl9MUDM5NzEgaXMgbm90IHNldAojIENPTkZJR19SRUdV TEFUT1JfTFAzOTcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX0xQODcyWCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9MUDg3NTUgaXMgbm90IHNldAojIENPTkZJR19S RUdVTEFUT1JfTUFYMTU4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9NQVg4NjQ5 IGlzIG5vdCBzZXQKIyBDT05GSUdfUkVHVUxBVE9SX01BWDg2NjAgaXMgbm90IHNldAojIENP TkZJR19SRUdVTEFUT1JfTUFYODk1MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JFR1VMQVRPUl9N QVg4OTczIGlzIG5vdCBzZXQKQ09ORklHX1JFR1VMQVRPUl9QQUxNQVM9eQpDT05GSUdfUkVH VUxBVE9SX1BCSUFTPXkKIyBDT05GSUdfUkVHVUxBVE9SX1BGVVpFMTAwIGlzIG5vdCBzZXQK Q09ORklHX1JFR1VMQVRPUl9USV9BQkI9eQojIENPTkZJR19SRUdVTEFUT1JfVFBTNTE2MzIg aXMgbm90IHNldAojIENPTkZJR19SRUdVTEFUT1JfVFBTNjIzNjAgaXMgbm90IHNldApDT05G SUdfUkVHVUxBVE9SX1RQUzY1MDIzPXkKQ09ORklHX1JFR1VMQVRPUl9UUFM2NTA3WD15CkNP TkZJR19SRUdVTEFUT1JfVFBTNjUyMTc9eQpDT05GSUdfUkVHVUxBVE9SX1RQUzY1MjE4PXkK IyBDT05GSUdfUkVHVUxBVE9SX1RQUzY1MjRYIGlzIG5vdCBzZXQKQ09ORklHX1JFR1VMQVRP Ul9UUFM2NTkxMD15CkNPTkZJR19NRURJQV9TVVBQT1JUPXkKCiMKIyBNdWx0aW1lZGlhIGNv cmUgc3VwcG9ydAojCkNPTkZJR19NRURJQV9DQU1FUkFfU1VQUE9SVD15CiMgQ09ORklHX01F RElBX0FOQUxPR19UVl9TVVBQT1JUIGlzIG5vdCBzZXQKIyBDT05GSUdfTUVESUFfRElHSVRB TF9UVl9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX1JBRElPX1NVUFBPUlQ9eQoj IENPTkZJR19NRURJQV9SQ19TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX01FRElBX0NPTlRS T0xMRVI9eQpDT05GSUdfVklERU9fREVWPXkKQ09ORklHX1ZJREVPX1Y0TDJfU1VCREVWX0FQ ST15CkNPTkZJR19WSURFT19WNEwyPXkKIyBDT05GSUdfVklERU9fQURWX0RFQlVHIGlzIG5v dCBzZXQKIyBDT05GSUdfVklERU9fRklYRURfTUlOT1JfUkFOR0VTIGlzIG5vdCBzZXQKQ09O RklHX1Y0TDJfTUVNMk1FTV9ERVY9bQpDT05GSUdfVklERU9CVUYyX0NPUkU9bQpDT05GSUdf VklERU9CVUYyX01FTU9QUz1tCkNPTkZJR19WSURFT0JVRjJfRE1BX0NPTlRJRz1tCkNPTkZJ R19WSURFT0JVRjJfVk1BTExPQz1tCiMgQ09ORklHX1RUUENJX0VFUFJPTSBpcyBub3Qgc2V0 CgojCiMgTWVkaWEgZHJpdmVycwojCkNPTkZJR19NRURJQV9VU0JfU1VQUE9SVD15CgojCiMg V2ViY2FtIGRldmljZXMKIwpDT05GSUdfVVNCX1ZJREVPX0NMQVNTPW0KQ09ORklHX1VTQl9W SURFT19DTEFTU19JTlBVVF9FVkRFVj15CkNPTkZJR19VU0JfR1NQQ0E9bQojIENPTkZJR19V U0JfTTU2MDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RWMDZYWCBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9HTDg2MCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9CRU5RIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0NPTkVYIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX0NQSUExIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0VUT01TIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX0ZJTkVQSVggaXMgbm90IHNldAojIENPTkZJ R19VU0JfR1NQQ0FfSkVJTElOSiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9KTDIw MDVCQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfS0lORUNUIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0dTUENBX0tPTklDQSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BD QV9NQVJTIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX01SOTczMTBBIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX05XODBYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dT UENBX09WNTE5IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX09WNTM0IGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0dTUENBX09WNTM0XzkgaXMgbm90IHNldAojIENPTkZJR19VU0Jf R1NQQ0FfUEFDMjA3IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1BBQzczMDIgaXMg bm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfUEFDNzMxMSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9HU1BDQV9TRTQwMSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TTjlDMjAy OCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TTjlDMjBYIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX0dTUENBX1NPTklYQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9T T05JWEogaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTUwMCBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTAxIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dT UENBX1NQQ0E1MDUgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTUwNiBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TUENBNTA4IGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX0dTUENBX1NQQ0E1NjEgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1BDQTE1 MjggaXMgbm90IHNldAojIENPTkZJR19VU0JfR1NQQ0FfU1E5MDUgaXMgbm90IHNldAojIENP TkZJR19VU0JfR1NQQ0FfU1E5MDVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NR OTMwWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9TVEswMTQgaXMgbm90IHNldAoj IENPTkZJR19VU0JfR1NQQ0FfU1RLMTEzNSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BD QV9TVFYwNjgwIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1NVTlBMVVMgaXMgbm90 IHNldAojIENPTkZJR19VU0JfR1NQQ0FfVDYxMyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9H U1BDQV9UT1BSTyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9HU1BDQV9UVjg1MzIgaXMgbm90 IHNldAojIENPTkZJR19VU0JfR1NQQ0FfVkMwMzJYIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0dTUENBX1ZJQ0FNIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1hJUkxJTktfQ0lU IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0dTUENBX1pDM1hYIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1BXQyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NQSUEyIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1pSMzY0WFggaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RLV0VCQ0FN IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1MyMjU1IGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVVNCVFYgaXMgbm90IHNldAoKIwojIFdlYmNhbSwgVFYgKGFuYWxvZy9kaWdpdGFsKSBV U0IgZGV2aWNlcwojCiMgQ09ORklHX1ZJREVPX0VNMjhYWCBpcyBub3Qgc2V0CiMgQ09ORklH X01FRElBX1BDSV9TVVBQT1JUIGlzIG5vdCBzZXQKQ09ORklHX1Y0TF9QTEFURk9STV9EUklW RVJTPXkKIyBDT05GSUdfVklERU9fQ0FGRV9DQ0lDIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVElNQkVSREFMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1NPQ19DQU1FUkEgaXMgbm90IHNl dApDT05GSUdfVklERU9fVElfVklQPW0KQ09ORklHX1Y0TF9NRU0yTUVNX0RSSVZFUlM9eQoj IENPTkZJR19WSURFT19NRU0yTUVNX0RFSU5URVJMQUNFIGlzIG5vdCBzZXQKIyBDT05GSUdf VklERU9fU0hfVkVVIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUkVORVNBU19WU1AxIGlz IG5vdCBzZXQKQ09ORklHX1ZJREVPX1RJX1ZQRT1tCiMgQ09ORklHX1ZJREVPX1RJX1ZQRV9E RUJVRyBpcyBub3Qgc2V0CkNPTkZJR19WSURFT19USV9WUERNQV9IRUxQRVI9bQojIENPTkZJ R19WSURFT19USV9WUERNQV9MT0FEX0ZXIGlzIG5vdCBzZXQKIyBDT05GSUdfVjRMX1RFU1Rf RFJJVkVSUyBpcyBub3Qgc2V0CgojCiMgU3VwcG9ydGVkIE1NQy9TRElPIGFkYXB0ZXJzCiMK Q09ORklHX1JBRElPX0FEQVBURVJTPXkKIyBDT05GSUdfUkFESU9fU0k0NzBYIGlzIG5vdCBz ZXQKQ09ORklHX0RSQTdYWF9SQURJT19IRUxQRVI9eQojIENPTkZJR19SQURJT19TSTQ3MTMg aXMgbm90IHNldAojIENPTkZJR19VU0JfTVI4MDAgaXMgbm90IHNldAojIENPTkZJR19VU0Jf RFNCUiBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX01BWElSQURJTyBpcyBub3Qgc2V0CiMg Q09ORklHX1JBRElPX1NIQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfUkFESU9fU0hBUksyIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX0tFRU5FIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JB UkVNT05PIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01BOTAxIGlzIG5vdCBzZXQKIyBDT05G SUdfUkFESU9fVEVBNTc2NCBpcyBub3Qgc2V0CiMgQ09ORklHX1JBRElPX1NBQTc3MDZIIGlz IG5vdCBzZXQKIyBDT05GSUdfUkFESU9fVEVGNjg2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1JB RElPX1dMMTI3MyBpcyBub3Qgc2V0CgojCiMgVGV4YXMgSW5zdHJ1bWVudHMgV0wxMjh4IEZN IGRyaXZlciAoU1QgYmFzZWQpCiMKIyBDT05GSUdfUkFESU9fV0wxMjhYIGlzIG5vdCBzZXQK IyBDT05GSUdfQ1lQUkVTU19GSVJNV0FSRSBpcyBub3Qgc2V0CgojCiMgTWVkaWEgYW5jaWxs YXJ5IGRyaXZlcnMgKHR1bmVycywgc2Vuc29ycywgaTJjLCBmcm9udGVuZHMpCiMKIyBDT05G SUdfTUVESUFfU1VCRFJWX0FVVE9TRUxFQ1QgaXMgbm90IHNldApDT05GSUdfTUVESUFfQVRU QUNIPXkKCiMKIyBFbmNvZGVycywgZGVjb2RlcnMsIHNlbnNvcnMgYW5kIG90aGVyIGhlbHBl ciBjaGlwcwojCgojCiMgQXVkaW8gZGVjb2RlcnMsIHByb2Nlc3NvcnMgYW5kIG1peGVycwoj CiMgQ09ORklHX1ZJREVPX1RWQVVESU8gaXMgbm90IHNldAojIENPTkZJR19WSURFT19UREE3 NDMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVERBOTg0MCBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1RFQTY0MTVDIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVEVBNjQyMCBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01TUDM0MDAgaXMgbm90IHNldAojIENPTkZJR19W SURFT19DUzUzNDUgaXMgbm90IHNldAojIENPTkZJR19WSURFT19DUzUzTDMyQSBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX1RMVjMyMEFJQzIzQiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX1VEQTEzNDIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19XTTg3NzUgaXMgbm90IHNl dAojIENPTkZJR19WSURFT19XTTg3MzkgaXMgbm90IHNldAojIENPTkZJR19WSURFT19WUDI3 U01QWCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NPTllfQlRGX01QWCBpcyBub3Qgc2V0 CgojCiMgUkRTIGRlY29kZXJzCiMKIyBDT05GSUdfVklERU9fU0FBNjU4OCBpcyBub3Qgc2V0 CgojCiMgVmlkZW8gZGVjb2RlcnMKIwojIENPTkZJR19WSURFT19BRFY3MTgwIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fQURWNzE4MyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0FE Vjc2MDQgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BRFY3ODQyIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fQlQ4MTkgaXMgbm90IHNldAojIENPTkZJR19WSURFT19CVDg1NiBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX0JUODY2IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9f S1MwMTI3IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fTUw4NlY3NjY3IGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fU0FBNzExMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NBQTcx MVggaXMgbm90IHNldAojIENPTkZJR19WSURFT19TQUE3MTkxIGlzIG5vdCBzZXQKIyBDT05G SUdfVklERU9fVFZQNTE0WCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1RWUDUxNTAgaXMg bm90IHNldAojIENPTkZJR19WSURFT19UVlA3MDAyIGlzIG5vdCBzZXQKIyBDT05GSUdfVklE RU9fVFcyODA0IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVFc5OTAzIGlzIG5vdCBzZXQK IyBDT05GSUdfVklERU9fVFc5OTA2IGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVlBYMzIy MCBpcyBub3Qgc2V0CgojCiMgVmlkZW8gYW5kIGF1ZGlvIGRlY29kZXJzCiMKIyBDT05GSUdf VklERU9fU0FBNzE3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX0NYMjU4NDAgaXMgbm90 IHNldAoKIwojIFZpZGVvIGVuY29kZXJzCiMKIyBDT05GSUdfVklERU9fU0FBNzEyNyBpcyBu b3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NBQTcxODUgaXMgbm90IHNldAojIENPTkZJR19WSURF T19BRFY3MTcwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzE3NSBpcyBub3Qgc2V0 CiMgQ09ORklHX1ZJREVPX0FEVjczNDMgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BRFY3 MzkzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQURWNzUxMSBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX0FEOTM4OUIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19BSzg4MVggaXMg bm90IHNldAojIENPTkZJR19WSURFT19USFM4MjAwIGlzIG5vdCBzZXQKCiMKIyBDYW1lcmEg c2Vuc29yIGRldmljZXMKIwpDT05GSUdfVklERU9fT1YyNjU5PW0KIyBDT05GSUdfVklERU9f T1Y3NjQwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1Y3NjcwIGlzIG5vdCBzZXQKIyBD T05GSUdfVklERU9fT1Y5NjUwIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fVlM2NjI0IGlz IG5vdCBzZXQKIyBDT05GSUdfVklERU9fTVQ5TTAzMiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX01UOVAwMzEgaXMgbm90IHNldAojIENPTkZJR19WSURFT19NVDlUMDAxIGlzIG5vdCBz ZXQKIyBDT05GSUdfVklERU9fTVQ5VjAxMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX01U OVYwMzIgaXMgbm90IHNldAojIENPTkZJR19WSURFT19TUjAzMFBDMzAgaXMgbm90IHNldAoj IENPTkZJR19WSURFT19OT09OMDEwUEMzMCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX001 TU9MUyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1M1SzZBQSBpcyBub3Qgc2V0CiMgQ09O RklHX1ZJREVPX1M1SzRFQ0dYIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fUzVLNUJBRiBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX1NNSUFQUCBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJ REVPX1M1QzczTTMgaXMgbm90IHNldAoKIwojIEZsYXNoIGRldmljZXMKIwojIENPTkZJR19W SURFT19BRFAxNjUzIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fQVMzNjQ1QSBpcyBub3Qg c2V0CiMgQ09ORklHX1ZJREVPX0xNMzU2MCBpcyBub3Qgc2V0CgojCiMgVmlkZW8gaW1wcm92 ZW1lbnQgY2hpcHMKIwojIENPTkZJR19WSURFT19VUEQ2NDAzMUEgaXMgbm90IHNldAojIENP TkZJR19WSURFT19VUEQ2NDA4MyBpcyBub3Qgc2V0CgojCiMgQXVkaW8vVmlkZW8gY29tcHJl c3Npb24gY2hpcHMKIwojIENPTkZJR19WSURFT19TQUE2NzUySFMgaXMgbm90IHNldAoKIwoj IE1pc2NlbGxhbmVvdXMgaGVscGVyIGNoaXBzCiMKIyBDT05GSUdfVklERU9fVEhTNzMwMyBp cyBub3Qgc2V0CiMgQ09ORklHX1ZJREVPX001Mjc5MCBpcyBub3Qgc2V0CgojCiMgU2Vuc29y cyB1c2VkIG9uIHNvY19jYW1lcmEgZHJpdmVyCiMKQ09ORklHX01FRElBX1RVTkVSPXkKCiMK IyBDdXN0b21pemUgVFYgdHVuZXJzCiMKQ09ORklHX01FRElBX1RVTkVSX1NJTVBMRT1tCkNP TkZJR19NRURJQV9UVU5FUl9UREE4MjkwPW0KQ09ORklHX01FRElBX1RVTkVSX1REQTgyN1g9 bQpDT05GSUdfTUVESUFfVFVORVJfVERBMTgyNzE9bQpDT05GSUdfTUVESUFfVFVORVJfVERB OTg4Nz1tCkNPTkZJR19NRURJQV9UVU5FUl9URUE1NzYxPW0KQ09ORklHX01FRElBX1RVTkVS X1RFQTU3Njc9bQpDT05GSUdfTUVESUFfVFVORVJfTVQyMFhYPW0KQ09ORklHX01FRElBX1RV TkVSX01UMjA2MD1tCkNPTkZJR19NRURJQV9UVU5FUl9NVDIwNjM9bQpDT05GSUdfTUVESUFf VFVORVJfTVQyMjY2PW0KQ09ORklHX01FRElBX1RVTkVSX01UMjEzMT1tCkNPTkZJR19NRURJ QV9UVU5FUl9RVDEwMTA9bQpDT05GSUdfTUVESUFfVFVORVJfWEMyMDI4PW0KQ09ORklHX01F RElBX1RVTkVSX1hDNTAwMD1tCkNPTkZJR19NRURJQV9UVU5FUl9YQzQwMDA9bQpDT05GSUdf TUVESUFfVFVORVJfTVhMNTAwNVM9bQpDT05GSUdfTUVESUFfVFVORVJfTVhMNTAwN1Q9bQpD T05GSUdfTUVESUFfVFVORVJfTUM0NFM4MDM9bQpDT05GSUdfTUVESUFfVFVORVJfTUFYMjE2 NT1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODIxOD1tCkNPTkZJR19NRURJQV9UVU5FUl9G QzAwMTE9bQpDT05GSUdfTUVESUFfVFVORVJfRkMwMDEyPW0KQ09ORklHX01FRElBX1RVTkVS X0ZDMDAxMz1tCkNPTkZJR19NRURJQV9UVU5FUl9UREExODIxMj1tCkNPTkZJR19NRURJQV9U VU5FUl9FNDAwMD1tCkNPTkZJR19NRURJQV9UVU5FUl9GQzI1ODA9bQpDT05GSUdfTUVESUFf VFVORVJfTTg4VFMyMDIyPW0KQ09ORklHX01FRElBX1RVTkVSX1RVQTkwMDE9bQpDT05GSUdf TUVESUFfVFVORVJfSVQ5MTNYPW0KQ09ORklHX01FRElBX1RVTkVSX1I4MjBUPW0KCiMKIyBD dXN0b21pc2UgRFZCIEZyb250ZW5kcwojCkNPTkZJR19EVkJfQVU4NTIyPW0KQ09ORklHX0RW Ql9BVTg1MjJfVjRMPW0KQ09ORklHX0RWQl9UVU5FUl9ESUIwMDcwPW0KQ09ORklHX0RWQl9U VU5FUl9ESUIwMDkwPW0KCiMKIyBUb29scyB0byBkZXZlbG9wIG5ldyBmcm9udGVuZHMKIwoj IENPTkZJR19EVkJfRFVNTVlfRkUgaXMgbm90IHNldAoKIwojIEdyYXBoaWNzIHN1cHBvcnQK IwpDT05GSUdfVkdBX0FSQj15CkNPTkZJR19WR0FfQVJCX01BWF9HUFVTPTE2CgojCiMgRGly ZWN0IFJlbmRlcmluZyBNYW5hZ2VyCiMKQ09ORklHX0RSTT15CkNPTkZJR19EUk1fS01TX0hF TFBFUj15CkNPTkZJR19EUk1fS01TX0ZCX0hFTFBFUj15CiMgQ09ORklHX0RSTV9MT0FEX0VE SURfRklSTVdBUkUgaXMgbm90IHNldApDT05GSUdfRFJNX0dFTV9DTUFfSEVMUEVSPXkKQ09O RklHX0RSTV9LTVNfQ01BX0hFTFBFUj15CgojCiMgSTJDIGVuY29kZXIgb3IgaGVscGVyIGNo aXBzCiMKIyBDT05GSUdfRFJNX0kyQ19DSDcwMDYgaXMgbm90IHNldAojIENPTkZJR19EUk1f STJDX1NJTDE2NCBpcyBub3Qgc2V0CkNPTkZJR19EUk1fSTJDX05YUF9UREE5OThYPXkKIyBD T05GSUdfRFJNX1RERlggaXMgbm90IHNldAojIENPTkZJR19EUk1fUjEyOCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RSTV9SQURFT04gaXMgbm90IHNldAojIENPTkZJR19EUk1fTk9VVkVBVSBp cyBub3Qgc2V0CiMgQ09ORklHX0RSTV9NR0EgaXMgbm90IHNldAojIENPTkZJR19EUk1fVklB IGlzIG5vdCBzZXQKIyBDT05GSUdfRFJNX1NBVkFHRSBpcyBub3Qgc2V0CiMgQ09ORklHX0RS TV9FWFlOT1MgaXMgbm90IHNldAojIENPTkZJR19EUk1fVk1XR0ZYIGlzIG5vdCBzZXQKIyBD T05GSUdfRFJNX1VETCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BU1QgaXMgbm90IHNldAoj IENPTkZJR19EUk1fTUdBRzIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9DSVJSVVNfUUVN VSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9BUk1BREEgaXMgbm90IHNldAojIENPTkZJR19E Uk1fUkNBUl9EVSBpcyBub3Qgc2V0CiMgQ09ORklHX0RSTV9TSE1PQklMRSBpcyBub3Qgc2V0 CkNPTkZJR19EUk1fT01BUD15CkNPTkZJR19EUk1fT01BUF9OVU1fQ1JUQ1M9MgpDT05GSUdf RFJNX1RJTENEQz15CiMgQ09ORklHX0RSTV9RWEwgaXMgbm90IHNldAojIENPTkZJR19EUk1f Qk9DSFMgaXMgbm90IHNldAoKIwojIEZyYW1lIGJ1ZmZlciBEZXZpY2VzCiMKQ09ORklHX0ZC PXkKQ09ORklHX0ZJUk1XQVJFX0VESUQ9eQojIENPTkZJR19GQl9EREMgaXMgbm90IHNldAoj IENPTkZJR19GQl9CT09UX1ZFU0FfU1VQUE9SVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NG Ql9GSUxMUkVDVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0NGQl9DT1BZQVJFQSBpcyBub3Qg c2V0CiMgQ09ORklHX0ZCX0NGQl9JTUFHRUJMSVQgaXMgbm90IHNldAojIENPTkZJR19GQl9D RkJfUkVWX1BJWEVMU19JTl9CWVRFIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19GSUxMUkVD VD15CkNPTkZJR19GQl9TWVNfQ09QWUFSRUE9eQpDT05GSUdfRkJfU1lTX0lNQUdFQkxJVD15 CiMgQ09ORklHX0ZCX0ZPUkVJR05fRU5ESUFOIGlzIG5vdCBzZXQKQ09ORklHX0ZCX1NZU19G T1BTPXkKQ09ORklHX0ZCX0RFRkVSUkVEX0lPPXkKIyBDT05GSUdfRkJfU1ZHQUxJQiBpcyBu b3Qgc2V0CiMgQ09ORklHX0ZCX01BQ01PREVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQkFD S0xJR0hUIGlzIG5vdCBzZXQKQ09ORklHX0ZCX01PREVfSEVMUEVSUz15CkNPTkZJR19GQl9U SUxFQkxJVFRJTkc9eQoKIwojIEZyYW1lIGJ1ZmZlciBoYXJkd2FyZSBkcml2ZXJzCiMKIyBD T05GSUdfRkJfQ0lSUlVTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0yIGlzIG5vdCBzZXQK IyBDT05GSUdfRkJfQ1lCRVIyMDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfQVNJTElBTlQg aXMgbm90IHNldAojIENPTkZJR19GQl9JTVNUVCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1VW RVNBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfT1BFTkNPUkVTIGlzIG5vdCBzZXQKIyBDT05G SUdfRkJfUzFEMTNYWFggaXMgbm90IHNldAojIENPTkZJR19GQl9OVklESUEgaXMgbm90IHNl dAojIENPTkZJR19GQl9SSVZBIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfSTc0MCBpcyBub3Qg c2V0CiMgQ09ORklHX0ZCX01BVFJPWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1JBREVPTiBp cyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FUWTEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX0FU WSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1MzIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0FW QUdFIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lTIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf TkVPTUFHSUMgaXMgbm90IHNldAojIENPTkZJR19GQl9LWVJPIGlzIG5vdCBzZXQKIyBDT05G SUdfRkJfM0RGWCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1ZPT0RPTzEgaXMgbm90IHNldAoj IENPTkZJR19GQl9WVDg2MjMgaXMgbm90IHNldAojIENPTkZJR19GQl9UUklERU5UIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQVJLIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfUE0zIGlzIG5v dCBzZXQKIyBDT05GSUdfRkJfQ0FSTUlORSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX1RNSU8g aXMgbm90IHNldAojIENPTkZJR19GQl9TTVNDVUZYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf VURMIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfR09MREZJU0ggaXMgbm90IHNldAojIENPTkZJ R19GQl9WSVJUVUFMIGlzIG5vdCBzZXQKQ09ORklHX1hFTl9GQkRFVl9GUk9OVEVORD15CiMg Q09ORklHX0ZCX01FVFJPTk9NRSBpcyBub3Qgc2V0CiMgQ09ORklHX0ZCX01CODYyWFggaXMg bm90IHNldAojIENPTkZJR19GQl9CUk9BRFNIRUVUIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJf QVVPX0sxOTBYIGlzIG5vdCBzZXQKIyBDT05GSUdfRkJfU0lNUExFIGlzIG5vdCBzZXQKQ09O RklHX09NQVAyX0RTU19JTklUPXkKQ09ORklHX09NQVAyX0RTUz15CiMgQ09ORklHX09NQVAy X0RTU19ERUJVRyBpcyBub3Qgc2V0CiMgQ09ORklHX09NQVAyX0RTU19ERUJVR0ZTIGlzIG5v dCBzZXQKQ09ORklHX09NQVAyX0RTU19EUEk9eQpDT05GSUdfT01BUDJfRFNTX1ZFTkM9eQpD T05GSUdfT01BUDJfRFNTX0hETUlfQ09NTU9OPXkKQ09ORklHX09NQVBfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDRfRFNTX0hETUk9eQpDT05GSUdfT01BUDRfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDVfRFNTX0hETUk9eQpDT05GSUdfT01BUDVfRFNTX0hETUlfQVVE SU89eQpDT05GSUdfT01BUDJfRFNTX1NEST15CkNPTkZJR19PTUFQMl9EU1NfRFNJPXkKQ09O RklHX09NQVAyX0RTU19NSU5fRkNLX1BFUl9QQ0s9MApDT05GSUdfT01BUDJfRFNTX1NMRUVQ X0FGVEVSX1ZFTkNfUkVTRVQ9eQoKIwojIE9NQVAgRGlzcGxheSBEZXZpY2UgRHJpdmVycyAo bmV3IGRldmljZSBtb2RlbCkKIwpDT05GSUdfRElTUExBWV9FTkNPREVSX1RGUDQxMD1tCkNP TkZJR19ESVNQTEFZX0VOQ09ERVJfVFBEMTJTMDE1PXkKQ09ORklHX0RJU1BMQVlfRFJBN0VW TV9FTkNPREVSX1RQRDEyUzAxNT15CkNPTkZJR19ESVNQTEFZX0VOQ09ERVJfU0lJOTAyMj15 CkNPTkZJR19ESVNQTEFZX0VOQ09ERVJfU0lJOTAyMl9BVURJT19DT0RFQz15CkNPTkZJR19E SVNQTEFZX0NPTk5FQ1RPUl9EVkk9bQpDT05GSUdfRElTUExBWV9DT05ORUNUT1JfSERNST15 CiMgQ09ORklHX0RJU1BMQVlfQ09OTkVDVE9SX0FOQUxPR19UViBpcyBub3Qgc2V0CkNPTkZJ R19ESVNQTEFZX1BBTkVMX0RQST15CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfRFNJX0NNIGlz IG5vdCBzZXQKIyBDT05GSUdfRElTUExBWV9QQU5FTF9TT05ZX0FDWDU2NUFLTSBpcyBub3Qg c2V0CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfTEdQSElMSVBTX0xCMDM1UTAyIGlzIG5vdCBz ZXQKIyBDT05GSUdfRElTUExBWV9QQU5FTF9TSEFSUF9MUzAzN1Y3RFcwMSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RJU1BMQVlfUEFORUxfVFBPX1REMDI4VFRFQzEgaXMgbm90IHNldAojIENP TkZJR19ESVNQTEFZX1BBTkVMX1RQT19URDA0M01URUExIGlzIG5vdCBzZXQKIyBDT05GSUdf RElTUExBWV9QQU5FTF9ORUNfTkw4MDQ4SEwxMSBpcyBub3Qgc2V0CkNPTkZJR19ESVNQTEFZ X1BBTkVMX1RMQzU5MTA4PXkKIyBDT05GSUdfRVhZTk9TX1ZJREVPIGlzIG5vdCBzZXQKIyBD T05GSUdfRkJfU1NEMTMwNyBpcyBub3Qgc2V0CkNPTkZJR19CQUNLTElHSFRfTENEX1NVUFBP UlQ9eQpDT05GSUdfTENEX0NMQVNTX0RFVklDRT15CiMgQ09ORklHX0xDRF9MNEYwMDI0MlQw MyBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9MTVMyODNHRjA1IGlzIG5vdCBzZXQKIyBDT05G SUdfTENEX0xUVjM1MFFWIGlzIG5vdCBzZXQKIyBDT05GSUdfTENEX0lMSTkyMlggaXMgbm90 IHNldAojIENPTkZJR19MQ0RfSUxJOTMyMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9URE8y NE0gaXMgbm90IHNldAojIENPTkZJR19MQ0RfVkdHMjQzMkE0IGlzIG5vdCBzZXQKQ09ORklH X0xDRF9QTEFURk9STT15CiMgQ09ORklHX0xDRF9TNkU2M00wIGlzIG5vdCBzZXQKIyBDT05G SUdfTENEX0xEOTA0MCBpcyBub3Qgc2V0CiMgQ09ORklHX0xDRF9BTVMzNjlGRzA2IGlzIG5v dCBzZXQKIyBDT05GSUdfTENEX0xNUzUwMUtGMDMgaXMgbm90IHNldAojIENPTkZJR19MQ0Rf SFg4MzU3IGlzIG5vdCBzZXQKQ09ORklHX0JBQ0tMSUdIVF9DTEFTU19ERVZJQ0U9eQpDT05G SUdfQkFDS0xJR0hUX0dFTkVSSUM9eQpDT05GSUdfQkFDS0xJR0hUX1BXTT15CiMgQ09ORklH X0JBQ0tMSUdIVF9BRFA4ODYwIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0FEUDg4 NzAgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRfTE0zNjMwQSBpcyBub3Qgc2V0CiMg Q09ORklHX0JBQ0tMSUdIVF9MTTM2MzkgaXMgbm90IHNldAojIENPTkZJR19CQUNLTElHSFRf TFA4NTVYIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX1RQUzY1MjE3IGlzIG5vdCBz ZXQKQ09ORklHX0JBQ0tMSUdIVF9HUElPPXkKIyBDT05GSUdfQkFDS0xJR0hUX0xWNTIwN0xQ IGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS0xJR0hUX0JENjEwNyBpcyBub3Qgc2V0CiMgQ09O RklHX1ZHQVNUQVRFIGlzIG5vdCBzZXQKIyBDT05GSUdfVklERU9fT1VUUFVUX0NPTlRST0wg aXMgbm90IHNldApDT05GSUdfVklERU9NT0RFX0hFTFBFUlM9eQpDT05GSUdfSERNST15Cgoj CiMgQ29uc29sZSBkaXNwbGF5IGRyaXZlciBzdXBwb3J0CiMKQ09ORklHX0RVTU1ZX0NPTlNP TEU9eQpDT05GSUdfRlJBTUVCVUZGRVJfQ09OU09MRT15CkNPTkZJR19GUkFNRUJVRkZFUl9D T05TT0xFX0RFVEVDVF9QUklNQVJZPXkKQ09ORklHX0ZSQU1FQlVGRkVSX0NPTlNPTEVfUk9U QVRJT049eQpDT05GSUdfTE9HTz15CkNPTkZJR19MT0dPX0xJTlVYX01PTk89eQpDT05GSUdf TE9HT19MSU5VWF9WR0ExNj15CkNPTkZJR19MT0dPX0xJTlVYX0NMVVQyMjQ9eQpDT05GSUdf U09VTkQ9eQpDT05GSUdfU09VTkRfT1NTX0NPUkU9eQpDT05GSUdfU09VTkRfT1NTX0NPUkVf UFJFQ0xBSU09eQpDT05GSUdfU05EPXkKQ09ORklHX1NORF9USU1FUj15CkNPTkZJR19TTkRf UENNPXkKQ09ORklHX1NORF9ETUFFTkdJTkVfUENNPXkKQ09ORklHX1NORF9IV0RFUD1tCkNP TkZJR19TTkRfUkFXTUlEST1tCkNPTkZJR19TTkRfQ09NUFJFU1NfT0ZGTE9BRD15CkNPTkZJ R19TTkRfSkFDSz15CiMgQ09ORklHX1NORF9TRVFVRU5DRVIgaXMgbm90IHNldApDT05GSUdf U05EX09TU0VNVUw9eQpDT05GSUdfU05EX01JWEVSX09TUz1tCkNPTkZJR19TTkRfUENNX09T Uz1tCkNPTkZJR19TTkRfUENNX09TU19QTFVHSU5TPXkKIyBDT05GSUdfU05EX0hSVElNRVIg aXMgbm90IHNldAojIENPTkZJR19TTkRfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldApDT05G SUdfU05EX1NVUFBPUlRfT0xEX0FQST15CkNPTkZJR19TTkRfVkVSQk9TRV9QUk9DRlM9eQpD T05GSUdfU05EX1ZFUkJPU0VfUFJJTlRLPXkKQ09ORklHX1NORF9ERUJVRz15CiMgQ09ORklH X1NORF9ERUJVR19WRVJCT1NFIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1BDTV9YUlVOX0RF QlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JBV01JRElfU0VRIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX09QTDNfTElCX1NFUSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9PUEw0X0xJ Ql9TRVEgaXMgbm90IHNldAojIENPTkZJR19TTkRfU0JBV0VfU0VRIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0VNVTEwSzFfU0VRIGlzIG5vdCBzZXQKQ09ORklHX1NORF9EUklWRVJTPXkK IyBDT05GSUdfU05EX0RVTU1ZIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FMT09QIGlzIG5v dCBzZXQKIyBDT05GSUdfU05EX01UUEFWIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NFUklB TF9VMTY1NTAgaXMgbm90IHNldAojIENPTkZJR19TTkRfTVBVNDAxIGlzIG5vdCBzZXQKQ09O RklHX1NORF9QQ0k9eQojIENPTkZJR19TTkRfQUQxODg5IGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX0FMUzMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BTEk1NDUxIGlzIG5vdCBzZXQK IyBDT05GSUdfU05EX0FUSUlYUCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVElJWFBfTU9E RU0gaXMgbm90IHNldAojIENPTkZJR19TTkRfQVU4ODEwIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX0FVODgyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9BVTg4MzAgaXMgbm90IHNldAoj IENPTkZJR19TTkRfQVcyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0FaVDMzMjggaXMgbm90 IHNldAojIENPTkZJR19TTkRfQlQ4N1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfQ0EwMTA2 IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0NNSVBDSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9PWFlHRU4gaXMgbm90IHNldAojIENPTkZJR19TTkRfQ1M0MjgxIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0NTNDZYWCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9DUzU1MzVBVURJTyBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9DVFhGSSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9E QVJMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0dJTkEyMCBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9MQVlMQTIwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0RBUkxBMjQgaXMgbm90 IHNldAojIENPTkZJR19TTkRfR0lOQTI0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xBWUxB MjQgaXMgbm90IHNldAojIENPTkZJR19TTkRfTU9OQSBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9NSUEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRUNITzNHIGlzIG5vdCBzZXQKIyBDT05G SUdfU05EX0lORElHTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJR09JTyBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9JTkRJR09ESiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JTkRJ R09JT1ggaXMgbm90IHNldAojIENPTkZJR19TTkRfSU5ESUdPREpYIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0VNVTEwSzEgaXMgbm90IHNldAojIENPTkZJR19TTkRfRU1VMTBLMVggaXMg bm90IHNldAojIENPTkZJR19TTkRfRU5TMTM3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9F TlMxMzcxIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0VTMTkzOCBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9FUzE5NjggaXMgbm90IHNldAojIENPTkZJR19TTkRfRk04MDEgaXMgbm90IHNl dAojIENPTkZJR19TTkRfSERBX0lOVEVMIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0hEU1Ag aXMgbm90IHNldAojIENPTkZJR19TTkRfSERTUE0gaXMgbm90IHNldAojIENPTkZJR19TTkRf SUNFMTcxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9JQ0UxNzI0IGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX0lOVEVMOFgwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0lOVEVMOFgwTSBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9LT1JHMTIxMiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9MT0xBIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX0xYNjQ2NEVTIGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX01BRVNUUk8zIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX01JWEFSVCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9OTTI1NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9QQ1hI UiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9SSVBUSURFIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX1JNRTMyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1JNRTk2IGlzIG5vdCBzZXQKIyBD T05GSUdfU05EX1JNRTk2NTIgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09OSUNWSUJFUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NORF9UUklERU5UIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1ZJQTgyWFggaXMgbm90IHNldAojIENPTkZJR19TTkRfVklBODJYWF9NT0RFTSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9WSVJUVU9TTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9WWDIy MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9ZTUZQQ0kgaXMgbm90IHNldApDT05GSUdfU05E X0FSTT15CkNPTkZJR19TTkRfU1BJPXkKQ09ORklHX1NORF9VU0I9eQpDT05GSUdfU05EX1VT Ql9BVURJTz1tCiMgQ09ORklHX1NORF9VU0JfVUExMDEgaXMgbm90IHNldAojIENPTkZJR19T TkRfVVNCX0NBSUFRIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1VTQl82RklSRSBpcyBub3Qg c2V0CiMgQ09ORklHX1NORF9VU0JfSElGQUNFIGlzIG5vdCBzZXQKQ09ORklHX1NORF9TT0M9 eQojIENPTkZJR19TTkRfQVRNRUxfU09DIGlzIG5vdCBzZXQKQ09ORklHX1NORF9EQVZJTkNJ X1NPQ19NQ0FTUD15CkNPTkZJR19TTkRfREFWSU5DSV9TT0NfR0VORVJJQ19FVk09eQojIENP TkZJR19TTkRfREVTSUdOV0FSRV9JMlMgaXMgbm90IHNldApDT05GSUdfU05EX09NQVBfU09D PXkKQ09ORklHX1NORF9PTUFQX1NPQ19IRE1JX0FVRElPPXkKQ09ORklHX1NORF9PTUFQX1NP Q19EUkE3RVZNPXkKQ09ORklHX1NORF9TT0NfSTJDX0FORF9TUEk9eQoKIwojIENPREVDIGRy aXZlcnMKIwojIENPTkZJR19TTkRfU09DX0FEQVUxNzAxIGlzIG5vdCBzZXQKIyBDT05GSUdf U05EX1NPQ19BSzQxMDQgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0FLNDU1NCBpcyBu b3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQUs0NjQyIGlzIG5vdCBzZXQKIyBDT05GSUdfU05E X1NPQ19BSzUzODYgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNTIgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX0NTNDJMNzMgaXMgbm90IHNldAojIENPTkZJR19TTkRf U09DX0NTNDI3MCBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfQ1M0MjcxIGlzIG5vdCBz ZXQKQ09ORklHX1NORF9TT0NfSERNSV9DT0RFQz15CiMgQ09ORklHX1NORF9TT0NfUENNMTY4 MSBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfUENNMTc5MkEgaXMgbm90IHNldAojIENP TkZJR19TTkRfU09DX1NHVEw1MDAwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19TUERJ RiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9TT0NfVEFTNTA4NiBpcyBub3Qgc2V0CkNPTkZJ R19TTkRfU09DX1RMVjMyMEFJQzMxWFg9eQpDT05GSUdfU05EX1NPQ19UTFYzMjBBSUMzWD15 CiMgQ09ORklHX1NORF9TT0NfV004NTEwIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19X TTg1MjMgaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODU4MCBpcyBub3Qgc2V0CiMg Q09ORklHX1NORF9TT0NfV004NzExIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3 MjggaXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODczMSBpcyBub3Qgc2V0CiMgQ09O RklHX1NORF9TT0NfV004NzM3IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NDEg aXMgbm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODc1MCBpcyBub3Qgc2V0CiMgQ09ORklH X1NORF9TT0NfV004NzUzIGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg3NzAgaXMg bm90IHNldAojIENPTkZJR19TTkRfU09DX1dNODc3NiBpcyBub3Qgc2V0CiMgQ09ORklHX1NO RF9TT0NfV004ODA0IGlzIG5vdCBzZXQKIyBDT05GSUdfU05EX1NPQ19XTTg5MDMgaXMgbm90 IHNldAojIENPTkZJR19TTkRfU09DX1dNODk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1NORF9T T0NfVFBBNjEzMEEyIGlzIG5vdCBzZXQKQ09ORklHX1NORF9TSU1QTEVfQ0FSRD15CiMgQ09O RklHX1NPVU5EX1BSSU1FIGlzIG5vdCBzZXQKCiMKIyBISUQgc3VwcG9ydAojCkNPTkZJR19I SUQ9eQojIENPTkZJR19ISURfQkFUVEVSWV9TVFJFTkdUSCBpcyBub3Qgc2V0CiMgQ09ORklH X0hJRFJBVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VISUQgaXMgbm90IHNldApDT05GSUdfSElE X0dFTkVSSUM9eQoKIwojIFNwZWNpYWwgSElEIGRyaXZlcnMKIwojIENPTkZJR19ISURfQTRU RUNIIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0FDUlVYIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX0FQUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0FQUExFSVIgaXMgbm90IHNldAoj IENPTkZJR19ISURfQVVSRUFMIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0JFTEtJTiBpcyBu b3Qgc2V0CiMgQ09ORklHX0hJRF9DSEVSUlkgaXMgbm90IHNldAojIENPTkZJR19ISURfQ0hJ Q09OWSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUk9ESUtFWVMgaXMgbm90IHNldAojIENP TkZJR19ISURfQ1lQUkVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9EUkFHT05SSVNFIGlz IG5vdCBzZXQKIyBDT05GSUdfSElEX0VNU19GRiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9F TEVDT00gaXMgbm90IHNldAojIENPTkZJR19ISURfRUxPIGlzIG5vdCBzZXQKIyBDT05GSUdf SElEX0VaS0VZIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0hPTFRFSyBpcyBub3Qgc2V0CiMg Q09ORklHX0hJRF9IVUlPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LRVlUT1VDSCBpcyBu b3Qgc2V0CiMgQ09ORklHX0hJRF9LWUUgaXMgbm90IHNldAojIENPTkZJR19ISURfVUNMT0dJ QyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XQUxUT1AgaXMgbm90IHNldAojIENPTkZJR19I SURfR1lSQVRJT04gaXMgbm90IHNldAojIENPTkZJR19ISURfSUNBREUgaXMgbm90IHNldAoj IENPTkZJR19ISURfVFdJTkhBTiBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9LRU5TSU5HVE9O IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0xDUE9XRVIgaXMgbm90IHNldAojIENPTkZJR19I SURfTEVOT1ZPX1RQS0JEIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX0xPR0lURUNIIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX01BR0lDTU9VU0UgaXMgbm90IHNldAojIENPTkZJR19ISURf TUlDUk9TT0ZUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX01PTlRFUkVZIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX01VTFRJVE9VQ0ggaXMgbm90IHNldAojIENPTkZJR19ISURfTlRSSUcg aXMgbm90IHNldAojIENPTkZJR19ISURfT1JURUsgaXMgbm90IHNldAojIENPTkZJR19ISURf UEFOVEhFUkxPUkQgaXMgbm90IHNldAojIENPTkZJR19ISURfUEVUQUxZTlggaXMgbm90IHNl dAojIENPTkZJR19ISURfUElDT0xDRCBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9QUklNQVgg aXMgbm90IHNldAojIENPTkZJR19ISURfUk9DQ0FUIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1NBSVRFSyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9TQU1TVU5HIGlzIG5vdCBzZXQKIyBD T05GSUdfSElEX1NPTlkgaXMgbm90IHNldAojIENPTkZJR19ISURfU1BFRURMSU5LIGlzIG5v dCBzZXQKIyBDT05GSUdfSElEX1NURUVMU0VSSUVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1NVTlBMVVMgaXMgbm90IHNldAojIENPTkZJR19ISURfR1JFRU5BU0lBIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX1NNQVJUSk9ZUExVUyBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9USVZP IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RPUFNFRUQgaXMgbm90IHNldAojIENPTkZJR19I SURfVEhJTkdNIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1RIUlVTVE1BU1RFUiBpcyBub3Qg c2V0CiMgQ09ORklHX0hJRF9XQUNPTSBpcyBub3Qgc2V0CiMgQ09ORklHX0hJRF9XSUlNT1RF IGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1hJTk1PIGlzIG5vdCBzZXQKIyBDT05GSUdfSElE X1pFUk9QTFVTIGlzIG5vdCBzZXQKIyBDT05GSUdfSElEX1pZREFDUk9OIGlzIG5vdCBzZXQK IyBDT05GSUdfSElEX1NFTlNPUl9IVUIgaXMgbm90IHNldAoKIwojIFVTQiBISUQgc3VwcG9y dAojCkNPTkZJR19VU0JfSElEPXkKIyBDT05GSUdfSElEX1BJRCBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9ISURERVYgaXMgbm90IHNldAoKIwojIEkyQyBISUQgc3VwcG9ydAojCiMgQ09O RklHX0kyQ19ISUQgaXMgbm90IHNldApDT05GSUdfVVNCX09IQ0lfTElUVExFX0VORElBTj15 CkNPTkZJR19VU0JfU1VQUE9SVD15CkNPTkZJR19VU0JfQ09NTU9OPXkKQ09ORklHX0RSRF9M SUI9eQpDT05GSUdfVVNCX0FSQ0hfSEFTX0hDRD15CkNPTkZJR19VU0I9eQojIENPTkZJR19V U0JfREVCVUcgaXMgbm90IHNldApDT05GSUdfVVNCX0FOTk9VTkNFX05FV19ERVZJQ0VTPXkK CiMKIyBNaXNjZWxsYW5lb3VzIFVTQiBvcHRpb25zCiMKQ09ORklHX1VTQl9ERUZBVUxUX1BF UlNJU1Q9eQojIENPTkZJR19VU0JfRFlOQU1JQ19NSU5PUlMgaXMgbm90IHNldAojIENPTkZJ R19VU0JfT1RHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX09UR19XSElURUxJU1QgaXMgbm90 IHNldAojIENPTkZJR19VU0JfT1RHX0JMQUNLTElTVF9IVUIgaXMgbm90IHNldApDT05GSUdf VVNCX01PTj15CiMgQ09ORklHX1VTQl9XVVNCX0NCQUYgaXMgbm90IHNldAoKIwojIFVTQiBI b3N0IENvbnRyb2xsZXIgRHJpdmVycwojCiMgQ09ORklHX1VTQl9DNjdYMDBfSENEIGlzIG5v dCBzZXQKQ09ORklHX1VTQl9YSENJX0hDRD1tCkNPTkZJR19VU0JfWEhDSV9QTEFURk9STT1t CkNPTkZJR19VU0JfRUhDSV9IQ0Q9eQojIENPTkZJR19VU0JfRUhDSV9ST09UX0hVQl9UVCBp cyBub3Qgc2V0CkNPTkZJR19VU0JfRUhDSV9UVF9ORVdTQ0hFRD15CkNPTkZJR19VU0JfRUhD SV9QQ0k9eQpDT05GSUdfVVNCX0VIQ0lfSENEX09NQVA9eQojIENPTkZJR19VU0JfRUhDSV9I Q0RfUExBVEZPUk0gaXMgbm90IHNldAojIENPTkZJR19VU0JfT1hVMjEwSFBfSENEIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0lTUDExNlhfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X0lTUDE3NjBfSENEIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0lTUDEzNjJfSENEIGlzIG5v dCBzZXQKIyBDT05GSUdfVVNCX0ZVU0JIMjAwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9GT1RHMjEwX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9PSENJX0hDRCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9VSENJX0hDRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TTDgx MV9IQ0QgaXMgbm90IHNldAojIENPTkZJR19VU0JfUjhBNjY1OTdfSENEIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0hDRF9URVNUX01PREUgaXMgbm90IHNldAojIENPTkZJR19VU0JfUkVO RVNBU19VU0JIUyBpcyBub3Qgc2V0CgojCiMgVVNCIERldmljZSBDbGFzcyBkcml2ZXJzCiMK Q09ORklHX1VTQl9BQ009bQpDT05GSUdfVVNCX1BSSU5URVI9bQpDT05GSUdfVVNCX1dETT15 CiMgQ09ORklHX1VTQl9UTUMgaXMgbm90IHNldAoKIwojIE5PVEU6IFVTQl9TVE9SQUdFIGRl cGVuZHMgb24gU0NTSSBidXQgQkxLX0RFVl9TRCBtYXkKIwoKIwojIGFsc28gYmUgbmVlZGVk OyBzZWUgVVNCX1NUT1JBR0UgSGVscCBmb3IgbW9yZSBpbmZvCiMKQ09ORklHX1VTQl9TVE9S QUdFPXkKIyBDT05GSUdfVVNCX1NUT1JBR0VfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19V U0JfU1RPUkFHRV9SRUFMVEVLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfREFU QUZBQiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX0ZSRUVDT00gaXMgbm90IHNl dAojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90IHNldAojIENPTkZJR19VU0Jf U1RPUkFHRV9VU0JBVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFIwOSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TVE9SQUdFX1NERFI1NSBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9TVE9SQUdFX0pVTVBTSE9UIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JB R0VfQUxBVURBIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NUT1JBR0VfT05FVE9VQ0ggaXMg bm90IHNldAojIENPTkZJR19VU0JfU1RPUkFHRV9LQVJNQSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TVE9SQUdFX0NZUFJFU1NfQVRBQ0IgaXMgbm90IHNldAojIENPTkZJR19VU0JfU1RP UkFHRV9FTkVfVUI2MjUwIGlzIG5vdCBzZXQKCiMKIyBVU0IgSW1hZ2luZyBkZXZpY2VzCiMK IyBDT05GSUdfVVNCX01EQzgwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NSUNST1RFSyBp cyBub3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9IRFJDPW0KIyBDT05GSUdfVVNCX01VU0JfSE9T VCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NVVNCX0dBREdFVCBpcyBub3Qgc2V0CkNPTkZJ R19VU0JfTVVTQl9EVUFMX1JPTEU9eQojIENPTkZJR19VU0JfTVVTQl9UVVNCNjAxMCBpcyBu b3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9PTUFQMlBMVVM9bQojIENPTkZJR19VU0JfTVVTQl9B TTM1WCBpcyBub3Qgc2V0CkNPTkZJR19VU0JfTVVTQl9EU1BTPW0KIyBDT05GSUdfVVNCX01V U0JfVVg1MDAgaXMgbm90IHNldApDT05GSUdfVVNCX01VU0JfQU0zMzVYX0NISUxEPW0KIyBD T05GSUdfVVNCX0lOVkVOVFJBX0RNQSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfVElfQ1BQSTQx X0RNQT15CiMgQ09ORklHX01VU0JfUElPX09OTFkgaXMgbm90IHNldApDT05GSUdfVVNCX0RX QzM9bQojIENPTkZJR19VU0JfRFdDM19IT1NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RX QzNfR0FER0VUIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9EV0MzX0RVQUxfUk9MRT15CgojCiMg UGxhdGZvcm0gR2x1ZSBEcml2ZXIgU3VwcG9ydAojCkNPTkZJR19VU0JfRFdDM19PTUFQPW0K Q09ORklHX1VTQl9EV0MzX1BDST1tCgojCiMgRGVidWdnaW5nIGZlYXR1cmVzCiMKIyBDT05G SUdfVVNCX0RXQzNfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19EV0MzX0hPU1RfVVNCM19M UE1fRU5BQkxFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0RXQzIgaXMgbm90IHNldAojIENP TkZJR19VU0JfQ0hJUElERUEgaXMgbm90IHNldAoKIwojIFVTQiBwb3J0IGRyaXZlcnMKIwpD T05GSUdfVVNCX1NFUklBTD1tCiMgQ09ORklHX1VTQl9TRVJJQUxfR0VORVJJQyBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU0lNUExFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNC X1NFUklBTF9BSVJDQUJMRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfQVJLMzEx NiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfQkVMS0lOIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9DSDM0MSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxf V0hJVEVIRUFUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9ESUdJX0FDQ0VMRVBP UlQgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0NQMjEwWCBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TRVJJQUxfQ1lQUkVTU19NOCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfRU1QRUcgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0ZURElfU0lPIGlz IG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9WSVNPUiBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfSVBBUSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfSVIgaXMg bm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0VER0VQT1JUIGlzIG5vdCBzZXQKIyBDT05G SUdfVVNCX1NFUklBTF9FREdFUE9SVF9USSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJ QUxfRjgxMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9HQVJNSU4gaXMgbm90 IHNldAojIENPTkZJR19VU0JfU0VSSUFMX0lQVyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfSVVVIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFOX1BEQSBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZU1BBTiBpcyBub3Qgc2V0CiMgQ09O RklHX1VTQl9TRVJJQUxfS0xTSSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfS09C SUxfU0NUIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9NQ1RfVTIzMiBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfTUVUUk8gaXMgbm90IHNldAojIENPTkZJR19VU0Jf U0VSSUFMX01PUzc3MjAgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01PUzc4NDAg aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX01YVVBPUlQgaXMgbm90IHNldAojIENP TkZJR19VU0JfU0VSSUFMX05BVk1BTiBpcyBub3Qgc2V0CkNPTkZJR19VU0JfU0VSSUFMX1BM MjMwMz1tCiMgQ09ORklHX1VTQl9TRVJJQUxfT1RJNjg1OCBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfUUNBVVggaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1FVQUxD T01NIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9TUENQOFg1IGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX1NFUklBTF9TQUZFIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklB TF9TSUVSUkFXSVJFTEVTUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfU1lNQk9M IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9USSBpcyBub3Qgc2V0CiMgQ09ORklH X1VTQl9TRVJJQUxfQ1lCRVJKQUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1NFUklBTF9Y SVJDT00gaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX09QVElPTiBpcyBub3Qgc2V0 CiMgQ09ORklHX1VTQl9TRVJJQUxfT01OSU5FVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9T RVJJQUxfT1BUSUNPTiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfWFNFTlNfTVQg aXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1dJU0hCT05FIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9aVEUgaXMgbm90IHNldAojIENPTkZJR19VU0JfU0VSSUFMX1NT VTEwMCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TRVJJQUxfUVQyIGlzIG5vdCBzZXQKIyBD T05GSUdfVVNCX1NFUklBTF9ERUJVRyBpcyBub3Qgc2V0CgojCiMgVVNCIE1pc2NlbGxhbmVv dXMgZHJpdmVycwojCiMgQ09ORklHX1VTQl9FTUk2MiBpcyBub3Qgc2V0CiMgQ09ORklHX1VT Ql9FTUkyNiBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9BRFVUVVggaXMgbm90IHNldAojIENP TkZJR19VU0JfU0VWU0VHIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JJTzUwMCBpcyBub3Qg c2V0CiMgQ09ORklHX1VTQl9MRUdPVE9XRVIgaXMgbm90IHNldAojIENPTkZJR19VU0JfTENE IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0xFRCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9D WVBSRVNTX0NZN0M2MyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9DWVRIRVJNIGlzIG5vdCBz ZXQKIyBDT05GSUdfVVNCX0lETU9VU0UgaXMgbm90IHNldAojIENPTkZJR19VU0JfRlRESV9F TEFOIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX0FQUExFRElTUExBWSBpcyBub3Qgc2V0CiMg Q09ORklHX1VTQl9TSVNVU0JWR0EgaXMgbm90IHNldAojIENPTkZJR19VU0JfTEQgaXMgbm90 IHNldAojIENPTkZJR19VU0JfVFJBTkNFVklCUkFUT1IgaXMgbm90IHNldAojIENPTkZJR19V U0JfSU9XQVJSSU9SIGlzIG5vdCBzZXQKQ09ORklHX1VTQl9URVNUPW0KIyBDT05GSUdfVVNC X0VIU0VUX1RFU1RfRklYVFVSRSBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU0lHSFRGVyBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ZVVJFWCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9F WlVTQl9GWDIgaXMgbm90IHNldAojIENPTkZJR19VU0JfSFNJQ19VU0IzNTAzIGlzIG5vdCBz ZXQKCiMKIyBVU0IgUGh5c2ljYWwgTGF5ZXIgZHJpdmVycwojCkNPTkZJR19VU0JfUEhZPXkK IyBDT05GSUdfVVNCX09UR19GU00gaXMgbm90IHNldAojIENPTkZJR19VU0JfT1RHX1dBS0VM T0NLIGlzIG5vdCBzZXQKQ09ORklHX05PUF9VU0JfWENFSVY9eQpDT05GSUdfQU0zMzVYX0NP TlRST0xfVVNCPXkKQ09ORklHX0FNMzM1WF9QSFlfVVNCPXkKIyBDT05GSUdfU0FNU1VOR19V U0IyUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdfU0FNU1VOR19VU0IzUEhZIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX0dQSU9fVkJVUyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9JU1AxMzAx IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1JDQVJfUEhZIGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1VMUEkgaXMgbm90IHNldApDT05GSUdfVVNCX0dBREdFVD15CkNPTkZJR19VU0JfR0FE R0VUX0RFQlVHPXkKIyBDT05GSUdfVVNCX0dBREdFVF9WRVJCT1NFIGlzIG5vdCBzZXQKQ09O RklHX1VTQl9HQURHRVRfREVCVUdfRklMRVM9eQpDT05GSUdfVVNCX0dBREdFVF9ERUJVR19G Uz15CkNPTkZJR19VU0JfR0FER0VUX1ZCVVNfRFJBVz0yCkNPTkZJR19VU0JfR0FER0VUX1NU T1JBR0VfTlVNX0JVRkZFUlM9MgoKIwojIFVTQiBQZXJpcGhlcmFsIENvbnRyb2xsZXIKIwoj IENPTkZJR19VU0JfRk9URzIxMF9VREMgaXMgbm90IHNldAojIENPTkZJR19VU0JfR1JfVURD IGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX1I4QTY2NTk3IGlzIG5vdCBzZXQKIyBDT05GSUdf VVNCX1BYQTI3WCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9TM0NfSFNPVEcgaXMgbm90IHNl dAojIENPTkZJR19VU0JfTVZfVURDIGlzIG5vdCBzZXQKIyBDT05GSUdfVVNCX01WX1UzRCBp cyBub3Qgc2V0CiMgQ09ORklHX1VTQl9NNjY1OTIgaXMgbm90IHNldAojIENPTkZJR19VU0Jf QU1ENTUzNlVEQyBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9ORVQyMjcyIGlzIG5vdCBzZXQK IyBDT05GSUdfVVNCX05FVDIyODAgaXMgbm90IHNldAojIENPTkZJR19VU0JfR09LVSBpcyBu b3Qgc2V0CiMgQ09ORklHX1VTQl9FRzIwVCBpcyBub3Qgc2V0CiMgQ09ORklHX1VTQl9EVU1N WV9IQ0QgaXMgbm90IHNldApDT05GSUdfVVNCX0xJQkNPTVBPU0lURT1tCkNPTkZJR19VU0Jf Rl9BQ009bQpDT05GSUdfVVNCX0ZfU1NfTEI9bQpDT05GSUdfVVNCX1VfU0VSSUFMPW0KQ09O RklHX1VTQl9VX0VUSEVSPW0KQ09ORklHX1VTQl9GX1NFUklBTD1tCkNPTkZJR19VU0JfRl9P QkVYPW0KQ09ORklHX1VTQl9GX05DTT1tCkNPTkZJR19VU0JfRl9FQ009bQpDT05GSUdfVVNC X0ZfU1VCU0VUPW0KQ09ORklHX1VTQl9GX1JORElTPW0KQ09ORklHX1VTQl9GX01BU1NfU1RP UkFHRT1tCkNPTkZJR19VU0JfRl9GUz1tCiMgQ09ORklHX1VTQl9DT05GSUdGUyBpcyBub3Qg c2V0CkNPTkZJR19VU0JfWkVSTz1tCkNPTkZJR19VU0JfQVVESU89bQojIENPTkZJR19HQURH RVRfVUFDMSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfRVRIPW0KQ09ORklHX1VTQl9FVEhfUk5E SVM9eQojIENPTkZJR19VU0JfRVRIX0VFTSBpcyBub3Qgc2V0CkNPTkZJR19VU0JfR19OQ009 bQpDT05GSUdfVVNCX0dBREdFVEZTPW0KQ09ORklHX1VTQl9GVU5DVElPTkZTPW0KQ09ORklH X1VTQl9GVU5DVElPTkZTX0VUSD15CkNPTkZJR19VU0JfRlVOQ1RJT05GU19STkRJUz15CkNP TkZJR19VU0JfRlVOQ1RJT05GU19HRU5FUklDPXkKQ09ORklHX1VTQl9NQVNTX1NUT1JBR0U9 bQpDT05GSUdfVVNCX0dfU0VSSUFMPW0KQ09ORklHX1VTQl9NSURJX0dBREdFVD1tCkNPTkZJ R19VU0JfR19QUklOVEVSPW0KQ09ORklHX1VTQl9DRENfQ09NUE9TSVRFPW0KQ09ORklHX1VT Ql9HX0FDTV9NUz1tCkNPTkZJR19VU0JfR19NVUxUST1tCkNPTkZJR19VU0JfR19NVUxUSV9S TkRJUz15CkNPTkZJR19VU0JfR19NVUxUSV9DREM9eQpDT05GSUdfVVNCX0dfSElEPW0KQ09O RklHX1VTQl9HX0RCR1A9bQojIENPTkZJR19VU0JfR19EQkdQX1BSSU5USyBpcyBub3Qgc2V0 CkNPTkZJR19VU0JfR19EQkdQX1NFUklBTD15CkNPTkZJR19VU0JfR19XRUJDQU09bQojIENP TkZJR19VV0IgaXMgbm90IHNldApDT05GSUdfTU1DPXkKIyBDT05GSUdfTU1DX0RFQlVHIGlz IG5vdCBzZXQKQ09ORklHX01NQ19VTlNBRkVfUkVTVU1FPXkKIyBDT05GSUdfTU1DX0NMS0dB VEUgaXMgbm90IHNldAojIENPTkZJR19NTUNfRU1CRURERURfU0RJTyBpcyBub3Qgc2V0CiMg Q09ORklHX01NQ19QQVJBTk9JRF9TRF9JTklUIGlzIG5vdCBzZXQKCiMKIyBNTUMvU0QvU0RJ TyBDYXJkIERyaXZlcnMKIwpDT05GSUdfTU1DX0JMT0NLPXkKQ09ORklHX01NQ19CTE9DS19N SU5PUlM9OApDT05GSUdfTU1DX0JMT0NLX0JPVU5DRT15CiMgQ09ORklHX01NQ19CTE9DS19E RUZFUlJFRF9SRVNVTUUgaXMgbm90IHNldApDT05GSUdfU0RJT19VQVJUPXkKIyBDT05GSUdf TU1DX1RFU1QgaXMgbm90IHNldAoKIwojIE1NQy9TRC9TRElPIEhvc3QgQ29udHJvbGxlciBE cml2ZXJzCiMKIyBDT05GSUdfTU1DX1NESENJIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1NE SENJX1BYQVYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX1NESENJX1BYQVYyIGlzIG5vdCBz ZXQKQ09ORklHX01NQ19PTUFQPXkKQ09ORklHX01NQ19PTUFQX0hTPXkKIyBDT05GSUdfTU1D X1RJRk1fU0QgaXMgbm90IHNldAojIENPTkZJR19NTUNfQ0I3MTAgaXMgbm90IHNldAojIENP TkZJR19NTUNfVklBX1NETU1DIGlzIG5vdCBzZXQKIyBDT05GSUdfTU1DX0RXIGlzIG5vdCBz ZXQKIyBDT05GSUdfTU1DX1ZVQjMwMCBpcyBub3Qgc2V0CiMgQ09ORklHX01NQ19VU0hDIGlz IG5vdCBzZXQKIyBDT05GSUdfTUVNU1RJQ0sgaXMgbm90IHNldApDT05GSUdfTkVXX0xFRFM9 eQpDT05GSUdfTEVEU19DTEFTUz15CgojCiMgTEVEIGRyaXZlcnMKIwojIENPTkZJR19MRURT X0xNMzUzMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNjQyIGlzIG5vdCBzZXQKIyBD T05GSUdfTEVEU19QQ0E5NTMyIGlzIG5vdCBzZXQKQ09ORklHX0xFRFNfR1BJTz15CiMgQ09O RklHX0xFRFNfTFAzOTQ0IGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDU1MjEgaXMgbm90 IHNldAojIENPTkZJR19MRURTX0xQNTUyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTFA1 NTYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19MUDg1MDEgaXMgbm90IHNldAojIENPTkZJ R19MRURTX1BDQTk1NVggaXMgbm90IHNldAojIENPTkZJR19MRURTX1BDQTk2M1ggaXMgbm90 IHNldAojIENPTkZJR19MRURTX1BDQTk2ODUgaXMgbm90IHNldAojIENPTkZJR19MRURTX0RB QzEyNFMwODUgaXMgbm90IHNldAojIENPTkZJR19MRURTX1BXTSBpcyBub3Qgc2V0CiMgQ09O RklHX0xFRFNfUkVHVUxBVE9SIGlzIG5vdCBzZXQKIyBDT05GSUdfTEVEU19CRDI4MDIgaXMg bm90IHNldAojIENPTkZJR19MRURTX0xUMzU5MyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNf VENBNjUwNyBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfTE0zNTV4IGlzIG5vdCBzZXQKIyBD T05GSUdfTEVEU19PVDIwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0xFRFNfQkxJTktNIGlzIG5v dCBzZXQKCiMKIyBMRUQgVHJpZ2dlcnMKIwpDT05GSUdfTEVEU19UUklHR0VSUz15CkNPTkZJ R19MRURTX1RSSUdHRVJfVElNRVI9eQpDT05GSUdfTEVEU19UUklHR0VSX09ORVNIT1Q9eQpD T05GSUdfTEVEU19UUklHR0VSX0hFQVJUQkVBVD15CkNPTkZJR19MRURTX1RSSUdHRVJfQkFD S0xJR0hUPXkKQ09ORklHX0xFRFNfVFJJR0dFUl9DUFU9eQpDT05GSUdfTEVEU19UUklHR0VS X0dQSU89eQpDT05GSUdfTEVEU19UUklHR0VSX0RFRkFVTFRfT049eQoKIwojIGlwdGFibGVz IHRyaWdnZXIgaXMgdW5kZXIgTmV0ZmlsdGVyIGNvbmZpZyAoTEVEIHRhcmdldCkKIwpDT05G SUdfTEVEU19UUklHR0VSX1RSQU5TSUVOVD15CkNPTkZJR19MRURTX1RSSUdHRVJfQ0FNRVJB PXkKIyBDT05GSUdfU1dJVENIIGlzIG5vdCBzZXQKIyBDT05GSUdfQUNDRVNTSUJJTElUWSBp cyBub3Qgc2V0CiMgQ09ORklHX0lORklOSUJBTkQgaXMgbm90IHNldAojIENPTkZJR19FREFD IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19MSUI9eQpDT05GSUdfUlRDX0NMQVNTPXkKQ09ORklH X1JUQ19IQ1RPU1lTPXkKQ09ORklHX1JUQ19TWVNUT0hDPXkKQ09ORklHX1JUQ19IQ1RPU1lT X0RFVklDRT0icnRjMCIKIyBDT05GSUdfUlRDX0RFQlVHIGlzIG5vdCBzZXQKCiMKIyBSVEMg aW50ZXJmYWNlcwojCkNPTkZJR19SVENfSU5URl9TWVNGUz15CkNPTkZJR19SVENfSU5URl9Q Uk9DPXkKQ09ORklHX1JUQ19JTlRGX0RFVj15CiMgQ09ORklHX1JUQ19JTlRGX0RFVl9VSUVf RU1VTCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfVEVTVCBpcyBub3Qgc2V0CgojCiMg STJDIFJUQyBkcml2ZXJzCiMKQ09ORklHX1JUQ19EUlZfRFMxMzA3PXkKIyBDT05GSUdfUlRD X0RSVl9EUzEzNzQgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTY3MiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfRFMzMjMyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9IWU04NTYzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NQVg2OTAwIGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9SUzVDMzcyIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9JU0wxMjA4IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9JU0wxMjAyMiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfSVNMMTIwNTcgaXMgbm90IHNldAojIENPTkZJR19SVENf RFJWX1gxMjA1IGlzIG5vdCBzZXQKQ09ORklHX1JUQ19EUlZfUEFMTUFTPXkKIyBDT05GSUdf UlRDX0RSVl9QQ0YyMTI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTIzIGlz IG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9QQ0Y4NTYzIGlzIG5vdCBzZXQKIyBDT05GSUdf UlRDX0RSVl9QQ0Y4NTgzIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NNDFUODAgaXMg bm90IHNldAojIENPTkZJR19SVENfRFJWX0JRMzJLIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9UUFM2NTkxMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfUzM1MzkwQSBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRk0zMTMwIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9SWDg1ODEgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX1JYODAyNSBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfRU0zMDI3IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9SVjMwMjlDMiBpcyBub3Qgc2V0CgojCiMgU1BJIFJUQyBkcml2ZXJzCiMKIyBDT05GSUdf UlRDX0RSVl9NNDFUOTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX000MVQ5NCBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxMzA1IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9EUzEzOTAgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX01BWDY5MDIgaXMgbm90 IHNldAojIENPTkZJR19SVENfRFJWX1I5NzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RS Vl9SUzVDMzQ4IGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9EUzMyMzQgaXMgbm90IHNl dAojIENPTkZJR19SVENfRFJWX1BDRjIxMjMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW X1JYNDU4MSBpcyBub3Qgc2V0CgojCiMgUGxhdGZvcm0gUlRDIGRyaXZlcnMKIwojIENPTkZJ R19SVENfRFJWX0NNT1MgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTI4NiBpcyBu b3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMxNTExIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRD X0RSVl9EUzE1NTMgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0RTMTc0MiBpcyBub3Qg c2V0CiMgQ09ORklHX1JUQ19EUlZfU1RLMTdUQTggaXMgbm90IHNldAojIENPTkZJR19SVENf RFJWX000OFQ4NiBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfTTQ4VDM1IGlzIG5vdCBz ZXQKIyBDT05GSUdfUlRDX0RSVl9NNDhUNTkgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJW X01TTTYyNDIgaXMgbm90IHNldAojIENPTkZJR19SVENfRFJWX0JRNDgwMiBpcyBub3Qgc2V0 CiMgQ09ORklHX1JUQ19EUlZfUlA1QzAxIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9W MzAyMCBpcyBub3Qgc2V0CiMgQ09ORklHX1JUQ19EUlZfRFMyNDA0IGlzIG5vdCBzZXQKCiMK IyBvbi1DUFUgUlRDIGRyaXZlcnMKIwpDT05GSUdfUlRDX0RSVl9PTUFQPXkKIyBDT05GSUdf UlRDX0RSVl9TTlZTIGlzIG5vdCBzZXQKIyBDT05GSUdfUlRDX0RSVl9NT1hBUlQgaXMgbm90 IHNldAoKIwojIEhJRCBTZW5zb3IgUlRDIGRyaXZlcnMKIwojIENPTkZJR19SVENfRFJWX0hJ RF9TRU5TT1JfVElNRSBpcyBub3Qgc2V0CkNPTkZJR19ETUFERVZJQ0VTPXkKIyBDT05GSUdf RE1BREVWSUNFU19ERUJVRyBpcyBub3Qgc2V0CgojCiMgRE1BIERldmljZXMKIwojIENPTkZJ R19EV19ETUFDX0NPUkUgaXMgbm90IHNldAojIENPTkZJR19EV19ETUFDIGlzIG5vdCBzZXQK IyBDT05GSUdfRFdfRE1BQ19QQ0kgaXMgbm90IHNldAojIENPTkZJR19USU1CX0RNQSBpcyBu b3Qgc2V0CkNPTkZJR19USV9FRE1BPXkKQ09ORklHX0RNQV9PTUFQPXkKQ09ORklHX1RJX0NQ UEk0MT15CkNPTkZJR19ETUFfRU5HSU5FPXkKQ09ORklHX0RNQV9WSVJUVUFMX0NIQU5ORUxT PXkKQ09ORklHX0RNQV9PRj15CgojCiMgRE1BIENsaWVudHMKIwojIENPTkZJR19BU1lOQ19U WF9ETUEgaXMgbm90IHNldAojIENPTkZJR19ETUFURVNUIGlzIG5vdCBzZXQKQ09ORklHX09N QVBfRE1BX0NST1NTQkFSPXkKIyBDT05GSUdfQVVYRElTUExBWSBpcyBub3Qgc2V0CiMgQ09O RklHX1VJTyBpcyBub3Qgc2V0CiMgQ09ORklHX1ZGSU8gaXMgbm90IHNldAojIENPTkZJR19W SVJUX0RSSVZFUlMgaXMgbm90IHNldApDT05GSUdfVklSVElPPW0KCiMKIyBWaXJ0aW8gZHJp dmVycwojCiMgQ09ORklHX1ZJUlRJT19QQ0kgaXMgbm90IHNldAojIENPTkZJR19WSVJUSU9f QkFMTE9PTiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZJUlRJT19NTUlPIGlzIG5vdCBzZXQKCiMK IyBNaWNyb3NvZnQgSHlwZXItViBndWVzdCBzdXBwb3J0CiMKCiMKIyBYZW4gZHJpdmVyIHN1 cHBvcnQKIwpDT05GSUdfWEVOX0JBTExPT049eQpDT05GSUdfWEVOX1NDUlVCX1BBR0VTPXkK Q09ORklHX1hFTl9ERVZfRVZUQ0hOPXkKQ09ORklHX1hFTl9CQUNLRU5EPXkKQ09ORklHX1hF TkZTPXkKQ09ORklHX1hFTl9DT01QQVRfWEVORlM9eQpDT05GSUdfWEVOX1NZU19IWVBFUlZJ U09SPXkKQ09ORklHX1hFTl9YRU5CVVNfRlJPTlRFTkQ9eQpDT05GSUdfWEVOX0dOVERFVj15 CkNPTkZJR19YRU5fR1JBTlRfREVWX0FMTE9DPXkKQ09ORklHX1NXSU9UTEJfWEVOPXkKQ09O RklHX1hFTl9QUklWQ01EPXkKIyBDT05GSUdfU1RBR0lORyBpcyBub3Qgc2V0CkNPTkZJR19D TEtERVZfTE9PS1VQPXkKQ09ORklHX0hBVkVfQ0xLX1BSRVBBUkU9eQpDT05GSUdfQ09NTU9O X0NMSz15CgojCiMgQ29tbW9uIENsb2NrIEZyYW1ld29yawojCiMgQ09ORklHX0NPTU1PTl9D TEtfU0k1MzUxIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NMS19TSTU3MCBpcyBub3Qg c2V0CiMgQ09ORklHX0NMS19UV0w2MDQwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ09NTU9OX0NM S19RQ09NIGlzIG5vdCBzZXQKQ09ORklHX0hXU1BJTkxPQ0s9eQoKIwojIEhhcmR3YXJlIFNw aW5sb2NrIGRyaXZlcnMKIwpDT05GSUdfSFdTUElOTE9DS19PTUFQPXkKQ09ORklHX0NMS1NS Q19PRj15CkNPTkZJR19DTEtTUkNfTU1JTz15CkNPTkZJR19BUk1fQVJDSF9USU1FUj15CkNP TkZJR19BUk1fQVJDSF9USU1FUl9FVlRTVFJFQU09eQpDT05GSUdfTUFJTEJPWD15CkNPTkZJ R19PTUFQMlBMVVNfTUJPWD15CkNPTkZJR19PTUFQX01CT1hfS0ZJRk9fU0laRT0yNTYKQ09O RklHX0lPTU1VX0FQST15CkNPTkZJR19JT01NVV9TVVBQT1JUPXkKQ09ORklHX09GX0lPTU1V PXkKQ09ORklHX09NQVBfSU9NTVU9eQpDT05GSUdfT01BUF9JT1ZNTT15CkNPTkZJR19PTUFQ X0lPTU1VX0RFQlVHPXkKIyBDT05GSUdfQVJNX1NNTVUgaXMgbm90IHNldAoKIwojIFJlbW90 ZXByb2MgZHJpdmVycwojCkNPTkZJR19SRU1PVEVQUk9DPW0KQ09ORklHX09NQVBfUkVNT1RF UFJPQz1tCkNPTkZJR19PTUFQX1JFTU9URVBST0NfV0FUQ0hET0c9eQojIENPTkZJR19TVEVf TU9ERU1fUlBST0MgaXMgbm90IHNldAojIENPTkZJR19QUlVTU19SRU1PVEVQUk9DIGlzIG5v dCBzZXQKCiMKIyBScG1zZyBkcml2ZXJzCiMKQ09ORklHX1JQTVNHPW0KQ09ORklHX1JQTVNH X1JQQz1tCiMgQ09ORklHX1BNX0RFVkZSRVEgaXMgbm90IHNldApDT05GSUdfRVhUQ09OPXkK CiMKIyBFeHRjb24gRGV2aWNlIERyaXZlcnMKIwpDT05GSUdfRVhUQ09OX0dQSU89eQojIENP TkZJR19FWFRDT05fQURDX0pBQ0sgaXMgbm90IHNldApDT05GSUdfRVhUQ09OX1BBTE1BUz15 CiMgQ09ORklHX01FTU9SWSBpcyBub3Qgc2V0CkNPTkZJR19JSU89bQpDT05GSUdfSUlPX0JV RkZFUj15CkNPTkZJR19JSU9fQlVGRkVSX0NCPXkKQ09ORklHX0lJT19LRklGT19CVUY9bQpD T05GSUdfSUlPX1RSSUdHRVI9eQpDT05GSUdfSUlPX0NPTlNVTUVSU19QRVJfVFJJR0dFUj0y CgojCiMgQWNjZWxlcm9tZXRlcnMKIwojIENPTkZJR19CTUExODAgaXMgbm90IHNldAojIENP TkZJR19JSU9fU1RfQUNDRUxfM0FYSVMgaXMgbm90IHNldAojIENPTkZJR19LWFNEOSBpcyBu b3Qgc2V0CgojCiMgQW5hbG9nIHRvIGRpZ2l0YWwgY29udmVydGVycwojCiMgQ09ORklHX0FE NzI2NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzI5OCBpcyBub3Qgc2V0CiMgQ09ORklHX0FE NzQ3NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzc5MSBpcyBub3Qgc2V0CiMgQ09ORklHX0FE Nzc5MyBpcyBub3Qgc2V0CiMgQ09ORklHX0FENzg4NyBpcyBub3Qgc2V0CiMgQ09ORklHX0FE NzkyMyBpcyBub3Qgc2V0CiMgQ09ORklHX0VYWU5PU19BREMgaXMgbm90IHNldAojIENPTkZJ R19NQVgxMzYzIGlzIG5vdCBzZXQKIyBDT05GSUdfTUNQMzIwWCBpcyBub3Qgc2V0CiMgQ09O RklHX01DUDM0MjIgaXMgbm90IHNldAojIENPTkZJR19OQVU3ODAyIGlzIG5vdCBzZXQKIyBD T05GSUdfVElfQURDMDgxQyBpcyBub3Qgc2V0CkNPTkZJR19USV9BTTMzNVhfQURDPW0KCiMK IyBBbXBsaWZpZXJzCiMKIyBDT05GSUdfQUQ4MzY2IGlzIG5vdCBzZXQKCiMKIyBIaWQgU2Vu c29yIElJTyBDb21tb24KIwoKIwojIERpZ2l0YWwgdG8gYW5hbG9nIGNvbnZlcnRlcnMKIwoj IENPTkZJR19BRDUwNjQgaXMgbm90IHNldAojIENPTkZJR19BRDUzNjAgaXMgbm90IHNldAoj IENPTkZJR19BRDUzODAgaXMgbm90IHNldAojIENPTkZJR19BRDU0MjEgaXMgbm90IHNldAoj IENPTkZJR19BRDU0NDYgaXMgbm90IHNldAojIENPTkZJR19BRDU0NDkgaXMgbm90IHNldAoj IENPTkZJR19BRDU1MDQgaXMgbm90IHNldAojIENPTkZJR19BRDU2MjRSX1NQSSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENTY4NiBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc1NSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENTc2NCBpcyBub3Qgc2V0CiMgQ09ORklHX0FENTc5MSBpcyBub3Qg c2V0CiMgQ09ORklHX0FENzMwMyBpcyBub3Qgc2V0CiMgQ09ORklHX01BWDUxNyBpcyBub3Qg c2V0CiMgQ09ORklHX01DUDQ3MjUgaXMgbm90IHNldAoKIwojIEZyZXF1ZW5jeSBTeW50aGVz aXplcnMgRERTL1BMTAojCgojCiMgQ2xvY2sgR2VuZXJhdG9yL0Rpc3RyaWJ1dGlvbgojCiMg Q09ORklHX0FEOTUyMyBpcyBub3Qgc2V0CgojCiMgUGhhc2UtTG9ja2VkIExvb3AgKFBMTCkg ZnJlcXVlbmN5IHN5bnRoZXNpemVycwojCiMgQ09ORklHX0FERjQzNTAgaXMgbm90IHNldAoK IwojIERpZ2l0YWwgZ3lyb3Njb3BlIHNlbnNvcnMKIwojIENPTkZJR19BRElTMTYwODAgaXMg bm90IHNldAojIENPTkZJR19BRElTMTYxMzAgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYx MzYgaXMgbm90IHNldAojIENPTkZJR19BRElTMTYyNjAgaXMgbm90IHNldAojIENPTkZJR19B RFhSUzQ1MCBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TVF9HWVJPXzNBWElTIGlzIG5vdCBz ZXQKIyBDT05GSUdfSVRHMzIwMCBpcyBub3Qgc2V0CgojCiMgSHVtaWRpdHkgc2Vuc29ycwoj CiMgQ09ORklHX0RIVDExIGlzIG5vdCBzZXQKCiMKIyBJbmVydGlhbCBtZWFzdXJlbWVudCB1 bml0cwojCiMgQ09ORklHX0FESVMxNjQwMCBpcyBub3Qgc2V0CiMgQ09ORklHX0FESVMxNjQ4 MCBpcyBub3Qgc2V0CiMgQ09ORklHX0lOVl9NUFU2MDUwX0lJTyBpcyBub3Qgc2V0CgojCiMg TGlnaHQgc2Vuc29ycwojCiMgQ09ORklHX0FESkRfUzMxMSBpcyBub3Qgc2V0CiMgQ09ORklH X0FQRFM5MzAwIGlzIG5vdCBzZXQKIyBDT05GSUdfQ00zMjE4MSBpcyBub3Qgc2V0CiMgQ09O RklHX0NNMzY2NTEgaXMgbm90IHNldAojIENPTkZJR19HUDJBUDAyMEEwMEYgaXMgbm90IHNl dAojIENPTkZJR19UQ1MzNDcyIGlzIG5vdCBzZXQKIyBDT05GSUdfU0VOU09SU19UU0wyNTYz IGlzIG5vdCBzZXQKIyBDT05GSUdfVFNMNDUzMSBpcyBub3Qgc2V0CiMgQ09ORklHX1ZDTkw0 MDAwIGlzIG5vdCBzZXQKCiMKIyBNYWduZXRvbWV0ZXIgc2Vuc29ycwojCiMgQ09ORklHX0FL ODk3NSBpcyBub3Qgc2V0CiMgQ09ORklHX01BRzMxMTAgaXMgbm90IHNldAojIENPTkZJR19J SU9fU1RfTUFHTl8zQVhJUyBpcyBub3Qgc2V0CgojCiMgSW5jbGlub21ldGVyIHNlbnNvcnMK IwoKIwojIFRyaWdnZXJzIC0gc3RhbmRhbG9uZQojCiMgQ09ORklHX0lJT19JTlRFUlJVUFRf VFJJR0dFUiBpcyBub3Qgc2V0CiMgQ09ORklHX0lJT19TWVNGU19UUklHR0VSIGlzIG5vdCBz ZXQKCiMKIyBQcmVzc3VyZSBzZW5zb3JzCiMKIyBDT05GSUdfTVBMMzExNSBpcyBub3Qgc2V0 CiMgQ09ORklHX0lJT19TVF9QUkVTUyBpcyBub3Qgc2V0CgojCiMgVGVtcGVyYXR1cmUgc2Vu c29ycwojCiMgQ09ORklHX1RNUDAwNiBpcyBub3Qgc2V0CiMgQ09ORklHX1ZNRV9CVVMgaXMg bm90IHNldApDT05GSUdfUFdNPXkKQ09ORklHX1BXTV9TWVNGUz15CiMgQ09ORklHX1BXTV9Q Q0E5Njg1IGlzIG5vdCBzZXQKQ09ORklHX0lSUUNISVA9eQpDT05GSUdfQVJNX0dJQz15CkNP TkZJR19JUlFfQ1JPU1NCQVI9eQojIENPTkZJR19JUEFDS19CVVMgaXMgbm90IHNldAojIENP TkZJR19SRVNFVF9DT05UUk9MTEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfRk1DIGlzIG5vdCBz ZXQKCiMKIyBQSFkgU3Vic3lzdGVtCiMKQ09ORklHX0dFTkVSSUNfUEhZPXkKIyBDT05GSUdf UEhZX0VYWU5PU19NSVBJX1ZJREVPIGlzIG5vdCBzZXQKQ09ORklHX09NQVBfQ09OVFJPTF9Q SFk9eQpDT05GSUdfT01BUF9VU0IyPXkKQ09ORklHX1RJX1BJUEUzPXkKIyBDT05GSUdfUEhZ X0VYWU5PU19EUF9WSURFTyBpcyBub3Qgc2V0CiMgQ09ORklHX0JDTV9LT05BX1VTQjJfUEhZ IGlzIG5vdCBzZXQKIyBDT05GSUdfUE9XRVJDQVAgaXMgbm90IHNldAoKIwojIEZpbGUgc3lz dGVtcwojCkNPTkZJR19EQ0FDSEVfV09SRF9BQ0NFU1M9eQpDT05GSUdfRVhUMl9GUz15CiMg Q09ORklHX0VYVDJfRlNfWEFUVFIgaXMgbm90IHNldAojIENPTkZJR19FWFQyX0ZTX1hJUCBp cyBub3Qgc2V0CkNPTkZJR19FWFQzX0ZTPXkKQ09ORklHX0VYVDNfREVGQVVMVFNfVE9fT1JE RVJFRD15CiMgQ09ORklHX0VYVDNfRlNfWEFUVFIgaXMgbm90IHNldApDT05GSUdfRVhUNF9G Uz15CiMgQ09ORklHX0VYVDRfRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfRVhU NF9GU19TRUNVUklUWSBpcyBub3Qgc2V0CiMgQ09ORklHX0VYVDRfREVCVUcgaXMgbm90IHNl dApDT05GSUdfSkJEPXkKIyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0pC RDI9eQojIENPTkZJR19KQkQyX0RFQlVHIGlzIG5vdCBzZXQKQ09ORklHX0ZTX01CQ0FDSEU9 eQojIENPTkZJR19SRUlTRVJGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0pGU19GUyBpcyBu b3Qgc2V0CiMgQ09ORklHX1hGU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0dGUzJfRlMgaXMg bm90IHNldAojIENPTkZJR19PQ0ZTMl9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0JUUkZTX0ZT IGlzIG5vdCBzZXQKIyBDT05GSUdfTklMRlMyX0ZTIGlzIG5vdCBzZXQKQ09ORklHX0ZTX1BP U0lYX0FDTD15CkNPTkZJR19GSUxFX0xPQ0tJTkc9eQpDT05GSUdfRlNOT1RJRlk9eQpDT05G SUdfRE5PVElGWT15CkNPTkZJR19JTk9USUZZX1VTRVI9eQojIENPTkZJR19GQU5PVElGWSBp cyBub3Qgc2V0CkNPTkZJR19RVU9UQT15CiMgQ09ORklHX1FVT1RBX05FVExJTktfSU5URVJG QUNFIGlzIG5vdCBzZXQKQ09ORklHX1BSSU5UX1FVT1RBX1dBUk5JTkc9eQojIENPTkZJR19R VU9UQV9ERUJVRyBpcyBub3Qgc2V0CkNPTkZJR19RVU9UQV9UUkVFPXkKIyBDT05GSUdfUUZN VF9WMSBpcyBub3Qgc2V0CkNPTkZJR19RRk1UX1YyPXkKQ09ORklHX1FVT1RBQ1RMPXkKIyBD T05GSUdfQVVUT0ZTNF9GUyBpcyBub3Qgc2V0CiMgQ09ORklHX0ZVU0VfRlMgaXMgbm90IHNl dAoKIwojIENhY2hlcwojCiMgQ09ORklHX0ZTQ0FDSEUgaXMgbm90IHNldAoKIwojIENELVJP TS9EVkQgRmlsZXN5c3RlbXMKIwojIENPTkZJR19JU085NjYwX0ZTIGlzIG5vdCBzZXQKIyBD T05GSUdfVURGX0ZTIGlzIG5vdCBzZXQKCiMKIyBET1MvRkFUL05UIEZpbGVzeXN0ZW1zCiMK Q09ORklHX0ZBVF9GUz15CkNPTkZJR19NU0RPU19GUz15CkNPTkZJR19WRkFUX0ZTPXkKQ09O RklHX0ZBVF9ERUZBVUxUX0NPREVQQUdFPTQzNwpDT05GSUdfRkFUX0RFRkFVTFRfSU9DSEFS U0VUPSJpc284ODU5LTEiCiMgQ09ORklHX05URlNfRlMgaXMgbm90IHNldAoKIwojIFBzZXVk byBmaWxlc3lzdGVtcwojCkNPTkZJR19QUk9DX0ZTPXkKQ09ORklHX1BST0NfU1lTQ1RMPXkK Q09ORklHX1BST0NfUEFHRV9NT05JVE9SPXkKQ09ORklHX1NZU0ZTPXkKQ09ORklHX1RNUEZT PXkKIyBDT05GSUdfVE1QRlNfUE9TSVhfQUNMIGlzIG5vdCBzZXQKIyBDT05GSUdfVE1QRlNf WEFUVFIgaXMgbm90IHNldAojIENPTkZJR19IVUdFVExCRlMgaXMgbm90IHNldAojIENPTkZJ R19IVUdFVExCX1BBR0UgaXMgbm90IHNldApDT05GSUdfQ09ORklHRlNfRlM9bQpDT05GSUdf TUlTQ19GSUxFU1lTVEVNUz15CiMgQ09ORklHX0FERlNfRlMgaXMgbm90IHNldAojIENPTkZJ R19BRkZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfRUNSWVBUX0ZTIGlzIG5vdCBzZXQKIyBD T05GSUdfSEZTX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfSEZTUExVU19GUyBpcyBub3Qgc2V0 CiMgQ09ORklHX0JFRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19CRlNfRlMgaXMgbm90IHNl dAojIENPTkZJR19FRlNfRlMgaXMgbm90IHNldApDT05GSUdfSkZGUzJfRlM9eQpDT05GSUdf SkZGUzJfRlNfREVCVUc9MApDT05GSUdfSkZGUzJfRlNfV1JJVEVCVUZGRVI9eQojIENPTkZJ R19KRkZTMl9GU19XQlVGX1ZFUklGWSBpcyBub3Qgc2V0CkNPTkZJR19KRkZTMl9TVU1NQVJZ PXkKQ09ORklHX0pGRlMyX0ZTX1hBVFRSPXkKQ09ORklHX0pGRlMyX0ZTX1BPU0lYX0FDTD15 CkNPTkZJR19KRkZTMl9GU19TRUNVUklUWT15CkNPTkZJR19KRkZTMl9DT01QUkVTU0lPTl9P UFRJT05TPXkKQ09ORklHX0pGRlMyX1pMSUI9eQpDT05GSUdfSkZGUzJfTFpPPXkKQ09ORklH X0pGRlMyX1JUSU1FPXkKQ09ORklHX0pGRlMyX1JVQklOPXkKIyBDT05GSUdfSkZGUzJfQ01P REVfTk9ORSBpcyBub3Qgc2V0CkNPTkZJR19KRkZTMl9DTU9ERV9QUklPUklUWT15CiMgQ09O RklHX0pGRlMyX0NNT0RFX1NJWkUgaXMgbm90IHNldAojIENPTkZJR19KRkZTMl9DTU9ERV9G QVZPVVJMWk8gaXMgbm90IHNldApDT05GSUdfVUJJRlNfRlM9eQojIENPTkZJR19VQklGU19G U19BRFZBTkNFRF9DT01QUiBpcyBub3Qgc2V0CkNPTkZJR19VQklGU19GU19MWk89eQpDT05G SUdfVUJJRlNfRlNfWkxJQj15CiMgQ09ORklHX0xPR0ZTIGlzIG5vdCBzZXQKQ09ORklHX0NS QU1GUz15CiMgQ09ORklHX1NRVUFTSEZTIGlzIG5vdCBzZXQKIyBDT05GSUdfVlhGU19GUyBp cyBub3Qgc2V0CiMgQ09ORklHX01JTklYX0ZTIGlzIG5vdCBzZXQKIyBDT05GSUdfT01GU19G UyBpcyBub3Qgc2V0CiMgQ09ORklHX0hQRlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg0 RlNfRlMgaXMgbm90IHNldAojIENPTkZJR19RTlg2RlNfRlMgaXMgbm90IHNldAojIENPTkZJ R19ST01GU19GUyBpcyBub3Qgc2V0CiMgQ09ORklHX1BTVE9SRSBpcyBub3Qgc2V0CiMgQ09O RklHX1NZU1ZfRlMgaXMgbm90IHNldAojIENPTkZJR19VRlNfRlMgaXMgbm90IHNldAojIENP TkZJR19GMkZTX0ZTIGlzIG5vdCBzZXQKQ09ORklHX05FVFdPUktfRklMRVNZU1RFTVM9eQpD T05GSUdfTkZTX0ZTPXkKQ09ORklHX05GU19WMj15CkNPTkZJR19ORlNfVjM9eQpDT05GSUdf TkZTX1YzX0FDTD15CkNPTkZJR19ORlNfVjQ9eQojIENPTkZJR19ORlNfU1dBUCBpcyBub3Qg c2V0CiMgQ09ORklHX05GU19WNF8xIGlzIG5vdCBzZXQKQ09ORklHX1JPT1RfTkZTPXkKIyBD T05GSUdfTkZTX1VTRV9MRUdBQ1lfRE5TIGlzIG5vdCBzZXQKQ09ORklHX05GU19VU0VfS0VS TkVMX0ROUz15CiMgQ09ORklHX05GU0QgaXMgbm90IHNldApDT05GSUdfTE9DS0Q9eQpDT05G SUdfTE9DS0RfVjQ9eQpDT05GSUdfTkZTX0FDTF9TVVBQT1JUPXkKQ09ORklHX05GU19DT01N T049eQpDT05GSUdfU1VOUlBDPXkKQ09ORklHX1NVTlJQQ19HU1M9eQojIENPTkZJR19TVU5S UENfREVCVUcgaXMgbm90IHNldAojIENPTkZJR19DRVBIX0ZTIGlzIG5vdCBzZXQKIyBDT05G SUdfQ0lGUyBpcyBub3Qgc2V0CiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0CiMgQ09ORklH X0NPREFfRlMgaXMgbm90IHNldAojIENPTkZJR19BRlNfRlMgaXMgbm90IHNldApDT05GSUdf TkxTPXkKQ09ORklHX05MU19ERUZBVUxUPSJpc284ODU5LTEiCkNPTkZJR19OTFNfQ09ERVBB R0VfNDM3PXkKIyBDT05GSUdfTkxTX0NPREVQQUdFXzczNyBpcyBub3Qgc2V0CiMgQ09ORklH X05MU19DT0RFUEFHRV83NzUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0VfODUw IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg1MiBpcyBub3Qgc2V0CiMgQ09O RklHX05MU19DT0RFUEFHRV84NTUgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBBR0Vf ODU3IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MCBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19DT0RFUEFHRV84NjEgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09ERVBB R0VfODYyIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MyBpcyBub3Qgc2V0 CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjQgaXMgbm90IHNldAojIENPTkZJR19OTFNfQ09E RVBBR0VfODY1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2NiBpcyBub3Qg c2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV84NjkgaXMgbm90IHNldAojIENPTkZJR19OTFNf Q09ERVBBR0VfOTM2IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzk1MCBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV85MzIgaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfOTQ5IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0NPREVQQUdFXzg3NCBp cyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzggaXMgbm90IHNldAojIENPTkZJR19O TFNfQ09ERVBBR0VfMTI1MCBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19DT0RFUEFHRV8xMjUx IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0FTQ0lJIGlzIG5vdCBzZXQKQ09ORklHX05MU19J U084ODU5XzE9eQojIENPTkZJR19OTFNfSVNPODg1OV8yIGlzIG5vdCBzZXQKIyBDT05GSUdf TkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzQgaXMgbm90 IHNldAojIENPTkZJR19OTFNfSVNPODg1OV81IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lT Tzg4NTlfNiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19JU084ODU5XzcgaXMgbm90IHNldAoj IENPTkZJR19OTFNfSVNPODg1OV85IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0lTTzg4NTlf MTMgaXMgbm90IHNldAojIENPTkZJR19OTFNfSVNPODg1OV8xNCBpcyBub3Qgc2V0CiMgQ09O RklHX05MU19JU084ODU5XzE1IGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX0tPSThfUiBpcyBu b3Qgc2V0CiMgQ09ORklHX05MU19LT0k4X1UgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFD X1JPTUFOIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19DRUxUSUMgaXMgbm90IHNldAoj IENPTkZJR19OTFNfTUFDX0NFTlRFVVJPIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19D Uk9BVElBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfQ1lSSUxMSUMgaXMgbm90IHNl dAojIENPTkZJR19OTFNfTUFDX0dBRUxJQyBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNf R1JFRUsgaXMgbm90IHNldAojIENPTkZJR19OTFNfTUFDX0lDRUxBTkQgaXMgbm90IHNldAoj IENPTkZJR19OTFNfTUFDX0lOVUlUIGlzIG5vdCBzZXQKIyBDT05GSUdfTkxTX01BQ19ST01B TklBTiBpcyBub3Qgc2V0CiMgQ09ORklHX05MU19NQUNfVFVSS0lTSCBpcyBub3Qgc2V0CiMg Q09ORklHX05MU19VVEY4IGlzIG5vdCBzZXQKIyBDT05GSUdfRExNIGlzIG5vdCBzZXQKCiMK IyBLZXJuZWwgaGFja2luZwojCgojCiMgcHJpbnRrIGFuZCBkbWVzZyBvcHRpb25zCiMKQ09O RklHX1BSSU5US19USU1FPXkKQ09ORklHX0RFRkFVTFRfTUVTU0FHRV9MT0dMRVZFTD00CiMg Q09ORklHX0JPT1RfUFJJTlRLX0RFTEFZIGlzIG5vdCBzZXQKIyBDT05GSUdfRFlOQU1JQ19E RUJVRyBpcyBub3Qgc2V0CgojCiMgQ29tcGlsZS10aW1lIGNoZWNrcyBhbmQgY29tcGlsZXIg b3B0aW9ucwojCkNPTkZJR19ERUJVR19JTkZPPXkKIyBDT05GSUdfREVCVUdfSU5GT19SRURV Q0VEIGlzIG5vdCBzZXQKQ09ORklHX0VOQUJMRV9XQVJOX0RFUFJFQ0FURUQ9eQpDT05GSUdf RU5BQkxFX01VU1RfQ0hFQ0s9eQpDT05GSUdfRlJBTUVfV0FSTj0xMDI0CiMgQ09ORklHX1NU UklQX0FTTV9TWU1TIGlzIG5vdCBzZXQKIyBDT05GSUdfUkVBREFCTEVfQVNNIGlzIG5vdCBz ZXQKIyBDT05GSUdfVU5VU0VEX1NZTUJPTFMgaXMgbm90IHNldApDT05GSUdfREVCVUdfRlM9 eQojIENPTkZJR19IRUFERVJTX0NIRUNLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0VD VElPTl9NSVNNQVRDSCBpcyBub3Qgc2V0CkNPTkZJR19GUkFNRV9QT0lOVEVSPXkKIyBDT05G SUdfREVCVUdfRk9SQ0VfV0VBS19QRVJfQ1BVIGlzIG5vdCBzZXQKQ09ORklHX01BR0lDX1NZ U1JRPXkKQ09ORklHX01BR0lDX1NZU1JRX0RFRkFVTFRfRU5BQkxFPTB4MQpDT05GSUdfREVC VUdfS0VSTkVMPXkKCiMKIyBNZW1vcnkgRGVidWdnaW5nCiMKIyBDT05GSUdfREVCVUdfUEFH RUFMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfT0JKRUNUUyBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX1NMQUIgaXMgbm90IHNldApDT05GSUdfSEFWRV9ERUJVR19LTUVNTEVB Sz15CiMgQ09ORklHX0RFQlVHX0tNRU1MRUFLIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdf U1RBQ0tfVVNBR0UgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19WTSBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX01FTU9SWV9JTklUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfUEVS X0NQVV9NQVBTIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfSElHSE1FTSBpcyBub3Qgc2V0 CiMgQ09ORklHX0RFQlVHX1NISVJRIGlzIG5vdCBzZXQKCiMKIyBEZWJ1ZyBMb2NrdXBzIGFu ZCBIYW5ncwojCiMgQ09ORklHX0xPQ0tVUF9ERVRFQ1RPUiBpcyBub3Qgc2V0CiMgQ09ORklH X0RFVEVDVF9IVU5HX1RBU0sgaXMgbm90IHNldAojIENPTkZJR19QQU5JQ19PTl9PT1BTIGlz IG5vdCBzZXQKQ09ORklHX1BBTklDX09OX09PUFNfVkFMVUU9MApDT05GSUdfUEFOSUNfVElN RU9VVD0wCiMgQ09ORklHX1NDSEVEX0RFQlVHIGlzIG5vdCBzZXQKIyBDT05GSUdfU0NIRURT VEFUUyBpcyBub3Qgc2V0CiMgQ09ORklHX1RJTUVSX1NUQVRTIGlzIG5vdCBzZXQKQ09ORklH X0RFQlVHX1BSRUVNUFQ9eQoKIwojIExvY2sgRGVidWdnaW5nIChzcGlubG9ja3MsIG11dGV4 ZXMsIGV0Yy4uLikKIwojIENPTkZJR19ERUJVR19SVF9NVVRFWEVTIGlzIG5vdCBzZXQKIyBD T05GSUdfUlRfTVVURVhfVEVTVEVSIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU1BJTkxP Q0sgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19NVVRFWEVTIGlzIG5vdCBzZXQKIyBDT05G SUdfREVCVUdfV1dfTVVURVhfU0xPV1BBVEggaXMgbm90IHNldAojIENPTkZJR19ERUJVR19M T0NLX0FMTE9DIGlzIG5vdCBzZXQKIyBDT05GSUdfUFJPVkVfTE9DS0lORyBpcyBub3Qgc2V0 CiMgQ09ORklHX0xPQ0tfU1RBVCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0FUT01JQ19T TEVFUCBpcyBub3Qgc2V0CiMgQ09ORklHX0RFQlVHX0xPQ0tJTkdfQVBJX1NFTEZURVNUUyBp cyBub3Qgc2V0CiMgQ09ORklHX1NUQUNLVFJBQ0UgaXMgbm90IHNldAojIENPTkZJR19ERUJV R19LT0JKRUNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfQlVHVkVSQk9TRSBpcyBub3Qg c2V0CiMgQ09ORklHX0RFQlVHX1dSSVRFQ09VTlQgaXMgbm90IHNldAojIENPTkZJR19ERUJV R19MSVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfU0cgaXMgbm90IHNldAojIENPTkZJ R19ERUJVR19OT1RJRklFUlMgaXMgbm90IHNldAojIENPTkZJR19ERUJVR19DUkVERU5USUFM UyBpcyBub3Qgc2V0CgojCiMgUkNVIERlYnVnZ2luZwojCiMgQ09ORklHX1BST1ZFX1JDVV9E RUxBWSBpcyBub3Qgc2V0CiMgQ09ORklHX1NQQVJTRV9SQ1VfUE9JTlRFUiBpcyBub3Qgc2V0 CiMgQ09ORklHX1JDVV9UT1JUVVJFX1RFU1QgaXMgbm90IHNldApDT05GSUdfUkNVX0NQVV9T VEFMTF9USU1FT1VUPTIxCkNPTkZJR19SQ1VfQ1BVX1NUQUxMX1ZFUkJPU0U9eQojIENPTkZJ R19SQ1VfQ1BVX1NUQUxMX0lORk8gaXMgbm90IHNldAojIENPTkZJR19SQ1VfVFJBQ0UgaXMg bm90IHNldAojIENPTkZJR19ERUJVR19CTE9DS19FWFRfREVWVCBpcyBub3Qgc2V0CiMgQ09O RklHX05PVElGSUVSX0VSUk9SX0lOSkVDVElPTiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZBVUxU X0lOSkVDVElPTiBpcyBub3Qgc2V0CkNPTkZJR19IQVZFX0ZVTkNUSU9OX1RSQUNFUj15CkNP TkZJR19IQVZFX0ZVTkNUSU9OX0dSQVBIX1RSQUNFUj15CkNPTkZJR19IQVZFX0RZTkFNSUNf RlRSQUNFPXkKQ09ORklHX0hBVkVfRlRSQUNFX01DT1VOVF9SRUNPUkQ9eQpDT05GSUdfSEFW RV9TWVNDQUxMX1RSQUNFUE9JTlRTPXkKQ09ORklHX0hBVkVfQ19SRUNPUkRNQ09VTlQ9eQpD T05GSUdfVFJBQ0VfQ0xPQ0s9eQpDT05GSUdfUklOR19CVUZGRVI9eQpDT05GSUdfUklOR19C VUZGRVJfQUxMT1dfU1dBUD15CkNPTkZJR19UUkFDSU5HX1NVUFBPUlQ9eQojIENPTkZJR19G VFJBQ0UgaXMgbm90IHNldAoKIwojIFJ1bnRpbWUgVGVzdGluZwojCiMgQ09ORklHX0xLRFRN IGlzIG5vdCBzZXQKIyBDT05GSUdfVEVTVF9MSVNUX1NPUlQgaXMgbm90IHNldAojIENPTkZJ R19LUFJPQkVTX1NBTklUWV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfQkFDS1RSQUNFX1NF TEZfVEVTVCBpcyBub3Qgc2V0CiMgQ09ORklHX1JCVFJFRV9URVNUIGlzIG5vdCBzZXQKIyBD T05GSUdfSU5URVJWQUxfVFJFRV9URVNUIGlzIG5vdCBzZXQKIyBDT05GSUdfUEVSQ1BVX1RF U1QgaXMgbm90IHNldAojIENPTkZJR19BVE9NSUM2NF9TRUxGVEVTVCBpcyBub3Qgc2V0CiMg Q09ORklHX1RFU1RfU1RSSU5HX0hFTFBFUlMgaXMgbm90IHNldAojIENPTkZJR19URVNUX0tT VFJUT1ggaXMgbm90IHNldAojIENPTkZJR19ETUFfQVBJX0RFQlVHIGlzIG5vdCBzZXQKIyBD T05GSUdfVEVTVF9NT0RVTEUgaXMgbm90IHNldAojIENPTkZJR19URVNUX1VTRVJfQ09QWSBp cyBub3Qgc2V0CiMgQ09ORklHX1NBTVBMRVMgaXMgbm90IHNldApDT05GSUdfSEFWRV9BUkNI X0tHREI9eQojIENPTkZJR19LR0RCIGlzIG5vdCBzZXQKIyBDT05GSUdfQVJNX1BURFVNUCBp cyBub3Qgc2V0CiMgQ09ORklHX1NUUklDVF9ERVZNRU0gaXMgbm90IHNldAojIENPTkZJR19B Uk1fVU5XSU5EIGlzIG5vdCBzZXQKIyBDT05GSUdfREVCVUdfVVNFUiBpcyBub3Qgc2V0CiMg Q09ORklHX0RFQlVHX0xMIGlzIG5vdCBzZXQKQ09ORklHX0RFQlVHX0xMX0lOQ0xVREU9Im1h Y2gvZGVidWctbWFjcm8uUyIKIyBDT05GSUdfREVCVUdfVUFSVF9QTDAxWCBpcyBub3Qgc2V0 CiMgQ09ORklHX0RFQlVHX1VBUlRfODI1MCBpcyBub3Qgc2V0CkNPTkZJR19VTkNPTVBSRVNT X0lOQ0xVREU9ImRlYnVnL3VuY29tcHJlc3MuaCIKIyBDT05GSUdfQVJNX0tQUk9CRVNfVEVT VCBpcyBub3Qgc2V0CiMgQ09ORklHX1BJRF9JTl9DT05URVhUSURSIGlzIG5vdCBzZXQKIyBD T05GSUdfREVCVUdfU0VUX01PRFVMRV9ST05YIGlzIG5vdCBzZXQKCiMKIyBTZWN1cml0eSBv cHRpb25zCiMKQ09ORklHX0tFWVM9eQojIENPTkZJR19QRVJTSVNURU5UX0tFWVJJTkdTIGlz IG5vdCBzZXQKIyBDT05GSUdfQklHX0tFWVMgaXMgbm90IHNldAojIENPTkZJR19FTkNSWVBU RURfS0VZUyBpcyBub3Qgc2V0CiMgQ09ORklHX0tFWVNfREVCVUdfUFJPQ19LRVlTIGlzIG5v dCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfRE1FU0dfUkVTVFJJQ1QgaXMgbm90IHNldApDT05G SUdfU0VDVVJJVFk9eQojIENPTkZJR19TRUNVUklUWUZTIGlzIG5vdCBzZXQKIyBDT05GSUdf U0VDVVJJVFlfTkVUV09SSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX1BBVEggaXMg bm90IHNldAojIENPTkZJR19TRUNVUklUWV9TTUFDSyBpcyBub3Qgc2V0CiMgQ09ORklHX1NF Q1VSSVRZX1RPTU9ZTyBpcyBub3Qgc2V0CiMgQ09ORklHX1NFQ1VSSVRZX0FQUEFSTU9SIGlz IG5vdCBzZXQKIyBDT05GSUdfU0VDVVJJVFlfWUFNQSBpcyBub3Qgc2V0CiMgQ09ORklHX0lN QSBpcyBub3Qgc2V0CiMgQ09ORklHX0VWTSBpcyBub3Qgc2V0CkNPTkZJR19ERUZBVUxUX1NF Q1VSSVRZX0RBQz15CkNPTkZJR19ERUZBVUxUX1NFQ1VSSVRZPSIiCkNPTkZJR19DUllQVE89 eQoKIwojIENyeXB0byBjb3JlIG9yIGhlbHBlcgojCkNPTkZJR19DUllQVE9fQUxHQVBJPXkK Q09ORklHX0NSWVBUT19BTEdBUEkyPXkKQ09ORklHX0NSWVBUT19BRUFEPXkKQ09ORklHX0NS WVBUT19BRUFEMj15CkNPTkZJR19DUllQVE9fQkxLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19C TEtDSVBIRVIyPXkKQ09ORklHX0NSWVBUT19IQVNIPXkKQ09ORklHX0NSWVBUT19IQVNIMj15 CkNPTkZJR19DUllQVE9fUk5HPXkKQ09ORklHX0NSWVBUT19STkcyPXkKQ09ORklHX0NSWVBU T19QQ09NUDI9eQpDT05GSUdfQ1JZUFRPX01BTkFHRVI9eQpDT05GSUdfQ1JZUFRPX01BTkFH RVIyPXkKIyBDT05GSUdfQ1JZUFRPX1VTRVIgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX01B TkFHRVJfRElTQUJMRV9URVNUUz15CiMgQ09ORklHX0NSWVBUT19HRjEyOE1VTCBpcyBub3Qg c2V0CiMgQ09ORklHX0NSWVBUT19OVUxMIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1BD UllQVCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fV09SS1FVRVVFPXkKIyBDT05GSUdfQ1JZ UFRPX0NSWVBURCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19BVVRIRU5DIGlzIG5vdCBz ZXQKQ09ORklHX0NSWVBUT19URVNUPW0KCiMKIyBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24g d2l0aCBBc3NvY2lhdGVkIERhdGEKIwpDT05GSUdfQ1JZUFRPX0NDTT15CiMgQ09ORklHX0NS WVBUT19HQ00gaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX1NFUUlWPXkKCiMKIyBCbG9jayBt b2RlcwojCiMgQ09ORklHX0NSWVBUT19DQkMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0NU Uj15CiMgQ09ORklHX0NSWVBUT19DVFMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0VDQj15 CiMgQ09ORklHX0NSWVBUT19MUlcgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUENCQyBp cyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19YVFMgaXMgbm90IHNldAoKIwojIEhhc2ggbW9k ZXMKIwojIENPTkZJR19DUllQVE9fQ01BQyBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fSE1B Qz15CiMgQ09ORklHX0NSWVBUT19YQ0JDIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1ZN QUMgaXMgbm90IHNldAoKIwojIERpZ2VzdAojCkNPTkZJR19DUllQVE9fQ1JDMzJDPXkKIyBD T05GSUdfQ1JZUFRPX0NSQzMyIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19DUkNUMTBESUY9 eQojIENPTkZJR19DUllQVE9fR0hBU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fTUQ0 IGlzIG5vdCBzZXQKQ09ORklHX0NSWVBUT19NRDU9eQpDT05GSUdfQ1JZUFRPX01JQ0hBRUxf TUlDPXkKIyBDT05GSUdfQ1JZUFRPX1JNRDEyOCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU T19STUQxNjAgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fUk1EMjU2IGlzIG5vdCBzZXQK IyBDT05GSUdfQ1JZUFRPX1JNRDMyMCBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hBMT15 CiMgQ09ORklHX0NSWVBUT19TSEExX0FSTSBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fU0hB MjU2PXkKQ09ORklHX0NSWVBUT19TSEE1MTI9eQojIENPTkZJR19DUllQVE9fVEdSMTkyIGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1dQNTEyIGlzIG5vdCBzZXQKCiMKIyBDaXBoZXJz CiMKQ09ORklHX0NSWVBUT19BRVM9eQojIENPTkZJR19DUllQVE9fQUVTX0FSTSBpcyBub3Qg c2V0CiMgQ09ORklHX0NSWVBUT19BTlVCSVMgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0FS QzQ9eQojIENPTkZJR19DUllQVE9fQkxPV0ZJU0ggaXMgbm90IHNldAojIENPTkZJR19DUllQ VE9fQ0FNRUxMSUEgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fQ0FTVDUgaXMgbm90IHNl dAojIENPTkZJR19DUllQVE9fQ0FTVDYgaXMgbm90IHNldApDT05GSUdfQ1JZUFRPX0RFUz15 CiMgQ09ORklHX0NSWVBUT19GQ1JZUFQgaXMgbm90IHNldAojIENPTkZJR19DUllQVE9fS0hB WkFEIGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1NBTFNBMjAgaXMgbm90IHNldAojIENP TkZJR19DUllQVE9fU0VFRCBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBUT19TRVJQRU5UIGlz IG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRPX1RFQSBpcyBub3Qgc2V0CiMgQ09ORklHX0NSWVBU T19UV09GSVNIIGlzIG5vdCBzZXQKCiMKIyBDb21wcmVzc2lvbgojCkNPTkZJR19DUllQVE9f REVGTEFURT15CiMgQ09ORklHX0NSWVBUT19aTElCIGlzIG5vdCBzZXQKQ09ORklHX0NSWVBU T19MWk89eQojIENPTkZJR19DUllQVE9fTFo0IGlzIG5vdCBzZXQKIyBDT05GSUdfQ1JZUFRP X0xaNEhDIGlzIG5vdCBzZXQKCiMKIyBSYW5kb20gTnVtYmVyIEdlbmVyYXRpb24KIwojIENP TkZJR19DUllQVE9fQU5TSV9DUFJORyBpcyBub3Qgc2V0CkNPTkZJR19DUllQVE9fVVNFUl9B UEk9eQpDT05GSUdfQ1JZUFRPX1VTRVJfQVBJX0hBU0g9eQpDT05GSUdfQ1JZUFRPX1VTRVJf QVBJX1NLQ0lQSEVSPXkKQ09ORklHX0NSWVBUT19IVz15CkNPTkZJR19DUllQVE9fREVWX09N QVBfU0hBTT15CkNPTkZJR19DUllQVE9fREVWX09NQVBfQUVTPXkKQ09ORklHX0NSWVBUT19E RVZfT01BUF9ERVM9eQojIENPTkZJR19BU1lNTUVUUklDX0tFWV9UWVBFIGlzIG5vdCBzZXQK IyBDT05GSUdfQklOQVJZX1BSSU5URiBpcyBub3Qgc2V0CgojCiMgTGlicmFyeSByb3V0aW5l cwojCkNPTkZJR19CSVRSRVZFUlNFPXkKQ09ORklHX0dFTkVSSUNfU1RSTkNQWV9GUk9NX1VT RVI9eQpDT05GSUdfR0VORVJJQ19TVFJOTEVOX1VTRVI9eQpDT05GSUdfR0VORVJJQ19ORVRf VVRJTFM9eQpDT05GSUdfR0VORVJJQ19QQ0lfSU9NQVA9eQpDT05GSUdfR0VORVJJQ19JTz15 CkNPTkZJR19BUkNIX1VTRV9DTVBYQ0hHX0xPQ0tSRUY9eQpDT05GSUdfQ1JDX0NDSVRUPXkK Q09ORklHX0NSQzE2PXkKQ09ORklHX0NSQ19UMTBESUY9eQpDT05GSUdfQ1JDX0lUVV9UPXkK Q09ORklHX0NSQzMyPXkKIyBDT05GSUdfQ1JDMzJfU0VMRlRFU1QgaXMgbm90IHNldApDT05G SUdfQ1JDMzJfU0xJQ0VCWTg9eQojIENPTkZJR19DUkMzMl9TTElDRUJZNCBpcyBub3Qgc2V0 CiMgQ09ORklHX0NSQzMyX1NBUldBVEUgaXMgbm90IHNldAojIENPTkZJR19DUkMzMl9CSVQg aXMgbm90IHNldApDT05GSUdfQ1JDNz15CkNPTkZJR19MSUJDUkMzMkM9eQojIENPTkZJR19D UkM4IGlzIG5vdCBzZXQKIyBDT05GSUdfUkFORE9NMzJfU0VMRlRFU1QgaXMgbm90IHNldApD T05GSUdfWkxJQl9JTkZMQVRFPXkKQ09ORklHX1pMSUJfREVGTEFURT15CkNPTkZJR19MWk9f Q09NUFJFU1M9eQpDT05GSUdfTFpPX0RFQ09NUFJFU1M9eQojIENPTkZJR19YWl9ERUMgaXMg bm90IHNldAojIENPTkZJR19YWl9ERUNfQkNKIGlzIG5vdCBzZXQKQ09ORklHX0RFQ09NUFJF U1NfR1pJUD15CkNPTkZJR19CQ0g9eQpDT05GSUdfQVNTT0NJQVRJVkVfQVJSQVk9eQpDT05G SUdfSEFTX0lPTUVNPXkKQ09ORklHX0hBU19JT1BPUlQ9eQpDT05GSUdfSEFTX0RNQT15CkNP TkZJR19DUFVfUk1BUD15CkNPTkZJR19EUUw9eQpDT05GSUdfTkxBVFRSPXkKQ09ORklHX0FS Q0hfSEFTX0FUT01JQzY0X0RFQ19JRl9QT1NJVElWRT15CiMgQ09ORklHX0FWRVJBR0UgaXMg bm90IHNldAojIENPTkZJR19DT1JESUMgaXMgbm90IHNldAojIENPTkZJR19ERFIgaXMgbm90 IHNldApDT05GSUdfT0lEX1JFR0lTVFJZPXkKQ09ORklHX0ZPTlRfU1VQUE9SVD15CkNPTkZJ R19GT05UUz15CkNPTkZJR19GT05UXzh4OD15CkNPTkZJR19GT05UXzh4MTY9eQojIENPTkZJ R19GT05UXzZ4MTEgaXMgbm90IHNldAojIENPTkZJR19GT05UXzd4MTQgaXMgbm90IHNldAoj IENPTkZJR19GT05UX1BFQVJMXzh4OCBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRfQUNPUk5f OHg4IGlzIG5vdCBzZXQKIyBDT05GSUdfRk9OVF9NSU5JXzR4NiBpcyBub3Qgc2V0CiMgQ09O RklHX0ZPTlRfU1VOOHgxNiBpcyBub3Qgc2V0CiMgQ09ORklHX0ZPTlRfU1VOMTJ4MjIgaXMg bm90IHNldAojIENPTkZJR19GT05UXzEweDE4IGlzIG5vdCBzZXQKQ09ORklHX1ZJUlRVQUxJ WkFUSU9OPXkKIyBDT05GSUdfS1ZNIGlzIG5vdCBzZXQK --------------020909000202020305090300 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020909000202020305090300-- From xen-users-bounces@lists.xen.org Thu Jul 09 17:05:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:05:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFFB-0006P5-EU; Thu, 09 Jul 2015 17:04:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFF9-0006Mh-Ji for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:04:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 61/99-01469-F89AE955; Thu, 09 Jul 2015 17:04:15 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1436461450!30751411!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32671 invoked from network); 9 Jul 2015 17:04:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 17:04:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="279593323" Message-ID: <1436460908.23508.159.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Thu, 9 Jul 2015 17:55:08 +0100 In-Reply-To: <559E7D63.3050804@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 09:55 -0400, Brandon Perez wrote: > I also noticed the following line during the Dom0 guest boot: > > (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz > > Is this expected to be different from the expected interrupt ID's > for ARM core timers (these numbers are all offset by +5)? That does seem odd, in particular because PPIs are in the range 16..31 inclusive, so it looks like you phys and virt timer interrupts are SPIs, which is unexpected and I'm not sure if/how it will work. These numbers I believe come basically direct from the device tree. Could you provide the DTB which you are using for your platform, or even better the DTS source. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 17:05:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:05:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFFB-0006P5-EU; Thu, 09 Jul 2015 17:04:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFF9-0006Mh-Ji for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:04:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 61/99-01469-F89AE955; Thu, 09 Jul 2015 17:04:15 +0000 X-Env-Sender: prvs=62559f241=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1436461450!30751411!3 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32671 invoked from network); 9 Jul 2015 17:04:14 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 9 Jul 2015 17:04:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="279593323" Message-ID: <1436460908.23508.159.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Thu, 9 Jul 2015 17:55:08 +0100 In-Reply-To: <559E7D63.3050804@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 09:55 -0400, Brandon Perez wrote: > I also noticed the following line during the Dom0 guest boot: > > (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz > > Is this expected to be different from the expected interrupt ID's > for ARM core timers (these numbers are all offset by +5)? That does seem odd, in particular because PPIs are in the range 16..31 inclusive, so it looks like you phys and virt timer interrupts are SPIs, which is unexpected and I'm not sure if/how it will work. These numbers I believe come basically direct from the device tree. Could you provide the DTB which you are using for your platform, or even better the DTS source. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 17:46:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:46:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFtU-0001uQ-Uf; Thu, 09 Jul 2015 17:45:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFtT-0001uL-Cx for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:45:55 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 0D/6B-01469-253BE955; Thu, 09 Jul 2015 17:45:54 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-10.tower-27.messagelabs.com!1436463953!30715290!1 X-Originating-IP: [212.7.160.42] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12098 invoked from network); 9 Jul 2015 17:45:53 -0000 Received: from mout02.rz-online.net (HELO mout02.rz-online.net) (212.7.160.42) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 17:45:53 -0000 Received: from donald.local (212-7-188-241.ktk-ip.de [212.7.188.241]) by mout02.rz-online.net (8.14.0/8.12.10) with ESMTP id t69HjqpC022734 for ; Thu, 9 Jul 2015 19:45:52 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id C161CA0552 for ; Thu, 9 Jul 2015 19:45:32 +0200 (CEST) Message-ID: <559EB33C.8010800@rz-online.de> Date: Thu, 09 Jul 2015 19:45:32 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users Content-Length:1083 Subject: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgWGVuIHNlcmlhbCBjb25zb2xlLCBidXQgb24gYSBjb21w dXRlciB3aGljaCBkb2VzIApub3QgaGF2ZSBhIHNlcmlhbCBkZXZpY2UuCgpTbyBJIGhhdmUgdG8g dXNlIHRoZSBzby1jYWxsZWQgVVNCIGRlYnVnZ2luZyBwb3J0IChjb25zb2xlPWRiZ3ApLiBUaGUg ClVTQiBjb250cm9sbGVyIGluIG15IHN5c3RlbSBzZWVtcyB0byBzdXBwb3J0IHRoaXMuCgpCdXQg d2hlcmUgZG8gSSBmaW5kIGFuIFVTQiBjYWJsZSB0byBjb25uZWN0IG15IGNvbXB1dGVyIHRvIGFu b3RoZXIgb25lIAp2aWEgVVNCPwoKTW9zdCBkb2N1bWVudGF0aW9ucyByZWZlciB0byBhIHNtYWxs IGRldmljZSBjYWxsZWQgTkVUMjBEQywgdG8gd2hpY2ggeW91IApjYW4gY29ubmVjdCBib3RoIGNv bXB1dGVycyB2aWEgVVNCLiBVbmZvcnR1bmF0ZWx5LCB0aGlzIGRldmljZSBkb2Vzbid0IApzZWVt IHRvIGJlIGF2YWlsYWJsZSBhbnltb3JlLgoKSXMgdGhlcmUgYW5vdGhlciBkZXZpY2UsIHdoaWNo IGlzIHN0aWxsIGF2YWlsYWJsZSBhbmQgaXMga25vd24gdG8gd29yaz8KCi0tIApNYW5mcmVkIEjD pHJ0ZWwsIERCM0hNICAgIG1haWx0bzpNYW5mcmVkLkhhZXJ0ZWxAcnotb25saW5lLmRlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3J6LWhvbWUuZGUvbWhhZXJ0ZWwKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5n IGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVz ZXJz From xen-users-bounces@lists.xen.org Thu Jul 09 17:46:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:46:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFtU-0001uQ-Uf; Thu, 09 Jul 2015 17:45:56 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDFtT-0001uL-Cx for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:45:55 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 0D/6B-01469-253BE955; Thu, 09 Jul 2015 17:45:54 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-10.tower-27.messagelabs.com!1436463953!30715290!1 X-Originating-IP: [212.7.160.42] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12098 invoked from network); 9 Jul 2015 17:45:53 -0000 Received: from mout02.rz-online.net (HELO mout02.rz-online.net) (212.7.160.42) by server-10.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 17:45:53 -0000 Received: from donald.local (212-7-188-241.ktk-ip.de [212.7.188.241]) by mout02.rz-online.net (8.14.0/8.12.10) with ESMTP id t69HjqpC022734 for ; Thu, 9 Jul 2015 19:45:52 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id C161CA0552 for ; Thu, 9 Jul 2015 19:45:32 +0200 (CEST) Message-ID: <559EB33C.8010800@rz-online.de> Date: Thu, 09 Jul 2015 19:45:32 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users Content-Length:1083 Subject: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgWGVuIHNlcmlhbCBjb25zb2xlLCBidXQgb24gYSBjb21w dXRlciB3aGljaCBkb2VzIApub3QgaGF2ZSBhIHNlcmlhbCBkZXZpY2UuCgpTbyBJIGhhdmUgdG8g dXNlIHRoZSBzby1jYWxsZWQgVVNCIGRlYnVnZ2luZyBwb3J0IChjb25zb2xlPWRiZ3ApLiBUaGUg ClVTQiBjb250cm9sbGVyIGluIG15IHN5c3RlbSBzZWVtcyB0byBzdXBwb3J0IHRoaXMuCgpCdXQg d2hlcmUgZG8gSSBmaW5kIGFuIFVTQiBjYWJsZSB0byBjb25uZWN0IG15IGNvbXB1dGVyIHRvIGFu b3RoZXIgb25lIAp2aWEgVVNCPwoKTW9zdCBkb2N1bWVudGF0aW9ucyByZWZlciB0byBhIHNtYWxs IGRldmljZSBjYWxsZWQgTkVUMjBEQywgdG8gd2hpY2ggeW91IApjYW4gY29ubmVjdCBib3RoIGNv bXB1dGVycyB2aWEgVVNCLiBVbmZvcnR1bmF0ZWx5LCB0aGlzIGRldmljZSBkb2Vzbid0IApzZWVt IHRvIGJlIGF2YWlsYWJsZSBhbnltb3JlLgoKSXMgdGhlcmUgYW5vdGhlciBkZXZpY2UsIHdoaWNo IGlzIHN0aWxsIGF2YWlsYWJsZSBhbmQgaXMga25vd24gdG8gd29yaz8KCi0tIApNYW5mcmVkIEjD pHJ0ZWwsIERCM0hNICAgIG1haWx0bzpNYW5mcmVkLkhhZXJ0ZWxAcnotb25saW5lLmRlCiAgICAg ICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3J6LWhvbWUuZGUvbWhhZXJ0ZWwKCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fClhlbi11c2VycyBtYWlsaW5n IGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVz ZXJz From xen-users-bounces@lists.xen.org Thu Jul 09 17:58:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDG5Y-00040G-Pu; Thu, 09 Jul 2015 17:58:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDG5Y-000403-3u for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:58:24 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 8D/C4-29123-F36BE955; Thu, 09 Jul 2015 17:58:23 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1436464701!19350697!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3792 invoked from network); 9 Jul 2015 17:58:22 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 17:58:22 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69HwHYX023887; Thu, 9 Jul 2015 12:58:17 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69HwHYk022666; Thu, 9 Jul 2015 12:58:17 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 12:58:00 -0500 Message-ID: <559EA82C.7020404@ti.com> Date: Thu, 9 Jul 2015 12:58:20 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <1436460908.23508.159.camel@citrix.com> In-Reply-To: <1436460908.23508.159.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/09/2015 12:55 PM, Ian Campbell wrote: > On Thu, 2015-07-09 at 09:55 -0400, Brandon Perez wrote: >> I also noticed the following line during the Dom0 guest boot: >> >> (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz >> >> Is this expected to be different from the expected interrupt ID's >> for ARM core timers (these numbers are all offset by +5)? > > That does seem odd, in particular because PPIs are in the range 16..31 > inclusive, so it looks like you phys and virt timer interrupts are SPIs, > which is unexpected and I'm not sure if/how it will work. > > These numbers I believe come basically direct from the device tree. > Could you provide the DTB which you are using for your platform, or even > better the DTS source. > > Ian. > > Hi Ian, Yep, that's correct, the issue was coming from those interrupts from being improperly mapped. This was caused due some local changes I made in the Xen source code. My previous email explains it in greater detail. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 09 17:58:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 09 Jul 2015 17:58:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDG5Y-00040G-Pu; Thu, 09 Jul 2015 17:58:24 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDG5Y-000403-3u for xen-users@lists.xen.org; Thu, 09 Jul 2015 17:58:24 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 8D/C4-29123-F36BE955; Thu, 09 Jul 2015 17:58:23 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-5.tower-27.messagelabs.com!1436464701!19350697!1 X-Originating-IP: [192.94.94.41] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQxID0+IDE2NDY4Ng==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3792 invoked from network); 9 Jul 2015 17:58:22 -0000 Received: from bear.ext.ti.com (HELO bear.ext.ti.com) (192.94.94.41) by server-5.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2015 17:58:22 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id t69HwHYX023887; Thu, 9 Jul 2015 12:58:17 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t69HwHYk022666; Thu, 9 Jul 2015 12:58:17 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Thu, 9 Jul 2015 12:58:00 -0500 Message-ID: <559EA82C.7020404@ti.com> Date: Thu, 9 Jul 2015 12:58:20 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <1436460908.23508.159.camel@citrix.com> In-Reply-To: <1436460908.23508.159.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/09/2015 12:55 PM, Ian Campbell wrote: > On Thu, 2015-07-09 at 09:55 -0400, Brandon Perez wrote: >> I also noticed the following line during the Dom0 guest boot: >> >> (XEN) Generic Timer IRQ: phys=35 hyp=31 virt=32 Freq: 6147 KHz >> >> Is this expected to be different from the expected interrupt ID's >> for ARM core timers (these numbers are all offset by +5)? > > That does seem odd, in particular because PPIs are in the range 16..31 > inclusive, so it looks like you phys and virt timer interrupts are SPIs, > which is unexpected and I'm not sure if/how it will work. > > These numbers I believe come basically direct from the device tree. > Could you provide the DTB which you are using for your platform, or even > better the DTS source. > > Ian. > > Hi Ian, Yep, that's correct, the issue was coming from those interrupts from being improperly mapped. This was caused due some local changes I made in the Xen source code. My previous email explains it in greater detail. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 07:03:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 07:03:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSK9-00040j-5d; Fri, 10 Jul 2015 07:02:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSK7-00040e-Gy for xen-users@lists.xen.org; Fri, 10 Jul 2015 07:02:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 73/AC-01469-6FD6F955; Fri, 10 Jul 2015 07:02:14 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-11.tower-27.messagelabs.com!1436511732!24765498!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18591 invoked from network); 10 Jul 2015 07:02:13 -0000 Received: from mail-qk0-f182.google.com (HELO mail-qk0-f182.google.com) (209.85.220.182) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 07:02:13 -0000 Received: by qkbp125 with SMTP id p125so201292851qkb.2 for ; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s0eWJJRgN0wFkQ4IAykSybgNxXebjeoRb7hHHva9gE4=; b=L2qgHoykuReHWZLq5ZJoL3pozA8geXJiV+xELV9rExPk7R479027nXVtuIwYEa1f3P TXFb9MVwn2VFwHMSgF0UpQjSPwXfOQV2TuPCI9Yg1f2vD7lzz+OTp/lJ9Er9RDD/03C+ 6nh/IJmopjnD1Y2hk5X9fkihDltcxdFVlqg7TAjWeCQsidNN5GqajHzBi7CgQRUGS8cC xn2pxRRH77HuUiwGKfj1vM9BcxkFdipljsyk0xkxZ5AkQrYIAIxASXzGAK09UV70dG1J 0N9wKYZfvjmGheOIqWLNC3Clwr4RiooS8Mgm1spXCUnVluhSDLdd70mHL15ICGMBasNG Wj+A== X-Gm-Message-State: ALoCoQkQFSRRnAPU3mZ3FWj3WcYzl8wgL3h76brWYbkFHqwDK11lpkUDboIqy8IilTlsMAJwYs2l MIME-Version: 1.0 X-Received: by 10.140.91.246 with SMTP id z109mr30967468qgd.39.1436511732654; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) In-Reply-To: <1436442225.23508.118.camel@citrix.com> References: <1436442225.23508.118.camel@citrix.com> Date: Fri, 10 Jul 2015 08:02:12 +0100 Message-ID: From: Phil Lello To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8649463169387574132==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8649463169387574132== Content-Type: multipart/alternative; boundary=001a113a6f368a8457051a7ff397 --001a113a6f368a8457051a7ff397 Content-Type: text/plain; charset=UTF-8 Hi all, Many thanks. I'm not actually sure why I was using routed networking for this node, as I'm issuing addresses from 192.168.1.x whilst the host is on a real IP. I now have DHCP working with dnsmasq, and am working on getting a NFS root partition working.... which rather than thread-jacking myself, I'll discuss on a new thread. Phil On Thu, Jul 9, 2015 at 12:43 PM, Ian Campbell wrote: > On Thu, 2015-07-09 at 11:12 +0100, Phil Lello wrote: > > Hi all, > > > > > > I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, > > using routed networking > > Normally routed networking[0] would imply no bridge, but rather some > routing/firewall(NAT) tables in domain 0. > > In particular vif-route won't put any virtual interfaces onto the > bridge, because it assumes things will be routed. > > Perhaps you are trying to build a "brouter"[1]? I don't know much about > this configuration or how it is supposed to work, but I do notice that > the document linked from [1] at [2] uses vif-bridge not vif-route (I'd > recommend ignoring the xend specfic network-* scripting there and > setting it up via the distro mechanisms such > as /etc/default/interfaces). > > HTH, > > Ian. > > [0] > http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing > [1] http://wiki.xen.org/wiki/Xen_Networking#Advanced_configurations > [2] https://tr.opensuse.org/Xen3_and_a_Virtual_Network > > > > > > --001a113a6f368a8457051a7ff397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Many thanks. I'm n= ot actually sure why I was using routed networking for this node, as I'= m issuing addresses from 192.168.1.x whilst the host is on a real IP.
I now have DHCP working with dnsmasq, and am working on getting a N= FS root partition working.... which rather than thread-jacking myself, I= 9;ll discuss on a new thread.

Phil

On Thu, Jul 9, 2015 at 12:43 PM, Ia= n Campbell <ian.campbell@citrix.com> wrote:
On Thu, 2015-07-09 at 11:12 +0100,= Phil Lello wrote:
> Hi all,
>
>
> I'm trying to confugre DHCP on Dom0 to server up addresses to DomU= ,
> using routed networking

Normally routed networking[0] would imply no bridge, but rather some=
routing/firewall(NAT) tables in domain 0.

In particular vif-route won't put any virtual interfaces onto the
bridge, because it assumes things will be routed.

Perhaps you are trying to build a "brouter"[1]? I don't know = much about
this configuration or how it is supposed to work, but I do notice that
the document linked from [1] at [2] uses vif-bridge not vif-route (I'd<= br> recommend ignoring the xend specfic network-* scripting there and
setting it up via the distro mechanisms such
as /etc/default/interfaces).

HTH,

Ian.

[0] http://wiki.xen.= org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing
[1] http://wiki.xen.org/wiki/Xen_Netw= orking#Advanced_configurations
[2] https://tr.opensuse.org/Xen3_and_a_Virtual_Net= work






--001a113a6f368a8457051a7ff397-- --===============8649463169387574132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8649463169387574132==-- From xen-users-bounces@lists.xen.org Fri Jul 10 07:03:27 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 07:03:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSK9-00040j-5d; Fri, 10 Jul 2015 07:02:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSK7-00040e-Gy for xen-users@lists.xen.org; Fri, 10 Jul 2015 07:02:15 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 73/AC-01469-6FD6F955; Fri, 10 Jul 2015 07:02:14 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-11.tower-27.messagelabs.com!1436511732!24765498!1 X-Originating-IP: [209.85.220.182] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18591 invoked from network); 10 Jul 2015 07:02:13 -0000 Received: from mail-qk0-f182.google.com (HELO mail-qk0-f182.google.com) (209.85.220.182) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 07:02:13 -0000 Received: by qkbp125 with SMTP id p125so201292851qkb.2 for ; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s0eWJJRgN0wFkQ4IAykSybgNxXebjeoRb7hHHva9gE4=; b=L2qgHoykuReHWZLq5ZJoL3pozA8geXJiV+xELV9rExPk7R479027nXVtuIwYEa1f3P TXFb9MVwn2VFwHMSgF0UpQjSPwXfOQV2TuPCI9Yg1f2vD7lzz+OTp/lJ9Er9RDD/03C+ 6nh/IJmopjnD1Y2hk5X9fkihDltcxdFVlqg7TAjWeCQsidNN5GqajHzBi7CgQRUGS8cC xn2pxRRH77HuUiwGKfj1vM9BcxkFdipljsyk0xkxZ5AkQrYIAIxASXzGAK09UV70dG1J 0N9wKYZfvjmGheOIqWLNC3Clwr4RiooS8Mgm1spXCUnVluhSDLdd70mHL15ICGMBasNG Wj+A== X-Gm-Message-State: ALoCoQkQFSRRnAPU3mZ3FWj3WcYzl8wgL3h76brWYbkFHqwDK11lpkUDboIqy8IilTlsMAJwYs2l MIME-Version: 1.0 X-Received: by 10.140.91.246 with SMTP id z109mr30967468qgd.39.1436511732654; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 00:02:12 -0700 (PDT) In-Reply-To: <1436442225.23508.118.camel@citrix.com> References: <1436442225.23508.118.camel@citrix.com> Date: Fri, 10 Jul 2015 08:02:12 +0100 Message-ID: From: Phil Lello To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] DHCP / Ubuntu X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8649463169387574132==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8649463169387574132== Content-Type: multipart/alternative; boundary=001a113a6f368a8457051a7ff397 --001a113a6f368a8457051a7ff397 Content-Type: text/plain; charset=UTF-8 Hi all, Many thanks. I'm not actually sure why I was using routed networking for this node, as I'm issuing addresses from 192.168.1.x whilst the host is on a real IP. I now have DHCP working with dnsmasq, and am working on getting a NFS root partition working.... which rather than thread-jacking myself, I'll discuss on a new thread. Phil On Thu, Jul 9, 2015 at 12:43 PM, Ian Campbell wrote: > On Thu, 2015-07-09 at 11:12 +0100, Phil Lello wrote: > > Hi all, > > > > > > I'm trying to confugre DHCP on Dom0 to server up addresses to DomU, > > using routed networking > > Normally routed networking[0] would imply no bridge, but rather some > routing/firewall(NAT) tables in domain 0. > > In particular vif-route won't put any virtual interfaces onto the > bridge, because it assumes things will be routed. > > Perhaps you are trying to build a "brouter"[1]? I don't know much about > this configuration or how it is supposed to work, but I do notice that > the document linked from [1] at [2] uses vif-bridge not vif-route (I'd > recommend ignoring the xend specfic network-* scripting there and > setting it up via the distro mechanisms such > as /etc/default/interfaces). > > HTH, > > Ian. > > [0] > http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing > [1] http://wiki.xen.org/wiki/Xen_Networking#Advanced_configurations > [2] https://tr.opensuse.org/Xen3_and_a_Virtual_Network > > > > > > --001a113a6f368a8457051a7ff397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Many thanks. I'm n= ot actually sure why I was using routed networking for this node, as I'= m issuing addresses from 192.168.1.x whilst the host is on a real IP.
I now have DHCP working with dnsmasq, and am working on getting a N= FS root partition working.... which rather than thread-jacking myself, I= 9;ll discuss on a new thread.

Phil

On Thu, Jul 9, 2015 at 12:43 PM, Ia= n Campbell <ian.campbell@citrix.com> wrote:
On Thu, 2015-07-09 at 11:12 +0100,= Phil Lello wrote:
> Hi all,
>
>
> I'm trying to confugre DHCP on Dom0 to server up addresses to DomU= ,
> using routed networking

Normally routed networking[0] would imply no bridge, but rather some=
routing/firewall(NAT) tables in domain 0.

In particular vif-route won't put any virtual interfaces onto the
bridge, because it assumes things will be routed.

Perhaps you are trying to build a "brouter"[1]? I don't know = much about
this configuration or how it is supposed to work, but I do notice that
the document linked from [1] at [2] uses vif-bridge not vif-route (I'd<= br> recommend ignoring the xend specfic network-* scripting there and
setting it up via the distro mechanisms such
as /etc/default/interfaces).

HTH,

Ian.

[0] http://wiki.xen.= org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Routing
[1] http://wiki.xen.org/wiki/Xen_Netw= orking#Advanced_configurations
[2] https://tr.opensuse.org/Xen3_and_a_Virtual_Net= work






--001a113a6f368a8457051a7ff397-- --===============8649463169387574132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8649463169387574132==-- From xen-users-bounces@lists.xen.org Fri Jul 10 07:21:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 07:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSba-0004c5-1V; Fri, 10 Jul 2015 07:20:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSbX-0004c0-OJ for xen-users@lists.xen.org; Fri, 10 Jul 2015 07:20:15 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 35/D4-23832-F227F955; Fri, 10 Jul 2015 07:20:15 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-2.tower-31.messagelabs.com!1436512813!24459431!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14885 invoked from network); 10 Jul 2015 07:20:14 -0000 Received: from mail-qk0-f171.google.com (HELO mail-qk0-f171.google.com) (209.85.220.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 07:20:14 -0000 Received: by qkcl188 with SMTP id l188so18299195qkc.1 for ; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=d5ybByBFKRtPOB0WF7aY9XnefsrMaZQ+M6oknvHAbkI=; b=AMClsmJcD4TI5lnImbRuEljS4XHUn0Umc2yDe7Fzmnisx2U5afcYc3G0FWrqAJR4Bl Fu7gC8q2Te9t0Ej8p6Jdk/FJfICeTBnxmxuVucexPv4/OxFnP7cqxIvOI9+L3l+JzilC 8wLKPGiHEa03bnQGslE3O9uz0bk/YsNgdxD9pT81N31uYv/1JaqIJDd5Y/IBt7LxmpmE ai3lipvPeg/QOLmau90qbaSHfrRWrecEkpghBiqujwD182C/FxLl0hlC2GDB2GJXhZQV DbcnNuTpCVPwBtfcvuccCyGJ1hQRsV/W38idobDAB3+WqjDUCzNzRXnLf+bH9hX1Ci7K fIBg== X-Gm-Message-State: ALoCoQnpmbOwtm2bWZU9p4a3BP5XsZz9xDu1ckcRvy4KxSP4vZuyHIsVQM+XkYGmV84CQkO27p/E MIME-Version: 1.0 X-Received: by 10.140.150.142 with SMTP id 136mr29496008qhw.17.1436512813150; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) Date: Fri, 10 Jul 2015 08:20:13 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: [Xen-users] NFS root partition for DomU (xenpvnetboot) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205237819148443892==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1205237819148443892== Content-Type: multipart/alternative; boundary=001a11357d4af192fe051a803366 --001a11357d4af192fe051a803366 Content-Type: text/plain; charset=UTF-8 Hi all, Following on from getting DHCP working for my DomU client, I'm now trying to get a NFS mounted root filesystem. I'm using xenpvnetboot [1] since this seemed the correct approach from internet searches - not sure if the author lurks on this list or not. My VM config looks like: memory = 1024 # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 8 name = "nfsboot" vif = [ 'script=vif-bridge,mac=00:16:3e:00:00:01' ] disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] #bootloader = "pygrub" bootloader = "xenpvnetboot" bootloader_args= [ '--location', 'nfs:192.168.1.1:/nfs/nfsboot-root' ] #bootloader_args= [ '--location', '/nfs/nfsboot-root' ] kernel = "vmlinuz" ramdisk = "initrd.img" The kernel is booting, so I'm reasonably certain NFS is configured correctly, but instead of getting the root partition mounted, I am spammed with: Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path done. Looking at the console output, I'm wondering if I've missed a DHCP option or two (it seems the NFS root isn't getting passed as I expected from the bootloader - or maybe I need to tinker with the initrd.img): [ 1.483755] FS-Cache: Netfs 'nfs' registered for caching IP-Config: eth0 hardware address 00:16:3e:00:00:01 mtu 1500 DHCP RARP IP-Config: eth0 complete (dhcp from 192.168.1.1): address: 192.168.1.176 broadcast: 192.168.1.255 netmask: 255.255.255.0 gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : 0.0.0.0 rootserver: 192.168.1.1 rootpath: filename : Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path done. Any help greatly appreciated. Phil [1] http://wiki.xenproject.org/wiki/Xenpvnetboot --001a11357d4af192fe051a803366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Fo= llowing on from getting DHCP working for my DomU client, I'm now trying= to get a NFS mounted root filesystem.

I'm using xenpvnetb= oot [1] since this seemed the correct approach from internet searches - not= sure if the author lurks on this list or not.

My VM config lo= oks like:

memory =3D 1024

# Should be at least 2KB per MB of = domain memory, plus a few MB per vcpu.
shadow_memory =3D 8
name =3D &= quot;nfsboot"
vif =3D [ 'script=3Dvif-bridge,mac=3D00:16:3e:00:= 00:01' ]
disk =3D [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w= 9; ]

#bootloader =3D "pygrub"
bootloader =3D "xenp= vnetboot"
bootloader_args=3D [ '--location', 'nfs:192.1= 68.1.1:/nfs/nfsboot-root' ]
#bootloader_args=3D [ '--location= 9;, '/nfs/nfsboot-root' ]
kernel =3D "vmlinuz"
ramd= isk =3D "initrd.img"

The kernel is booting, so I'= ;m reasonably certain NFS is configured correctly, but instead of getting t= he root partition mounted, I am spammed with:

Begin: Retrying nfs mo= unt ... Begin: Running /scripts/nfs-premount ... done.
nfsmount: need a = path
done.

Looking at the console output, I'm wondering= if I've missed a DHCP option or two (it seems the NFS root isn't g= etting passed as I expected from the bootloader - or maybe I need to tinker= with the initrd.img):

[=C2=A0=C2=A0=C2=A0 1.483755] FS-Cache: Netfs= 'nfs' registered for caching
IP-Config: eth0 hardware address 0= 0:16:3e:00:00:01 mtu 1500 DHCP RARP
IP-Config: eth0 complete (dhcp from = 192.168.1.1):
=C2=A0address: 192.168.1.176=C2=A0=C2=A0=C2=A0 broadcast: = 192.168.1.255=C2=A0=C2=A0=C2=A0 netmask: 255.255.255.0=C2=A0=C2=A0

= =C2=A0gateway: 192.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns0=C2=A0=C2=A0= =C2=A0=C2=A0 : 192.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns1=C2=A0=C2=A0 := 0.0.0.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0root= server: 192.168.1.1 rootpath:
=C2=A0filename=C2=A0 :
Begin: Running= /scripts/nfs-premount ... done.
nfsmount: need a path
Begin: Retryin= g nfs mount ... Begin: Running /scripts/nfs-premount ... done.
nfsmount:= need a path
done.

Any help greatly appreciated.

Phil
--001a11357d4af192fe051a803366-- --===============1205237819148443892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1205237819148443892==-- From xen-users-bounces@lists.xen.org Fri Jul 10 07:21:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 07:21:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSba-0004c5-1V; Fri, 10 Jul 2015 07:20:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDSbX-0004c0-OJ for xen-users@lists.xen.org; Fri, 10 Jul 2015 07:20:15 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 35/D4-23832-F227F955; Fri, 10 Jul 2015 07:20:15 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-2.tower-31.messagelabs.com!1436512813!24459431!1 X-Originating-IP: [209.85.220.171] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14885 invoked from network); 10 Jul 2015 07:20:14 -0000 Received: from mail-qk0-f171.google.com (HELO mail-qk0-f171.google.com) (209.85.220.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 07:20:14 -0000 Received: by qkcl188 with SMTP id l188so18299195qkc.1 for ; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=d5ybByBFKRtPOB0WF7aY9XnefsrMaZQ+M6oknvHAbkI=; b=AMClsmJcD4TI5lnImbRuEljS4XHUn0Umc2yDe7Fzmnisx2U5afcYc3G0FWrqAJR4Bl Fu7gC8q2Te9t0Ej8p6Jdk/FJfICeTBnxmxuVucexPv4/OxFnP7cqxIvOI9+L3l+JzilC 8wLKPGiHEa03bnQGslE3O9uz0bk/YsNgdxD9pT81N31uYv/1JaqIJDd5Y/IBt7LxmpmE ai3lipvPeg/QOLmau90qbaSHfrRWrecEkpghBiqujwD182C/FxLl0hlC2GDB2GJXhZQV DbcnNuTpCVPwBtfcvuccCyGJ1hQRsV/W38idobDAB3+WqjDUCzNzRXnLf+bH9hX1Ci7K fIBg== X-Gm-Message-State: ALoCoQnpmbOwtm2bWZU9p4a3BP5XsZz9xDu1ckcRvy4KxSP4vZuyHIsVQM+XkYGmV84CQkO27p/E MIME-Version: 1.0 X-Received: by 10.140.150.142 with SMTP id 136mr29496008qhw.17.1436512813150; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 00:20:13 -0700 (PDT) Date: Fri, 10 Jul 2015 08:20:13 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: [Xen-users] NFS root partition for DomU (xenpvnetboot) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1205237819148443892==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1205237819148443892== Content-Type: multipart/alternative; boundary=001a11357d4af192fe051a803366 --001a11357d4af192fe051a803366 Content-Type: text/plain; charset=UTF-8 Hi all, Following on from getting DHCP working for my DomU client, I'm now trying to get a NFS mounted root filesystem. I'm using xenpvnetboot [1] since this seemed the correct approach from internet searches - not sure if the author lurks on this list or not. My VM config looks like: memory = 1024 # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. shadow_memory = 8 name = "nfsboot" vif = [ 'script=vif-bridge,mac=00:16:3e:00:00:01' ] disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] #bootloader = "pygrub" bootloader = "xenpvnetboot" bootloader_args= [ '--location', 'nfs:192.168.1.1:/nfs/nfsboot-root' ] #bootloader_args= [ '--location', '/nfs/nfsboot-root' ] kernel = "vmlinuz" ramdisk = "initrd.img" The kernel is booting, so I'm reasonably certain NFS is configured correctly, but instead of getting the root partition mounted, I am spammed with: Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path done. Looking at the console output, I'm wondering if I've missed a DHCP option or two (it seems the NFS root isn't getting passed as I expected from the bootloader - or maybe I need to tinker with the initrd.img): [ 1.483755] FS-Cache: Netfs 'nfs' registered for caching IP-Config: eth0 hardware address 00:16:3e:00:00:01 mtu 1500 DHCP RARP IP-Config: eth0 complete (dhcp from 192.168.1.1): address: 192.168.1.176 broadcast: 192.168.1.255 netmask: 255.255.255.0 gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : 0.0.0.0 rootserver: 192.168.1.1 rootpath: filename : Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... done. nfsmount: need a path done. Any help greatly appreciated. Phil [1] http://wiki.xenproject.org/wiki/Xenpvnetboot --001a11357d4af192fe051a803366 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

Fo= llowing on from getting DHCP working for my DomU client, I'm now trying= to get a NFS mounted root filesystem.

I'm using xenpvnetb= oot [1] since this seemed the correct approach from internet searches - not= sure if the author lurks on this list or not.

My VM config lo= oks like:

memory =3D 1024

# Should be at least 2KB per MB of = domain memory, plus a few MB per vcpu.
shadow_memory =3D 8
name =3D &= quot;nfsboot"
vif =3D [ 'script=3Dvif-bridge,mac=3D00:16:3e:00:= 00:01' ]
disk =3D [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w= 9; ]

#bootloader =3D "pygrub"
bootloader =3D "xenp= vnetboot"
bootloader_args=3D [ '--location', 'nfs:192.1= 68.1.1:/nfs/nfsboot-root' ]
#bootloader_args=3D [ '--location= 9;, '/nfs/nfsboot-root' ]
kernel =3D "vmlinuz"
ramd= isk =3D "initrd.img"

The kernel is booting, so I'= ;m reasonably certain NFS is configured correctly, but instead of getting t= he root partition mounted, I am spammed with:

Begin: Retrying nfs mo= unt ... Begin: Running /scripts/nfs-premount ... done.
nfsmount: need a = path
done.

Looking at the console output, I'm wondering= if I've missed a DHCP option or two (it seems the NFS root isn't g= etting passed as I expected from the bootloader - or maybe I need to tinker= with the initrd.img):

[=C2=A0=C2=A0=C2=A0 1.483755] FS-Cache: Netfs= 'nfs' registered for caching
IP-Config: eth0 hardware address 0= 0:16:3e:00:00:01 mtu 1500 DHCP RARP
IP-Config: eth0 complete (dhcp from = 192.168.1.1):
=C2=A0address: 192.168.1.176=C2=A0=C2=A0=C2=A0 broadcast: = 192.168.1.255=C2=A0=C2=A0=C2=A0 netmask: 255.255.255.0=C2=A0=C2=A0

= =C2=A0gateway: 192.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns0=C2=A0=C2=A0= =C2=A0=C2=A0 : 192.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns1=C2=A0=C2=A0 := 0.0.0.0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0root= server: 192.168.1.1 rootpath:
=C2=A0filename=C2=A0 :
Begin: Running= /scripts/nfs-premount ... done.
nfsmount: need a path
Begin: Retryin= g nfs mount ... Begin: Running /scripts/nfs-premount ... done.
nfsmount:= need a path
done.

Any help greatly appreciated.

Phil
--001a11357d4af192fe051a803366-- --===============1205237819148443892== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1205237819148443892==-- From xen-users-bounces@lists.xen.org Fri Jul 10 08:16:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 08:16:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDTTB-0008Ic-QY; Fri, 10 Jul 2015 08:15:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDTTA-0008IV-DH for xen-users@lists.xen.org; Fri, 10 Jul 2015 08:15:40 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 0B/DF-03895-B2F7F955; Fri, 10 Jul 2015 08:15:39 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1436516137!20074701!1 X-Originating-IP: [209.85.192.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31496 invoked from network); 10 Jul 2015 08:15:38 -0000 Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 08:15:38 -0000 Received: by qget71 with SMTP id t71so126095865qge.2 for ; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IXRlSoGV9XyodpPfdkq4UICug6F8L9uWk7xzce42Sew=; b=CZlaB/599G0IFLrGBOFLv+bmU1V/AEGU4o3EGqnZCGsYYHAMUk+JrpqW1PB0PRo/7G rf7D5IZK8JZj0O0wGUKb0ivFQijiv+lNG/prBcxZ3P/qrkKmPAcBxPoWd8QgCAEHbTsK 7uXK6ZHZYNEHwUiGy0VewJCZmLYYD2QJQTYuVcyoJ0QKvBenUCa1v5lbXAMXdG4+SEjj /ObYWXX8D9YmyYfozAXEe4satXqnSHOFIfzNHZtYRqfBUefItdsQYmr/IM5OquTwfw5X r6C/aDXQr7y32jxCgNJdPDSwCfIcRkzJxO1UFSFMbuWyhMauQoEimwO95o4j0uCQF6Nb Dydg== X-Gm-Message-State: ALoCoQlOrKsvntQvToPLmNquec2P9pnUDPBOXHTtWDrgwzJi6iiMEM71o5UAFbsU4tvKo6GC0j8W MIME-Version: 1.0 X-Received: by 10.55.26.133 with SMTP id l5mr30686101qkh.40.1436516137576; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2015 09:15:37 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: Re: [Xen-users] NFS root partition for DomU (xenpvnetboot) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414724432340547084==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1414724432340547084== Content-Type: multipart/alternative; boundary=001a1145b642184acf051a80fab4 --001a1145b642184acf051a80fab4 Content-Type: text/plain; charset=UTF-8 And I've got it solved... I needed to explicitly set the NFS server in /etc/initramfs-tools/initramfs.conf. Once I get the xen console connected (ssh works, xl console just hangs after boot messages), I'll document on the Wiki for those that follow. Phil On Fri, Jul 10, 2015 at 8:20 AM, Phil Lello wrote: > Hi all, > > Following on from getting DHCP working for my DomU client, I'm now trying > to get a NFS mounted root filesystem. > > I'm using xenpvnetboot [1] since this seemed the correct approach from > internet searches - not sure if the author lurks on this list or not. > > My VM config looks like: > > memory = 1024 > > # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. > shadow_memory = 8 > name = "nfsboot" > vif = [ 'script=vif-bridge,mac=00:16:3e:00:00:01' ] > disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] > > #bootloader = "pygrub" > bootloader = "xenpvnetboot" > bootloader_args= [ '--location', 'nfs:192.168.1.1:/nfs/nfsboot-root' ] > #bootloader_args= [ '--location', '/nfs/nfsboot-root' ] > kernel = "vmlinuz" > ramdisk = "initrd.img" > > The kernel is booting, so I'm reasonably certain NFS is configured > correctly, but instead of getting the root partition mounted, I am spammed > with: > > Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... > done. > nfsmount: need a path > done. > > Looking at the console output, I'm wondering if I've missed a DHCP option > or two (it seems the NFS root isn't getting passed as I expected from the > bootloader - or maybe I need to tinker with the initrd.img): > > [ 1.483755] FS-Cache: Netfs 'nfs' registered for caching > IP-Config: eth0 hardware address 00:16:3e:00:00:01 mtu 1500 DHCP RARP > IP-Config: eth0 complete (dhcp from 192.168.1.1): > address: 192.168.1.176 broadcast: 192.168.1.255 netmask: > 255.255.255.0 > > gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : > 0.0.0.0 > > rootserver: 192.168.1.1 rootpath: > filename : > Begin: Running /scripts/nfs-premount ... done. > nfsmount: need a path > Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... > done. > nfsmount: need a path > done. > > Any help greatly appreciated. > > Phil > > [1] http://wiki.xenproject.org/wiki/Xenpvnetboot > --001a1145b642184acf051a80fab4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And I've got it solved... I needed to explic= itly set the NFS server in /etc/initramfs-tools/initramfs.conf.

Once I get the xen console connected (ssh works, xl console just hangs af= ter boot messages), I'll document on the Wiki for those that follow.

Phil

On Fri, Jul 10, 2015 at 8:20 AM, Phil Lello <<= a href=3D"mailto:phil@dunlop-lello.uk" target=3D"_blank">phil@dunlop-lello.= uk> wrote:
Hi all,

Following on from = getting DHCP working for my DomU client, I'm now trying to get a NFS mo= unted root filesystem.

I'm using xenpvnetboot [1] since th= is seemed the correct approach from internet searches - not sure if the aut= hor lurks on this list or not.

My VM config looks like:
memory =3D 1024

# Should be at least 2KB per MB of domain memory, p= lus a few MB per vcpu.
shadow_memory =3D 8
name =3D "nfsboot&quo= t;
vif =3D [ 'script=3Dvif-bridge,mac=3D00:16:3e:00:00:01' ]
= disk =3D [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ]

#boo= tloader =3D "pygrub"
bootloader =3D "xenpvnetboot"bootloader_args=3D [ '--location', 'nfs:192.168.1.1:/nfs/nfsb= oot-root' ]
#bootloader_args=3D [ '--location', '/nfs/nf= sboot-root' ]
kernel =3D "vmlinuz"
ramdisk =3D "in= itrd.img"

The kernel is booting, so I'm reasonably ce= rtain NFS is configured correctly, but instead of getting the root partitio= n mounted, I am spammed with:

Begin: Retrying nfs mount ... Begin: R= unning /scripts/nfs-premount ... done.
nfsmount: need a path
done.
Looking at the console output, I'm wondering if I've mis= sed a DHCP option or two (it seems the NFS root isn't getting passed as= I expected from the bootloader - or maybe I need to tinker with the initrd= .img):

[=C2=A0=C2=A0=C2=A0 1.483755] FS-Cache: Netfs 'nfs' r= egistered for caching
IP-Config: eth0 hardware address 00:16:3e:00:00:01= mtu 1500 DHCP RARP
IP-Config: eth0 complete (dhcp from 192.168.1.1):=C2=A0address: 192.168.1.176=C2=A0=C2=A0=C2=A0 broadcast: 192.168.1.255=C2= =A0=C2=A0=C2=A0 netmask: 255.255.255.0=C2=A0=C2=A0

=C2=A0gateway: 1= 92.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns0=C2=A0=C2=A0=C2=A0=C2=A0 : 192= .168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns1=C2=A0=C2=A0 : 0.0.0.0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0rootserver: 192.168.1= .1 rootpath:
=C2=A0filename=C2=A0 :
Begin: Running /scripts/nfs-pre= mount ... done.
nfsmount: need a path
Begin: Retrying nfs mount ... B= egin: Running /scripts/nfs-premount ... done.
nfsmount: need a path
d= one.

Any help greatly appreciated.

Phil

--001a1145b642184acf051a80fab4-- --===============1414724432340547084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1414724432340547084==-- From xen-users-bounces@lists.xen.org Fri Jul 10 08:16:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 08:16:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDTTB-0008Ic-QY; Fri, 10 Jul 2015 08:15:41 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDTTA-0008IV-DH for xen-users@lists.xen.org; Fri, 10 Jul 2015 08:15:40 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 0B/DF-03895-B2F7F955; Fri, 10 Jul 2015 08:15:39 +0000 X-Env-Sender: phil@dunlop-lello.uk X-Msg-Ref: server-6.tower-31.messagelabs.com!1436516137!20074701!1 X-Originating-IP: [209.85.192.52] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31496 invoked from network); 10 Jul 2015 08:15:38 -0000 Received: from mail-qg0-f52.google.com (HELO mail-qg0-f52.google.com) (209.85.192.52) by server-6.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 08:15:38 -0000 Received: by qget71 with SMTP id t71so126095865qge.2 for ; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=IXRlSoGV9XyodpPfdkq4UICug6F8L9uWk7xzce42Sew=; b=CZlaB/599G0IFLrGBOFLv+bmU1V/AEGU4o3EGqnZCGsYYHAMUk+JrpqW1PB0PRo/7G rf7D5IZK8JZj0O0wGUKb0ivFQijiv+lNG/prBcxZ3P/qrkKmPAcBxPoWd8QgCAEHbTsK 7uXK6ZHZYNEHwUiGy0VewJCZmLYYD2QJQTYuVcyoJ0QKvBenUCa1v5lbXAMXdG4+SEjj /ObYWXX8D9YmyYfozAXEe4satXqnSHOFIfzNHZtYRqfBUefItdsQYmr/IM5OquTwfw5X r6C/aDXQr7y32jxCgNJdPDSwCfIcRkzJxO1UFSFMbuWyhMauQoEimwO95o4j0uCQF6Nb Dydg== X-Gm-Message-State: ALoCoQlOrKsvntQvToPLmNquec2P9pnUDPBOXHTtWDrgwzJi6iiMEM71o5UAFbsU4tvKo6GC0j8W MIME-Version: 1.0 X-Received: by 10.55.26.133 with SMTP id l5mr30686101qkh.40.1436516137576; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) Received: by 10.96.158.9 with HTTP; Fri, 10 Jul 2015 01:15:37 -0700 (PDT) In-Reply-To: References: Date: Fri, 10 Jul 2015 09:15:37 +0100 Message-ID: From: Phil Lello To: xen-users@lists.xen.org Subject: Re: [Xen-users] NFS root partition for DomU (xenpvnetboot) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1414724432340547084==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1414724432340547084== Content-Type: multipart/alternative; boundary=001a1145b642184acf051a80fab4 --001a1145b642184acf051a80fab4 Content-Type: text/plain; charset=UTF-8 And I've got it solved... I needed to explicitly set the NFS server in /etc/initramfs-tools/initramfs.conf. Once I get the xen console connected (ssh works, xl console just hangs after boot messages), I'll document on the Wiki for those that follow. Phil On Fri, Jul 10, 2015 at 8:20 AM, Phil Lello wrote: > Hi all, > > Following on from getting DHCP working for my DomU client, I'm now trying > to get a NFS mounted root filesystem. > > I'm using xenpvnetboot [1] since this seemed the correct approach from > internet searches - not sure if the author lurks on this list or not. > > My VM config looks like: > > memory = 1024 > > # Should be at least 2KB per MB of domain memory, plus a few MB per vcpu. > shadow_memory = 8 > name = "nfsboot" > vif = [ 'script=vif-bridge,mac=00:16:3e:00:00:01' ] > disk = [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ] > > #bootloader = "pygrub" > bootloader = "xenpvnetboot" > bootloader_args= [ '--location', 'nfs:192.168.1.1:/nfs/nfsboot-root' ] > #bootloader_args= [ '--location', '/nfs/nfsboot-root' ] > kernel = "vmlinuz" > ramdisk = "initrd.img" > > The kernel is booting, so I'm reasonably certain NFS is configured > correctly, but instead of getting the root partition mounted, I am spammed > with: > > Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... > done. > nfsmount: need a path > done. > > Looking at the console output, I'm wondering if I've missed a DHCP option > or two (it seems the NFS root isn't getting passed as I expected from the > bootloader - or maybe I need to tinker with the initrd.img): > > [ 1.483755] FS-Cache: Netfs 'nfs' registered for caching > IP-Config: eth0 hardware address 00:16:3e:00:00:01 mtu 1500 DHCP RARP > IP-Config: eth0 complete (dhcp from 192.168.1.1): > address: 192.168.1.176 broadcast: 192.168.1.255 netmask: > 255.255.255.0 > > gateway: 192.168.1.1 dns0 : 192.168.1.1 dns1 : > 0.0.0.0 > > rootserver: 192.168.1.1 rootpath: > filename : > Begin: Running /scripts/nfs-premount ... done. > nfsmount: need a path > Begin: Retrying nfs mount ... Begin: Running /scripts/nfs-premount ... > done. > nfsmount: need a path > done. > > Any help greatly appreciated. > > Phil > > [1] http://wiki.xenproject.org/wiki/Xenpvnetboot > --001a1145b642184acf051a80fab4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And I've got it solved... I needed to explic= itly set the NFS server in /etc/initramfs-tools/initramfs.conf.

Once I get the xen console connected (ssh works, xl console just hangs af= ter boot messages), I'll document on the Wiki for those that follow.

Phil

On Fri, Jul 10, 2015 at 8:20 AM, Phil Lello <<= a href=3D"mailto:phil@dunlop-lello.uk" target=3D"_blank">phil@dunlop-lello.= uk> wrote:
Hi all,

Following on from = getting DHCP working for my DomU client, I'm now trying to get a NFS mo= unted root filesystem.

I'm using xenpvnetboot [1] since th= is seemed the correct approach from internet searches - not sure if the aut= hor lurks on this list or not.

My VM config looks like:
memory =3D 1024

# Should be at least 2KB per MB of domain memory, p= lus a few MB per vcpu.
shadow_memory =3D 8
name =3D "nfsboot&quo= t;
vif =3D [ 'script=3Dvif-bridge,mac=3D00:16:3e:00:00:01' ]
= disk =3D [ 'file:/srv/xen/nfsboot/nfsboot.img,xvda,w' ]

#boo= tloader =3D "pygrub"
bootloader =3D "xenpvnetboot"bootloader_args=3D [ '--location', 'nfs:192.168.1.1:/nfs/nfsb= oot-root' ]
#bootloader_args=3D [ '--location', '/nfs/nf= sboot-root' ]
kernel =3D "vmlinuz"
ramdisk =3D "in= itrd.img"

The kernel is booting, so I'm reasonably ce= rtain NFS is configured correctly, but instead of getting the root partitio= n mounted, I am spammed with:

Begin: Retrying nfs mount ... Begin: R= unning /scripts/nfs-premount ... done.
nfsmount: need a path
done.
Looking at the console output, I'm wondering if I've mis= sed a DHCP option or two (it seems the NFS root isn't getting passed as= I expected from the bootloader - or maybe I need to tinker with the initrd= .img):

[=C2=A0=C2=A0=C2=A0 1.483755] FS-Cache: Netfs 'nfs' r= egistered for caching
IP-Config: eth0 hardware address 00:16:3e:00:00:01= mtu 1500 DHCP RARP
IP-Config: eth0 complete (dhcp from 192.168.1.1):=C2=A0address: 192.168.1.176=C2=A0=C2=A0=C2=A0 broadcast: 192.168.1.255=C2= =A0=C2=A0=C2=A0 netmask: 255.255.255.0=C2=A0=C2=A0

=C2=A0gateway: 1= 92.168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns0=C2=A0=C2=A0=C2=A0=C2=A0 : 192= .168.1.1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 dns1=C2=A0=C2=A0 : 0.0.0.0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0rootserver: 192.168.1= .1 rootpath:
=C2=A0filename=C2=A0 :
Begin: Running /scripts/nfs-pre= mount ... done.
nfsmount: need a path
Begin: Retrying nfs mount ... B= egin: Running /scripts/nfs-premount ... done.
nfsmount: need a path
d= one.

Any help greatly appreciated.

Phil

--001a1145b642184acf051a80fab4-- --===============1414724432340547084== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1414724432340547084==-- From xen-users-bounces@lists.xen.org Fri Jul 10 09:13:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 09:13:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUMK-0002Kh-H3; Fri, 10 Jul 2015 09:12:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUMJ-0002KZ-Kd for xen-users@lists.xen.org; Fri, 10 Jul 2015 09:12:39 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id B6/6B-30151-68C8F955; Fri, 10 Jul 2015 09:12:38 +0000 X-Env-Sender: prvs=626f2c6bc=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436519556!30943842!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30628 invoked from network); 10 Jul 2015 09:12:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 09:12:38 -0000 X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208";a="279818412" Message-ID: <1436519554.23508.183.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" Date: Fri, 10 Jul 2015 10:12:34 +0100 In-Reply-To: <559EB33C.8010800@rz-online.de> References: <559EB33C.8010800@rz-online.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 19:45 +0200, Manfred Haertel, DB3HM wrote: > I would like to use the Xen serial console, but on a computer which does > not have a serial device. > > So I have to use the so-called USB debugging port (console=dbgp). The > USB controller in my system seems to support this. > > But where do I find an USB cable to connect my computer to another one > via USB? > > Most documentations refer to a small device called NET20DC, to which you > can connect both computers via USB. Unfortunately, this device doesn't > seem to be available anymore. Indeed, a while back I searched long and hard for such a thing and didn't come up with anything, I concluded that they were either fictional, ancient and unavailable or something one needed to build for oneself with a soldering iron :-/ I just had another look and things seem more promising, the "Net chip USB debug link" in https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt remains dead but I found https://github.com/avivgr/teensy_debugdev and http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx Which lead me to google "usb debug cable" and find things such as: http://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html and a bunch of ones which don't look right (mostly extension cables or TTL/serial on one end). I have no idea if that datapro thing is actually the right thing, but it looks promising... > Is there another device, which is still available and is known to work? Depending on your platform it might have AMT or some other serial-over-LAN capability? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 09:13:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 09:13:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUMK-0002Kh-H3; Fri, 10 Jul 2015 09:12:40 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUMJ-0002KZ-Kd for xen-users@lists.xen.org; Fri, 10 Jul 2015 09:12:39 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id B6/6B-30151-68C8F955; Fri, 10 Jul 2015 09:12:38 +0000 X-Env-Sender: prvs=626f2c6bc=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436519556!30943842!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30628 invoked from network); 10 Jul 2015 09:12:38 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 09:12:38 -0000 X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208";a="279818412" Message-ID: <1436519554.23508.183.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" Date: Fri, 10 Jul 2015 10:12:34 +0100 In-Reply-To: <559EB33C.8010800@rz-online.de> References: <559EB33C.8010800@rz-online.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 19:45 +0200, Manfred Haertel, DB3HM wrote: > I would like to use the Xen serial console, but on a computer which does > not have a serial device. > > So I have to use the so-called USB debugging port (console=dbgp). The > USB controller in my system seems to support this. > > But where do I find an USB cable to connect my computer to another one > via USB? > > Most documentations refer to a small device called NET20DC, to which you > can connect both computers via USB. Unfortunately, this device doesn't > seem to be available anymore. Indeed, a while back I searched long and hard for such a thing and didn't come up with anything, I concluded that they were either fictional, ancient and unavailable or something one needed to build for oneself with a soldering iron :-/ I just had another look and things seem more promising, the "Net chip USB debug link" in https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt remains dead but I found https://github.com/avivgr/teensy_debugdev and http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx Which lead me to google "usb debug cable" and find things such as: http://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html and a bunch of ones which don't look right (mostly extension cables or TTL/serial on one end). I have no idea if that datapro thing is actually the right thing, but it looks promising... > Is there another device, which is still available and is known to work? Depending on your platform it might have AMT or some other serial-over-LAN capability? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 09:31:07 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 09:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUdy-0003Wm-B7; Fri, 10 Jul 2015 09:30:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUdw-0003W7-MC for xen-users@lists.xen.org; Fri, 10 Jul 2015 09:30:52 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 0A/1C-31304-BC09F955; Fri, 10 Jul 2015 09:30:51 +0000 X-Env-Sender: prvs=626f2c6bc=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1436520649!20269874!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5175 invoked from network); 10 Jul 2015 09:30:50 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 09:30:50 -0000 X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208";a="282893838" Message-ID: <1436520645.23508.193.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Fri, 10 Jul 2015 10:30:45 +0100 In-Reply-To: <559E90A7.7010809@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 11:17 -0400, Brandon Perez wrote: > Thanks, for the clarifications on my questions on interrupt/timer > code flow in Xen. That made it a lot clearer. I figured out what is > causing the bug, and it turned out to be one of the local changes I had > to Xen. Great, I'm glad you figured this out, it was really starting to stump me! > On the DRA72x device, there are a large number of peripheral > devices, more than can be handled by the SPI on the GIC. Therefore, > there's an internal mechanism that allows the routing of these > peripherals to the interrupt lines on the GIC. Right, this (secondary/chained interrupt controllers) is a quite common occurrence on ARM systems I think, but not one we've had to deal with until now. Assuming the devices behind this chained controller are not targets for passthrough then I think the solution is reasonably easy (at least architecturally), it just needs a small bit of infrastructure code and a small bit of per-controller code in Xen, matched on the DT compatibility-string of the nested controller (possibly the per-controller code might even be as small as _just_ the compat string in a list). Upon discovering such an chained interrupt-controller node in the DT all of the output SPIs should be routed to dom0 and all the associated MMIO ranges should be mapped to dom0 etc etc (perhaps the new dt_for_each_range and/or dt_for_each_irq_map functions would help here). Upon discovering a device whose interrupt-parent is one of these chained interrupt controllers (or anything not the root GIC really) then it's own interrupt property can just be passed through unchanged without mapping anything. Now dom0 can prod this new controller to its hearts content and the resulting SPIs will be correctly routed to dom0. If they are targets for passthrough then something more complex would be needed, involving quite a bit more code on the Xen side, I expect. I've not considered this case very deeply. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 09:31:07 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 09:31:07 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUdy-0003Wm-B7; Fri, 10 Jul 2015 09:30:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDUdw-0003W7-MC for xen-users@lists.xen.org; Fri, 10 Jul 2015 09:30:52 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 0A/1C-31304-BC09F955; Fri, 10 Jul 2015 09:30:51 +0000 X-Env-Sender: prvs=626f2c6bc=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1436520649!20269874!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5175 invoked from network); 10 Jul 2015 09:30:50 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 10 Jul 2015 09:30:50 -0000 X-IronPort-AV: E=Sophos;i="5.15,446,1432598400"; d="scan'208";a="282893838" Message-ID: <1436520645.23508.193.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Fri, 10 Jul 2015 10:30:45 +0100 In-Reply-To: <559E90A7.7010809@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-09 at 11:17 -0400, Brandon Perez wrote: > Thanks, for the clarifications on my questions on interrupt/timer > code flow in Xen. That made it a lot clearer. I figured out what is > causing the bug, and it turned out to be one of the local changes I had > to Xen. Great, I'm glad you figured this out, it was really starting to stump me! > On the DRA72x device, there are a large number of peripheral > devices, more than can be handled by the SPI on the GIC. Therefore, > there's an internal mechanism that allows the routing of these > peripherals to the interrupt lines on the GIC. Right, this (secondary/chained interrupt controllers) is a quite common occurrence on ARM systems I think, but not one we've had to deal with until now. Assuming the devices behind this chained controller are not targets for passthrough then I think the solution is reasonably easy (at least architecturally), it just needs a small bit of infrastructure code and a small bit of per-controller code in Xen, matched on the DT compatibility-string of the nested controller (possibly the per-controller code might even be as small as _just_ the compat string in a list). Upon discovering such an chained interrupt-controller node in the DT all of the output SPIs should be routed to dom0 and all the associated MMIO ranges should be mapped to dom0 etc etc (perhaps the new dt_for_each_range and/or dt_for_each_irq_map functions would help here). Upon discovering a device whose interrupt-parent is one of these chained interrupt controllers (or anything not the root GIC really) then it's own interrupt property can just be passed through unchanged without mapping anything. Now dom0 can prod this new controller to its hearts content and the resulting SPIs will be correctly routed to dom0. If they are targets for passthrough then something more complex would be needed, involving quite a bit more code on the Xen side, I expect. I've not considered this case very deeply. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 16:22:39 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 16:22:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDb3S-0007su-OE; Fri, 10 Jul 2015 16:21:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDb3R-0007sk-0c for xen-users@lists.xen.org; Fri, 10 Jul 2015 16:21:37 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 06/80-32733-011FF955; Fri, 10 Jul 2015 16:21:36 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436545294!31079920!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9118 invoked from network); 10 Jul 2015 16:21:35 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jul 2015 16:21:35 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6AGLUlU023065; Fri, 10 Jul 2015 11:21:30 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6AGLU50028352; Fri, 10 Jul 2015 11:21:30 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Fri, 10 Jul 2015 11:21:12 -0500 Message-ID: <559FE2FE.8050608@ti.com> Date: Fri, 10 Jul 2015 11:21:34 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> In-Reply-To: <1436520645.23508.193.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/10/2015 05:30 AM, Ian Campbell wrote: > > Great, I'm glad you figured this out, it was really starting to stump > me! > > > Right, this (secondary/chained interrupt controllers) is a quite common > occurrence on ARM systems I think, but not one we've had to deal with > until now. > > Assuming the devices behind this chained controller are not targets for > passthrough then I think the solution is reasonably easy (at least > architecturally), it just needs a small bit of infrastructure code and a > small bit of per-controller code in Xen, matched on the DT > compatibility-string of the nested controller (possibly the > per-controller code might even be as small as _just_ the compat string > in a list). > > Upon discovering such an chained interrupt-controller node in the DT all > of the output SPIs should be routed to dom0 and all the associated MMIO > ranges should be mapped to dom0 etc etc (perhaps the new > dt_for_each_range and/or dt_for_each_irq_map functions would help here). > > Upon discovering a device whose interrupt-parent is one of these chained > interrupt controllers (or anything not the root GIC really) then it's > own interrupt property can just be passed through unchanged without > mapping anything. > > Now dom0 can prod this new controller to its hearts content and the > resulting SPIs will be correctly routed to dom0. > Yes, this makes sense. I'm working on modifying my device tree to get this working now. > If they are targets for passthrough then something more complex would be > needed, involving quite a bit more code on the Xen side, I expect. I've > not considered this case very deeply. > > Ian. > I think, at least based on my current understanding of the Xen code, there's no real mechanism to do this as of yet. The guest is not capable of redefining an IRQ. At least in the short term, you could require that any interrupts which are passthrough be statically mapped (e.g. the mapping is set up by the bootloader, or the default is used). Then, Xen would need to be aware of the true IRQ number, and the kernel would have to take care to not remap this IRQ. The former can be accomlished with an additional property in the device tree, and the functionality for the latter already exists, at least for OMAP devices, where the interrupt is marked as "reserved". The other case to consider is when Xen requires an interrupt that is an SPI. The only case I've seen so far is the serial interrupt, which is controlled by Xen. For now, I'm adding a property to the UART device tree node that informs Xen of what the true IRQ number is. For now, the default mapping is used, and the Dom0 kernel makes sure not to override this mapping. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 10 16:22:39 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 10 Jul 2015 16:22:39 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDb3S-0007su-OE; Fri, 10 Jul 2015 16:21:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZDb3R-0007sk-0c for xen-users@lists.xen.org; Fri, 10 Jul 2015 16:21:37 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 06/80-32733-011FF955; Fri, 10 Jul 2015 16:21:36 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1436545294!31079920!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9118 invoked from network); 10 Jul 2015 16:21:35 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-8.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jul 2015 16:21:35 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6AGLUlU023065; Fri, 10 Jul 2015 11:21:30 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6AGLU50028352; Fri, 10 Jul 2015 11:21:30 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Fri, 10 Jul 2015 11:21:12 -0500 Message-ID: <559FE2FE.8050608@ti.com> Date: Fri, 10 Jul 2015 11:21:34 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> In-Reply-To: <1436520645.23508.193.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/10/2015 05:30 AM, Ian Campbell wrote: > > Great, I'm glad you figured this out, it was really starting to stump > me! > > > Right, this (secondary/chained interrupt controllers) is a quite common > occurrence on ARM systems I think, but not one we've had to deal with > until now. > > Assuming the devices behind this chained controller are not targets for > passthrough then I think the solution is reasonably easy (at least > architecturally), it just needs a small bit of infrastructure code and a > small bit of per-controller code in Xen, matched on the DT > compatibility-string of the nested controller (possibly the > per-controller code might even be as small as _just_ the compat string > in a list). > > Upon discovering such an chained interrupt-controller node in the DT all > of the output SPIs should be routed to dom0 and all the associated MMIO > ranges should be mapped to dom0 etc etc (perhaps the new > dt_for_each_range and/or dt_for_each_irq_map functions would help here). > > Upon discovering a device whose interrupt-parent is one of these chained > interrupt controllers (or anything not the root GIC really) then it's > own interrupt property can just be passed through unchanged without > mapping anything. > > Now dom0 can prod this new controller to its hearts content and the > resulting SPIs will be correctly routed to dom0. > Yes, this makes sense. I'm working on modifying my device tree to get this working now. > If they are targets for passthrough then something more complex would be > needed, involving quite a bit more code on the Xen side, I expect. I've > not considered this case very deeply. > > Ian. > I think, at least based on my current understanding of the Xen code, there's no real mechanism to do this as of yet. The guest is not capable of redefining an IRQ. At least in the short term, you could require that any interrupts which are passthrough be statically mapped (e.g. the mapping is set up by the bootloader, or the default is used). Then, Xen would need to be aware of the true IRQ number, and the kernel would have to take care to not remap this IRQ. The former can be accomlished with an additional property in the device tree, and the functionality for the latter already exists, at least for OMAP devices, where the interrupt is marked as "reserved". The other case to consider is when Xen requires an interrupt that is an SPI. The only case I've seen so far is the serial interrupt, which is controlled by Xen. For now, I'm adding a property to the UART device tree node that informs Xen of what the true IRQ number is. For now, the default mapping is used, and the Dom0 kernel makes sure not to override this mapping. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Jul 12 13:32:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 12 Jul 2015 13:32:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEHLr-0000Bi-3B; Sun, 12 Jul 2015 13:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEHLp-0000Bd-J2 for xen-users@lists.xen.org; Sun, 12 Jul 2015 13:31:25 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 4B/AF-19853-C2C62A55; Sun, 12 Jul 2015 13:31:24 +0000 X-Env-Sender: hbc1024@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1436707876!20587301!1 X-Originating-IP: [209.85.212.196] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23925 invoked from network); 12 Jul 2015 13:31:16 -0000 Received: from mail-wi0-f196.google.com (HELO mail-wi0-f196.google.com) (209.85.212.196) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Jul 2015 13:31:16 -0000 Received: by wipp2 with SMTP id p2so5980840wip.2 for ; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rXl1MKnI+IEqrOuwKsf7m3hclwOKN0QXQelbUBMBPCM=; b=X2HfIbykI1K2jacry6xeHSggxm14ZBQAu+h1F+K77ObIcTTx+N29BcwcWy+c1gz+UY nuNe539j6tV8nj7C4D+MjARc9Z/0dBKWMFcSOIFMWirq9M6FCK6rFTO6cy2emzDV4WzD g07qEDGxvPKRlxl+ET7yYRtFmVXmtwPIdggHxq7UAIDhLrJekHP7WlXKj50JsBQ+wNGL KuNTBOIDeYze/DtdaxtxW6+xghBGDf95EDVzMWHCV+BH5MTRLvmoJI83VAc+xqxZs/1h tj+1z/ZDUnmxvOZwYs8i2Vth9GwVqrosZBFbtutUlxlnCRG9bvxpYFQzEwCMJElxB1fy CLWw== MIME-Version: 1.0 X-Received: by 10.194.200.194 with SMTP id ju2mr56569275wjc.61.1436707876307; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) Received: by 10.28.101.69 with HTTP; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) Date: Sun, 12 Jul 2015 21:31:16 +0800 Message-ID: From: H C To: xen-users@lists.xen.org Subject: [Xen-users] xl save X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I'm running xen 4.4.1 on arch linux and I'm not having any luck with saving an arch PV guest. Does the guest OS have to support suspending? I suspect it does but would like to confirm before I go down the path of setting it up. When I execute xl save with the domain name I don't get any error messages. The restore fails, however. Its odd because when I ran xl save with the domain id (instead of the name), it did fail during the save with a complaint about the guest not suspending. [ssh log below] I googled around for some of the text in the error messages and did not find anything useful. The closest I came was this former mail list conversation(http://lists.xen.org/archives/html/xen-devel/2014-03/msg01647.html), however, it seems to be about HVM so I'm not sure it is related to my issue. And this one but it is old: http://xen.crc.id.au/bugs/print_bug_page.php?bug_id=7 Thanks in advance. [root@earth ~]# xl save arch2 /vms/arch2/save Saving to /vms/arch2/save new xl format (info 0x0/0x0/226) xc: Saving memory: iter 0 (last sent 0 skipped 0): 134217728/134217728 100% -------- [root@earth arch2]# xl restore /vms/arch2/save Loading new save file /vms/arch2/save (new xl fmt info 0x0/0x0/226) Savefile contains xl domain config Parsing config from libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated reading ipc msg header from domain 19 save/restore helper stdout pipe libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 19 save/restore helper [-1] died due to fatal signal Killed libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3 -------- [root@earth arch2]# xl restore /vms/arch2/arch2.c /vms/arch2/save Loading new save file /vms/arch2/save (new xl fmt info 0x0/0x0/226) Savefile contains xl domain config Parsing config from /vms/arch2/arch2.c libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated reading ipc msg header from domain 20 save/restore helper stdout pipe libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 20 save/restore helper [-1] died due to fatal signal Killed libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3 ---------------------------------------------- [root@earth new]# xl save 26 /vms/arch2/save Saving to /vms/arch2/save new xl format (info 0x0/0x0/226) libxl: error: libxl_dom.c:1099:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, cancelling request libxl: error: libxl_dom.c:1121:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, request cancelled xc: error: Suspend request failed: Internal error xc: error: Domain appears not to have suspended: Internal error libxl: error: libxl_dom.c:1406:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: Success Failed to save domain, resuming domain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sun Jul 12 13:32:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sun, 12 Jul 2015 13:32:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEHLr-0000Bi-3B; Sun, 12 Jul 2015 13:31:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEHLp-0000Bd-J2 for xen-users@lists.xen.org; Sun, 12 Jul 2015 13:31:25 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 4B/AF-19853-C2C62A55; Sun, 12 Jul 2015 13:31:24 +0000 X-Env-Sender: hbc1024@gmail.com X-Msg-Ref: server-4.tower-206.messagelabs.com!1436707876!20587301!1 X-Originating-IP: [209.85.212.196] X-SpamReason: No, hits=0.3 required=7.0 tests=ML_RADAR_SPEW_LINKS_8, RCVD_BY_IP,spamassassin: ,async_handler: YXN5bmNfZGVsYXk6IDAgKHRpbWVvdXQp\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23925 invoked from network); 12 Jul 2015 13:31:16 -0000 Received: from mail-wi0-f196.google.com (HELO mail-wi0-f196.google.com) (209.85.212.196) by server-4.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 12 Jul 2015 13:31:16 -0000 Received: by wipp2 with SMTP id p2so5980840wip.2 for ; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rXl1MKnI+IEqrOuwKsf7m3hclwOKN0QXQelbUBMBPCM=; b=X2HfIbykI1K2jacry6xeHSggxm14ZBQAu+h1F+K77ObIcTTx+N29BcwcWy+c1gz+UY nuNe539j6tV8nj7C4D+MjARc9Z/0dBKWMFcSOIFMWirq9M6FCK6rFTO6cy2emzDV4WzD g07qEDGxvPKRlxl+ET7yYRtFmVXmtwPIdggHxq7UAIDhLrJekHP7WlXKj50JsBQ+wNGL KuNTBOIDeYze/DtdaxtxW6+xghBGDf95EDVzMWHCV+BH5MTRLvmoJI83VAc+xqxZs/1h tj+1z/ZDUnmxvOZwYs8i2Vth9GwVqrosZBFbtutUlxlnCRG9bvxpYFQzEwCMJElxB1fy CLWw== MIME-Version: 1.0 X-Received: by 10.194.200.194 with SMTP id ju2mr56569275wjc.61.1436707876307; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) Received: by 10.28.101.69 with HTTP; Sun, 12 Jul 2015 06:31:16 -0700 (PDT) Date: Sun, 12 Jul 2015 21:31:16 +0800 Message-ID: From: H C To: xen-users@lists.xen.org Subject: [Xen-users] xl save X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I'm running xen 4.4.1 on arch linux and I'm not having any luck with saving an arch PV guest. Does the guest OS have to support suspending? I suspect it does but would like to confirm before I go down the path of setting it up. When I execute xl save with the domain name I don't get any error messages. The restore fails, however. Its odd because when I ran xl save with the domain id (instead of the name), it did fail during the save with a complaint about the guest not suspending. [ssh log below] I googled around for some of the text in the error messages and did not find anything useful. The closest I came was this former mail list conversation(http://lists.xen.org/archives/html/xen-devel/2014-03/msg01647.html), however, it seems to be about HVM so I'm not sure it is related to my issue. And this one but it is old: http://xen.crc.id.au/bugs/print_bug_page.php?bug_id=7 Thanks in advance. [root@earth ~]# xl save arch2 /vms/arch2/save Saving to /vms/arch2/save new xl format (info 0x0/0x0/226) xc: Saving memory: iter 0 (last sent 0 skipped 0): 134217728/134217728 100% -------- [root@earth arch2]# xl restore /vms/arch2/save Loading new save file /vms/arch2/save (new xl fmt info 0x0/0x0/226) Savefile contains xl domain config Parsing config from libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated reading ipc msg header from domain 19 save/restore helper stdout pipe libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 19 save/restore helper [-1] died due to fatal signal Killed libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3 -------- [root@earth arch2]# xl restore /vms/arch2/arch2.c /vms/arch2/save Loading new save file /vms/arch2/save (new xl fmt info 0x0/0x0/226) Savefile contains xl domain config Parsing config from /vms/arch2/arch2.c libxl: error: libxl_utils.c:396:libxl_read_exactly: file/stream truncated reading ipc msg header from domain 20 save/restore helper stdout pipe libxl: error: libxl_exec.c:129:libxl_report_child_exitstatus: domain 20 save/restore helper [-1] died due to fatal signal Killed libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3 ---------------------------------------------- [root@earth new]# xl save 26 /vms/arch2/save Saving to /vms/arch2/save new xl format (info 0x0/0x0/226) libxl: error: libxl_dom.c:1099:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, cancelling request libxl: error: libxl_dom.c:1121:libxl__domain_suspend_common_callback: guest didn't acknowledge suspend, request cancelled xc: error: Suspend request failed: Internal error xc: error: Domain appears not to have suspended: Internal error libxl: error: libxl_dom.c:1406:libxl__xc_domain_save_done: saving domain: domain did not respond to suspend request: Success Failed to save domain, resuming domain _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 08:30:55 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 08:30:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZ7S-0007mV-3W; Mon, 13 Jul 2015 08:29:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZ7Q-0007mQ-IH for xen-users@lists.xen.org; Mon, 13 Jul 2015 08:29:44 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 53/40-19654-7F673A55; Mon, 13 Jul 2015 08:29:43 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1436776181!17800861!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22520 invoked from network); 13 Jul 2015 08:29:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 08:29:43 -0000 X-IronPort-AV: E=Sophos;i="5.15,461,1432598400"; d="scan'208";a="280358172" Message-ID: <1436776174.7019.25.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Mon, 13 Jul 2015 09:29:34 +0100 In-Reply-To: <559FE2FE.8050608@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > If they are targets for passthrough then something more complex would be > > needed, involving quite a bit more code on the Xen side, I expect. I've > > not considered this case very deeply. > > > > Ian. > > > > I think, at least based on my current understanding of the Xen > code, there's no real mechanism to do this as of yet. The guest is not > capable of redefining an IRQ. At least in the short term, you could > require that any interrupts which are passthrough be statically mapped > (e.g. the mapping is set up by the bootloader, or the default is used). > Then, Xen would need to be aware of the true IRQ number, and the kernel > would have to take care to not remap this IRQ. The former can be > accomlished with an additional property in the device tree, and the > functionality for the latter already exists, at least for OMAP devices, > where the interrupt is marked as "reserved". Is there a 1:1 mapping between (active) interrupts handled by this cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 SPIs would you only be able to use 16 of the devices? Or does it support multiple interrupt sources triggering a single SPI? > The other case to consider is when Xen requires an interrupt that is > an SPI. The only case I've seen so far is the serial interrupt, which is > controlled by Xen. For now, I'm adding a property to the UART device > tree node that informs Xen of what the true IRQ number is. For now, the > default mapping is used, and the Dom0 kernel makes sure not to override > this mapping. Right, this is a tricky one. Other than various solutions involving trusting the firmware to get it right and requiring dom0 to not muck around with it the only other solution I can think of would be a bit of code in Xen which traps dom0's attempted changes and validates them, preventing dom0 from mucking with the ones Xen cares about. Given how simple these sorts of interrupt remappers often are that might not even be that much code. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 08:30:55 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 08:30:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZ7S-0007mV-3W; Mon, 13 Jul 2015 08:29:46 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZ7Q-0007mQ-IH for xen-users@lists.xen.org; Mon, 13 Jul 2015 08:29:44 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 53/40-19654-7F673A55; Mon, 13 Jul 2015 08:29:43 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1436776181!17800861!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22520 invoked from network); 13 Jul 2015 08:29:43 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 08:29:43 -0000 X-IronPort-AV: E=Sophos;i="5.15,461,1432598400"; d="scan'208";a="280358172" Message-ID: <1436776174.7019.25.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Mon, 13 Jul 2015 09:29:34 +0100 In-Reply-To: <559FE2FE.8050608@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > If they are targets for passthrough then something more complex would be > > needed, involving quite a bit more code on the Xen side, I expect. I've > > not considered this case very deeply. > > > > Ian. > > > > I think, at least based on my current understanding of the Xen > code, there's no real mechanism to do this as of yet. The guest is not > capable of redefining an IRQ. At least in the short term, you could > require that any interrupts which are passthrough be statically mapped > (e.g. the mapping is set up by the bootloader, or the default is used). > Then, Xen would need to be aware of the true IRQ number, and the kernel > would have to take care to not remap this IRQ. The former can be > accomlished with an additional property in the device tree, and the > functionality for the latter already exists, at least for OMAP devices, > where the interrupt is marked as "reserved". Is there a 1:1 mapping between (active) interrupts handled by this cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 SPIs would you only be able to use 16 of the devices? Or does it support multiple interrupt sources triggering a single SPI? > The other case to consider is when Xen requires an interrupt that is > an SPI. The only case I've seen so far is the serial interrupt, which is > controlled by Xen. For now, I'm adding a property to the UART device > tree node that informs Xen of what the true IRQ number is. For now, the > default mapping is used, and the Dom0 kernel makes sure not to override > this mapping. Right, this is a tricky one. Other than various solutions involving trusting the firmware to get it right and requiring dom0 to not muck around with it the only other solution I can think of would be a bit of code in Xen which traps dom0's attempted changes and validates them, preventing dom0 from mucking with the ones Xen cares about. Given how simple these sorts of interrupt remappers often are that might not even be that much code. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 08:41:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 08:41:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZIK-0008Lm-5n; Mon, 13 Jul 2015 08:41:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZII-0008Le-TX for xen-users@lists.xen.org; Mon, 13 Jul 2015 08:40:59 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 26/F5-17050-A9973A55; Mon, 13 Jul 2015 08:40:58 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436776854!25218394!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28548 invoked from network); 13 Jul 2015 08:40:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 08:40:55 -0000 X-IronPort-AV: E=Sophos;i="5.15,461,1432598400"; d="scan'208";a="283457375" Message-ID: <1436776852.7019.26.camel@citrix.com> From: Ian Campbell To: H C Date: Mon, 13 Jul 2015 09:40:52 +0100 In-Reply-To: References: Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl save X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sun, 2015-07-12 at 21:31 +0800, H C wrote: > I'm running xen 4.4.1 on arch linux and I'm not having any luck with > saving an arch PV guest. > > Does the guest OS have to support suspending? For a PV guest, yes it does. I can't remember the exact kernel options but IIRC they are basically the same ones as support suspend/resume and hibernate for native systems. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 08:41:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 08:41:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZIK-0008Lm-5n; Mon, 13 Jul 2015 08:41:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEZII-0008Le-TX for xen-users@lists.xen.org; Mon, 13 Jul 2015 08:40:59 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 26/F5-17050-A9973A55; Mon, 13 Jul 2015 08:40:58 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436776854!25218394!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28548 invoked from network); 13 Jul 2015 08:40:55 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 08:40:55 -0000 X-IronPort-AV: E=Sophos;i="5.15,461,1432598400"; d="scan'208";a="283457375" Message-ID: <1436776852.7019.26.camel@citrix.com> From: Ian Campbell To: H C Date: Mon, 13 Jul 2015 09:40:52 +0100 In-Reply-To: References: Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] xl save X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sun, 2015-07-12 at 21:31 +0800, H C wrote: > I'm running xen 4.4.1 on arch linux and I'm not having any luck with > saving an arch PV guest. > > Does the guest OS have to support suspending? For a PV guest, yes it does. I can't remember the exact kernel options but IIRC they are basically the same ones as support suspend/resume and hibernate for native systems. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 13:34:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 13:34:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEdrk-0004vV-F0; Mon, 13 Jul 2015 13:33:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEdrj-0004vN-5A for xen-users@lists.xen.org; Mon, 13 Jul 2015 13:33:51 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id F8/F9-23832-E3EB3A55; Mon, 13 Jul 2015 13:33:50 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436794424!25343949!1 X-Originating-IP: [192.94.94.40] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQwID0+IDE3MDg0MQ==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26131 invoked from network); 13 Jul 2015 13:33:45 -0000 Received: from arroyo.ext.ti.com (HELO arroyo.ext.ti.com) (192.94.94.40) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jul 2015 13:33:45 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6DDXfK4011827; Mon, 13 Jul 2015 08:33:41 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6DDXftK007923; Mon, 13 Jul 2015 08:33:41 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 13 Jul 2015 08:33:20 -0500 Message-ID: <55A3B02E.7050206@ti.com> Date: Mon, 13 Jul 2015 08:33:50 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> In-Reply-To: <1436776174.7019.25.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/13/2015 04:29 AM, Ian Campbell wrote: > On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > Is there a 1:1 mapping between (active) interrupts handled by this > cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > SPIs would you only be able to use 16 of the devices? > > Or does it support multiple interrupt sources triggering a single SPI? For the chip I'm working with, it only supports a 1:1 mapping. It doesn't allow for multiple interrupts to share an SPI line. > > > Right, this is a tricky one. Other than various solutions involving > trusting the firmware to get it right and requiring dom0 to not muck > around with it the only other solution I can think of would be a bit of > code in Xen which traps dom0's attempted changes and validates them, > preventing dom0 from mucking with the ones Xen cares about. > > Given how simple these sorts of interrupt remappers often are that might > not even be that much code. > > Ian. > I think that wouldn't be too difficult to do, but for now, I'm going to stick with using the device tree to inform Xen and the Kernel. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 13:34:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 13:34:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEdrk-0004vV-F0; Mon, 13 Jul 2015 13:33:52 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEdrj-0004vN-5A for xen-users@lists.xen.org; Mon, 13 Jul 2015 13:33:51 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id F8/F9-23832-E3EB3A55; Mon, 13 Jul 2015 13:33:50 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1436794424!25343949!1 X-Originating-IP: [192.94.94.40] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTkyLjk0Ljk0LjQwID0+IDE3MDg0MQ==\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26131 invoked from network); 13 Jul 2015 13:33:45 -0000 Received: from arroyo.ext.ti.com (HELO arroyo.ext.ti.com) (192.94.94.40) by server-3.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Jul 2015 13:33:45 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6DDXfK4011827; Mon, 13 Jul 2015 08:33:41 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6DDXftK007923; Mon, 13 Jul 2015 08:33:41 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 13 Jul 2015 08:33:20 -0500 Message-ID: <55A3B02E.7050206@ti.com> Date: Mon, 13 Jul 2015 08:33:50 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> In-Reply-To: <1436776174.7019.25.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/13/2015 04:29 AM, Ian Campbell wrote: > On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > Is there a 1:1 mapping between (active) interrupts handled by this > cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > SPIs would you only be able to use 16 of the devices? > > Or does it support multiple interrupt sources triggering a single SPI? For the chip I'm working with, it only supports a 1:1 mapping. It doesn't allow for multiple interrupts to share an SPI line. > > > Right, this is a tricky one. Other than various solutions involving > trusting the firmware to get it right and requiring dom0 to not muck > around with it the only other solution I can think of would be a bit of > code in Xen which traps dom0's attempted changes and validates them, > preventing dom0 from mucking with the ones Xen cares about. > > Given how simple these sorts of interrupt remappers often are that might > not even be that much code. > > Ian. > I think that wouldn't be too difficult to do, but for now, I'm going to stick with using the device tree to inform Xen and the Kernel. Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 15:20:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 15:20:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfWB-0003Lx-19; Mon, 13 Jul 2015 15:19:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfWA-0003Ls-BK for xen-users@lists.xen.org; Mon, 13 Jul 2015 15:19:42 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id DD/E9-15011-D07D3A55; Mon, 13 Jul 2015 15:19:41 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-3.tower-206.messagelabs.com!1436800780!13233354!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28212 invoked from network); 13 Jul 2015 15:19:41 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 15:19:41 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEfW8-0004Sy-Ms for xen-users@lists.xen.org; Mon, 13 Jul 2015 17:19:40 +0200 Message-ID: <55A3D70C.2040602@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 17:19:40 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, how do I boot anything to get a VM started and installed? I tried a windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No matter what I try, I keep getting messages that no kernel can be found and that the VM cannot be created. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 15:20:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 15:20:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfWB-0003Lx-19; Mon, 13 Jul 2015 15:19:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfWA-0003Ls-BK for xen-users@lists.xen.org; Mon, 13 Jul 2015 15:19:42 +0000 Received: from [85.158.139.211] by server-9.bemta-5.messagelabs.com id DD/E9-15011-D07D3A55; Mon, 13 Jul 2015 15:19:41 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-3.tower-206.messagelabs.com!1436800780!13233354!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28212 invoked from network); 13 Jul 2015 15:19:41 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-3.tower-206.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 15:19:41 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEfW8-0004Sy-Ms for xen-users@lists.xen.org; Mon, 13 Jul 2015 17:19:40 +0200 Message-ID: <55A3D70C.2040602@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 17:19:40 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org Subject: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, how do I boot anything to get a VM started and installed? I tried a windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No matter what I try, I keep getting messages that no kernel can be found and that the VM cannot be created. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 15:49:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 15:49:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfz1-0005bx-VF; Mon, 13 Jul 2015 15:49:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfz0-0005bp-76 for xen-users@lists.xen.org; Mon, 13 Jul 2015 15:49:30 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id E9/BF-18733-90ED3A55; Mon, 13 Jul 2015 15:49:29 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436802556!31643451!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28031 invoked from network); 13 Jul 2015 15:49:17 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 15:49:17 -0000 X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="283587880" Message-ID: <1436802496.25044.13.camel@citrix.com> From: Ian Campbell To: hw Date: Mon, 13 Jul 2015 16:48:16 +0100 In-Reply-To: <55A3D70C.2040602@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 17:19 +0200, hw wrote: > Hi, > > how do I boot anything to get a VM started and installed? I tried a > windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No > matter what I try, I keep getting messages that no kernel can be found > and that the VM cannot be created. Without any logs or even a config file I'm just guessing, but it sounds like you are wanting to create an HVM guest but are actually creating a PV one. The main difference is the use of builder = "hvm" in your cfg file. xl.cfg(5) has details and xlexample.hvm (normally installed to /etc/xen) an example. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 15:49:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 15:49:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfz1-0005bx-VF; Mon, 13 Jul 2015 15:49:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEfz0-0005bp-76 for xen-users@lists.xen.org; Mon, 13 Jul 2015 15:49:30 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id E9/BF-18733-90ED3A55; Mon, 13 Jul 2015 15:49:29 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436802556!31643451!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28031 invoked from network); 13 Jul 2015 15:49:17 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 15:49:17 -0000 X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="283587880" Message-ID: <1436802496.25044.13.camel@citrix.com> From: Ian Campbell To: hw Date: Mon, 13 Jul 2015 16:48:16 +0100 In-Reply-To: <55A3D70C.2040602@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 17:19 +0200, hw wrote: > Hi, > > how do I boot anything to get a VM started and installed? I tried a > windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No > matter what I try, I keep getting messages that no kernel can be found > and that the VM cannot be created. Without any logs or even a config file I'm just guessing, but it sounds like you are wanting to create an HVM guest but are actually creating a PV one. The main difference is the use of builder = "hvm" in your cfg file. xl.cfg(5) has details and xlexample.hvm (normally installed to /etc/xen) an example. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 16:01:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 16:01:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgAd-0007Zf-OV; Mon, 13 Jul 2015 16:01:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgAb-0007Za-EI for xen-users@lists.xen.org; Mon, 13 Jul 2015 16:01:29 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id E4/8B-23832-8D0E3A55; Mon, 13 Jul 2015 16:01:28 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-6.tower-31.messagelabs.com!1436803287!20928065!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=1.2 required=7.0 tests=HOT_NASTY X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4957 invoked from network); 13 Jul 2015 16:01:28 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-6.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 16:01:28 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEgAX-0004W2-M2; Mon, 13 Jul 2015 18:01:25 +0200 Message-ID: <55A3E0D5.8010501@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 18:01:25 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Ian Campbell References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> In-Reply-To: <1436802496.25044.13.camel@citrix.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 13.07.2015 um 17:48 schrieb Ian Campbell: > On Mon, 2015-07-13 at 17:19 +0200, hw wrote: >> Hi, >> >> how do I boot anything to get a VM started and installed? I tried a >> windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No >> matter what I try, I keep getting messages that no kernel can be found >> and that the VM cannot be created. > > Without any logs or even a config file I'm just guessing, but it sounds > like you are wanting to create an HVM guest but are actually creating a > PV one. > > The main difference is the use of > builder = "hvm" > in your cfg file. xl.cfg(5) has details and xlexample.hvm (normally > installed to /etc/xen) an example. Yes, I have that. The config is: # This configures an HVM rather than PV guest builder = "hvm" device_model_version="qemu-xen" #device_model_override="/usr/bin/qemu-img-xen" # Guest name name = "ws-01" # 128-bit UUID for the domain as a hexadecimal number. # Use "uuidgen" to generate one if required. # The default behavior is to generate a new UUID each time the guest is started. #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" # Enable Microsoft Hyper-V compatibile paravirtualisation / # enlightenment interfaces. Turning this on can improve Windows guest # performance and is therefore recommended viridian = 1 # Initial memory allocation (MB) memory = 4096 # Maximum memory (MB) # If this is greater than `memory' then the slack will start ballooned # (this assumes guest kernel support for ballooning) #maxmem = 512 # Number of VCPUS vcpus = 2 # Network devices # A list of 'vifspec' entries as described in # docs/misc/xl-network-configuration.markdown vif = [ 'bridge=brloc' ] # Disk Devices # A list of `diskspec' entries as described in # docs/misc/xl-disk-configuration.txt disk = [ 'phy:/dev/sde1,hda,w', 'file:/root/installers/de_windows_7_professional_with_sp1_x64_dvd_u_676919.iso,hdc:cdrom,r' ] boot="dc" # Guest VGA console configuration, either SDL or VNC sdl = 0 vnc = 1 And I'm only getting: Parsing config from /etc/xen/ws-01.hvm libxl: debug: libxl_create.c:1504:do_domain_create: ao 0x250e350: create: how=(nil) callback=(nil) poller=0x250e3b0 libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk libxl: debug: libxl_create.c:907:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:629:libxl__ev_xswatch_deregister: watch w=0x250ec80: deregister unregistered libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=26, free_memkb=9875 libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=26, free_memkb=10311 libxl: detail: libxl_dom.c:196:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 10311 KB free selected libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: base group enabled libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: freq group enabled libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: time_ref_count group enabled xc: error: Could not open kernel image (2 = No such file or directory): Internal error libxl: error: libxl_dom.c:818:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1595:kill_device_model: unable to find device model pid in /local/domain/35/image/device-model-pid libxl: error: libxl.c:1608:libxl__destroy_domid: libxl__destroy_device_model failed for 35 libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 5250 for destroy of domain 35 libxl: debug: libxl_create.c:1520:do_domain_create: ao 0x250e350: inprogress: poller=0x250e3b0, flags=i libxl: debug: libxl_event.c:1765:libxl__ao_complete: ao 0x250e350: complete, rc=-3 libxl: debug: libxl_event.c:1737:libxl__ao__destroy: ao 0x250e350: destroy xc: debug: hypercall buffer: total allocations:197 total releases:197 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:182 misses:4 toobig:11 So I thought I'd try to make a PV guest with Gentoo ISO and found that nothing can be booted: Parsing config from /etc/xen/test.pvlinux libxl: debug: libxl_create.c:1504:do_domain_create: ao 0x2454c30: create: how=(nil) callback=(nil) poller=0x2455410 libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=xvda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=xvda, using backend qdisk libxl: debug: libxl_create.c:907:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:329:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:629:libxl__ev_xswatch_deregister: watch w=0x2455ca0: deregister unregistered libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=36, free_memkb=9875 libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=36, free_memkb=10312 libxl: detail: libxl_dom.c:196:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 10312 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/ram0 init=/linuxrc aufs looptype=squashfs loop=/image.squashfs cdroot", features="(null)" libxl: debug: libxl_dom.c:533:libxl__build_pv: pv kernel mapped 0 path /isolinux/gentoo domainbuilder: detail: xc_dom_kernel_file: filename="/isolinux/gentoo" xc: error: panic: xc_dom_core.c:208: failed to open file: No such file or directory: Internal error domainbuilder: detail: xc_dom_malloc_filemap: failed (on file `/isolinux/gentoo') libxl: error: libxl_dom.c:546:libxl__build_pv: xc_dom_kernel_file failed: No such file or directory domainbuilder: detail: xc_dom_release: called libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 5252 for destroy of domain 36 libxl: debug: libxl_create.c:1520:do_domain_create: ao 0x2454c30: inprogress: poller=0x2455410, flags=i libxl: debug: libxl_event.c:1765:libxl__ao_complete: ao 0x2454c30: complete, rc=-3 libxl: debug: libxl_event.c:1737:libxl__ao__destroy: ao 0x2454c30: destroy xc: debug: hypercall buffer: total allocations:252 total releases:252 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:237 misses:4 toobig:11 '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and it does exist. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 16:01:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 16:01:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgAd-0007Zf-OV; Mon, 13 Jul 2015 16:01:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgAb-0007Za-EI for xen-users@lists.xen.org; Mon, 13 Jul 2015 16:01:29 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id E4/8B-23832-8D0E3A55; Mon, 13 Jul 2015 16:01:28 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-6.tower-31.messagelabs.com!1436803287!20928065!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=1.2 required=7.0 tests=HOT_NASTY X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4957 invoked from network); 13 Jul 2015 16:01:28 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-6.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 16:01:28 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEgAX-0004W2-M2; Mon, 13 Jul 2015 18:01:25 +0200 Message-ID: <55A3E0D5.8010501@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 18:01:25 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Ian Campbell References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> In-Reply-To: <1436802496.25044.13.camel@citrix.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 13.07.2015 um 17:48 schrieb Ian Campbell: > On Mon, 2015-07-13 at 17:19 +0200, hw wrote: >> Hi, >> >> how do I boot anything to get a VM started and installed? I tried a >> windoze 7 installer ISO and a Gentoo live-DVD ISO and nothing works. No >> matter what I try, I keep getting messages that no kernel can be found >> and that the VM cannot be created. > > Without any logs or even a config file I'm just guessing, but it sounds > like you are wanting to create an HVM guest but are actually creating a > PV one. > > The main difference is the use of > builder = "hvm" > in your cfg file. xl.cfg(5) has details and xlexample.hvm (normally > installed to /etc/xen) an example. Yes, I have that. The config is: # This configures an HVM rather than PV guest builder = "hvm" device_model_version="qemu-xen" #device_model_override="/usr/bin/qemu-img-xen" # Guest name name = "ws-01" # 128-bit UUID for the domain as a hexadecimal number. # Use "uuidgen" to generate one if required. # The default behavior is to generate a new UUID each time the guest is started. #uuid = "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX" # Enable Microsoft Hyper-V compatibile paravirtualisation / # enlightenment interfaces. Turning this on can improve Windows guest # performance and is therefore recommended viridian = 1 # Initial memory allocation (MB) memory = 4096 # Maximum memory (MB) # If this is greater than `memory' then the slack will start ballooned # (this assumes guest kernel support for ballooning) #maxmem = 512 # Number of VCPUS vcpus = 2 # Network devices # A list of 'vifspec' entries as described in # docs/misc/xl-network-configuration.markdown vif = [ 'bridge=brloc' ] # Disk Devices # A list of `diskspec' entries as described in # docs/misc/xl-disk-configuration.txt disk = [ 'phy:/dev/sde1,hda,w', 'file:/root/installers/de_windows_7_professional_with_sp1_x64_dvd_u_676919.iso,hdc:cdrom,r' ] boot="dc" # Guest VGA console configuration, either SDL or VNC sdl = 0 vnc = 1 And I'm only getting: Parsing config from /etc/xen/ws-01.hvm libxl: debug: libxl_create.c:1504:do_domain_create: ao 0x250e350: create: how=(nil) callback=(nil) poller=0x250e3b0 libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hda spec.backend=unknown libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hda, using backend phy libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=hdc spec.backend=unknown libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=hdc, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=hdc, using backend qdisk libxl: debug: libxl_create.c:907:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:323:libxl__bootloader_run: not a PV domain, skipping bootloader libxl: debug: libxl_event.c:629:libxl__ev_xswatch_deregister: watch w=0x250ec80: deregister unregistered libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=26, free_memkb=9875 libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=26, free_memkb=10311 libxl: detail: libxl_dom.c:196:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 10311 KB free selected libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: base group enabled libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: freq group enabled libxl: detail: libxl_dom.c:254:hvm_set_viridian_features: time_ref_count group enabled xc: error: Could not open kernel image (2 = No such file or directory): Internal error libxl: error: libxl_dom.c:818:libxl__build_hvm: hvm building failed libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: error: libxl_dm.c:1595:kill_device_model: unable to find device model pid in /local/domain/35/image/device-model-pid libxl: error: libxl.c:1608:libxl__destroy_domid: libxl__destroy_device_model failed for 35 libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 5250 for destroy of domain 35 libxl: debug: libxl_create.c:1520:do_domain_create: ao 0x250e350: inprogress: poller=0x250e3b0, flags=i libxl: debug: libxl_event.c:1765:libxl__ao_complete: ao 0x250e350: complete, rc=-3 libxl: debug: libxl_event.c:1737:libxl__ao__destroy: ao 0x250e350: destroy xc: debug: hypercall buffer: total allocations:197 total releases:197 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:182 misses:4 toobig:11 So I thought I'd try to make a PV guest with Gentoo ISO and found that nothing can be booted: Parsing config from /etc/xen/test.pvlinux libxl: debug: libxl_create.c:1504:do_domain_create: ao 0x2454c30: create: how=(nil) callback=(nil) poller=0x2455410 libxl: debug: libxl_device.c:269:libxl__device_disk_set_backend: Disk vdev=xvda spec.backend=unknown libxl: debug: libxl_device.c:215:disk_try_backend: Disk vdev=xvda, backend phy unsuitable as phys path not a block device libxl: debug: libxl_device.c:298:libxl__device_disk_set_backend: Disk vdev=xvda, using backend qdisk libxl: debug: libxl_create.c:907:initiate_domain_create: running bootloader libxl: debug: libxl_bootloader.c:329:libxl__bootloader_run: no bootloader configured, using user supplied kernel libxl: debug: libxl_event.c:629:libxl__ev_xswatch_deregister: watch w=0x2455ca0: deregister unregistered libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=36, free_memkb=9875 libxl: debug: libxl_numa.c:483:libxl__get_numa_candidate: New best NUMA placement candidate found: nr_nodes=1, nr_cpus=12, nr_vcpus=36, free_memkb=10312 libxl: detail: libxl_dom.c:196:numa_place_domain: NUMA placement candidate with 1 nodes, 12 cpus and 10312 KB free selected domainbuilder: detail: xc_dom_allocate: cmdline="root=/dev/ram0 init=/linuxrc aufs looptype=squashfs loop=/image.squashfs cdroot", features="(null)" libxl: debug: libxl_dom.c:533:libxl__build_pv: pv kernel mapped 0 path /isolinux/gentoo domainbuilder: detail: xc_dom_kernel_file: filename="/isolinux/gentoo" xc: error: panic: xc_dom_core.c:208: failed to open file: No such file or directory: Internal error domainbuilder: detail: xc_dom_malloc_filemap: failed (on file `/isolinux/gentoo') libxl: error: libxl_dom.c:546:libxl__build_pv: xc_dom_kernel_file failed: No such file or directory domainbuilder: detail: xc_dom_release: called libxl: error: libxl_create.c:1121:domcreate_rebuild_done: cannot (re-)build domain: -3 libxl: info: libxl.c:1691:devices_destroy_cb: forked pid 5252 for destroy of domain 36 libxl: debug: libxl_create.c:1520:do_domain_create: ao 0x2454c30: inprogress: poller=0x2455410, flags=i libxl: debug: libxl_event.c:1765:libxl__ao_complete: ao 0x2454c30: complete, rc=-3 libxl: debug: libxl_event.c:1737:libxl__ao__destroy: ao 0x2454c30: destroy xc: debug: hypercall buffer: total allocations:252 total releases:252 xc: debug: hypercall buffer: current allocations:0 maximum allocations:4 xc: debug: hypercall buffer: cache current size:4 xc: debug: hypercall buffer: cache hits:237 misses:4 toobig:11 '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and it does exist. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 16:23:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 16:23:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgV5-0000bG-Pg; Mon, 13 Jul 2015 16:22:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgV3-0000YZ-Jq for xen-users@lists.xen.org; Mon, 13 Jul 2015 16:22:37 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 09/D2-00468-CC5E3A55; Mon, 13 Jul 2015 16:22:36 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1436804554!20854277!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29009 invoked from network); 13 Jul 2015 16:22:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 16:22:36 -0000 X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="283600597" Message-ID: <1436804552.25044.21.camel@citrix.com> From: Ian Campbell To: hw Date: Mon, 13 Jul 2015 17:22:32 +0100 In-Reply-To: <55A3E0D5.8010501@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 18:01 +0200, hw wrote: > xc: error: Could not open kernel image (2 = No such file or directory): Internal error Strange. This suggests that hvmloader isn't available for some reason. What version of Xen is this? On what distro Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some other path? [...] > '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and > it does exist. Booting a PV guest from an ISO is a bit subtle, http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. Without using pygrub as described there the toolstack will be looking for /isolinux/gentoo on your dom0 filesystem. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 16:23:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 16:23:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgV5-0000bG-Pg; Mon, 13 Jul 2015 16:22:39 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEgV3-0000YZ-Jq for xen-users@lists.xen.org; Mon, 13 Jul 2015 16:22:37 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 09/D2-00468-CC5E3A55; Mon, 13 Jul 2015 16:22:36 +0000 X-Env-Sender: prvs=629d1b08a=Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1436804554!20854277!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29009 invoked from network); 13 Jul 2015 16:22:36 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 16:22:36 -0000 X-IronPort-AV: E=Sophos;i="5.15,463,1432598400"; d="scan'208";a="283600597" Message-ID: <1436804552.25044.21.camel@citrix.com> From: Ian Campbell To: hw Date: Mon, 13 Jul 2015 17:22:32 +0100 In-Reply-To: <55A3E0D5.8010501@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 18:01 +0200, hw wrote: > xc: error: Could not open kernel image (2 = No such file or directory): Internal error Strange. This suggests that hvmloader isn't available for some reason. What version of Xen is this? On what distro Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some other path? [...] > '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and > it does exist. Booting a PV guest from an ISO is a bit subtle, http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. Without using pygrub as described there the toolstack will be looking for /isolinux/gentoo on your dom0 filesystem. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 17:18:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 17:18:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEhMi-00062l-6W; Mon, 13 Jul 2015 17:18:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEhMg-00062I-0H for xen-users@lists.xen.org; Mon, 13 Jul 2015 17:18:02 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 18/D3-18733-9C2F3A55; Mon, 13 Jul 2015 17:18:01 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1436807880!31733338!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29619 invoked from network); 13 Jul 2015 17:18:00 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 17:18:00 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEhMc-0004cH-IE; Mon, 13 Jul 2015 19:17:58 +0200 Message-ID: <55A3F2C6.6010100@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 19:17:58 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Ian Campbell References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> In-Reply-To: <1436804552.25044.21.camel@citrix.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 13.07.2015 um 18:22 schrieb Ian Campbell: > On Mon, 2015-07-13 at 18:01 +0200, hw wrote: >> xc: error: Could not open kernel image (2 = No such file or directory): Internal error > > Strange. This suggests that hvmloader isn't available for some reason. > What version of Xen is this? On what distro It's an up-to-date Gentoo, not sure how to find out what xen version it has. > Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some > other path? 'find / -name hvmloader' doesn't find any files, so I take it it's not available. Am I supopsed to expect that the VM is booting from the ISO when I create it (which is what I do), or am I missing something else? Hmmm ... The 'xen-tools' package has USE flags, according to http://gentoobrowse.randomdan.homeip.net/package/app-emulation/xen-tools --- among them 'hvm'. I do not have this USE flag at all: moonflo ~ # equery uses xen-tools [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-emulation/xen-tools-4.5.1-r1: U I - - api : Build the C libxenapi bindings - - custom-cflags : Build with user-specified CFLAGS (unsupported) - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally - - flask : Enable the Flask XSM module from NSA - - ovmf : Enable support to boot UEFI guest vm, needed by hvm + + pam : Enable pam support - - pygrub : Install the pygrub boot loader - - python : Add optional support/bindings for the Python language + + python_targets_python2_7 : Build with Python 2.7 - - qemu : Enable IOEMU support via the use of qemu-dm - - screen : Enable support for running domain U console in an app-misc/screen session - - static-libs : Build static versions of dynamic libraries as well - - system-qemu : Using app-emulation/qemu instead of the bundled one - - system-seabios : Using sys-firmware/seabios instead of the bundled one moonflo ~ # I'll ask about this on the Gentoo mailing list. > [...] >> '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and >> it does exist. > > Booting a PV guest from an ISO is a bit subtle, > http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. Thanks, maybe that can somehow be applied to the Gentoo ISO. It might be easier to create a hvm guest booting from the Gentoo ISO --- if it was possible to boot something at all ... I could also boot the whole server from an USB stick to do the installation, but at least for the windoze guest, I have doubts that it would run when virtualized. Why do they make it so impossible to install guests on xen to begin with? > Without using pygrub as described there the toolstack will be looking > for /isolinux/gentoo on your dom0 filesystem. Well, pygrub isn't installed. I could install it, but I was planning to install a Gentoo VM only later once the windoze VM is finally running. Maybe it doesn't work at all, and the time would be wasted. What sense would it make to look for files which belong to the guest which is to be installed within the file system of the host? When specifying such files, of course I expect them to be looked for within the guest. The host has already booted and is running. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 17:18:24 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 17:18:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEhMi-00062l-6W; Mon, 13 Jul 2015 17:18:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEhMg-00062I-0H for xen-users@lists.xen.org; Mon, 13 Jul 2015 17:18:02 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id 18/D3-18733-9C2F3A55; Mon, 13 Jul 2015 17:18:01 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-8.tower-27.messagelabs.com!1436807880!31733338!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29619 invoked from network); 13 Jul 2015 17:18:00 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-8.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 13 Jul 2015 17:18:00 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEhMc-0004cH-IE; Mon, 13 Jul 2015 19:17:58 +0200 Message-ID: <55A3F2C6.6010100@gartencenter-vaehning.de> Date: Mon, 13 Jul 2015 19:17:58 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: Ian Campbell References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> In-Reply-To: <1436804552.25044.21.camel@citrix.com> Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 13.07.2015 um 18:22 schrieb Ian Campbell: > On Mon, 2015-07-13 at 18:01 +0200, hw wrote: >> xc: error: Could not open kernel image (2 = No such file or directory): Internal error > > Strange. This suggests that hvmloader isn't available for some reason. > What version of Xen is this? On what distro It's an up-to-date Gentoo, not sure how to find out what xen version it has. > Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some > other path? 'find / -name hvmloader' doesn't find any files, so I take it it's not available. Am I supopsed to expect that the VM is booting from the ISO when I create it (which is what I do), or am I missing something else? Hmmm ... The 'xen-tools' package has USE flags, according to http://gentoobrowse.randomdan.homeip.net/package/app-emulation/xen-tools --- among them 'hvm'. I do not have this USE flag at all: moonflo ~ # equery uses xen-tools [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-emulation/xen-tools-4.5.1-r1: U I - - api : Build the C libxenapi bindings - - custom-cflags : Build with user-specified CFLAGS (unsupported) - - debug : Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces - - doc : Add extra documentation (API, Javadoc, etc). It is recommended to enable per package instead of globally - - flask : Enable the Flask XSM module from NSA - - ovmf : Enable support to boot UEFI guest vm, needed by hvm + + pam : Enable pam support - - pygrub : Install the pygrub boot loader - - python : Add optional support/bindings for the Python language + + python_targets_python2_7 : Build with Python 2.7 - - qemu : Enable IOEMU support via the use of qemu-dm - - screen : Enable support for running domain U console in an app-misc/screen session - - static-libs : Build static versions of dynamic libraries as well - - system-qemu : Using app-emulation/qemu instead of the bundled one - - system-seabios : Using sys-firmware/seabios instead of the bundled one moonflo ~ # I'll ask about this on the Gentoo mailing list. > [...] >> '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and >> it does exist. > > Booting a PV guest from an ISO is a bit subtle, > http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. Thanks, maybe that can somehow be applied to the Gentoo ISO. It might be easier to create a hvm guest booting from the Gentoo ISO --- if it was possible to boot something at all ... I could also boot the whole server from an USB stick to do the installation, but at least for the windoze guest, I have doubts that it would run when virtualized. Why do they make it so impossible to install guests on xen to begin with? > Without using pygrub as described there the toolstack will be looking > for /isolinux/gentoo on your dom0 filesystem. Well, pygrub isn't installed. I could install it, but I was planning to install a Gentoo VM only later once the windoze VM is finally running. Maybe it doesn't work at all, and the time would be wasted. What sense would it make to look for files which belong to the guest which is to be installed within the file system of the host? When specifying such files, of course I expect them to be looked for within the guest. The host has already booted and is running. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 21:35:51 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 21:35:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZElND-0006sW-JW; Mon, 13 Jul 2015 21:34:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZElNC-0006sR-KP for xen-users@lists.xen.org; Mon, 13 Jul 2015 21:34:50 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 77/B6-27764-AFE24A55; Mon, 13 Jul 2015 21:34:50 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1436823288!30583681!1 X-Originating-IP: [209.85.220.51] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25384 invoked from network); 13 Jul 2015 21:34:49 -0000 Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 21:34:49 -0000 Received: by padck2 with SMTP id ck2so48866338pad.0 for ; Mon, 13 Jul 2015 14:34:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=bnDahGgZYPXZQb3R0ewChIH5jUKJlWQkoytqTGyUqIQ=; b=Sk/AZ476HL3usFTHq+LwTzNDxoQ6m9bAYEX93ndCuT34wO3DNni/ZBF+hEGfhSV3M2 U44J/3ac/o12uYB8Ril7kMg+rkY8WxovpGr0WcR3/XKkiYckR7+MWp4Hsv/PGP/0L2Cx 16x8CirwlsEWocIl2p4SQxpjGOOIik6MpeBCeFzFRVcksQ+ZDoZoN0CNh6d8YOmmGEqr cSXoUezKMhVKaOxpadgruZTT7HF/d4CbykE4QS5qnYzZYVlTsoGKBVpuifWOp6ihge0q rg2YkicjY/zaL1EAaDtyoLXB+4m9+q/1DyQNbY0RS7E9DeCDnSfQ8YEBxkNjtMmZslKB iEgw== X-Gm-Message-State: ALoCoQlFOUi80uMJvY358twUFwfP3I2vmOogKZyzcP4OhGTw7LnqdK7f3aV0jcP3HCX3QcLvqVuc X-Received: by 10.66.222.41 with SMTP id qj9mr74184844pac.139.1436823287766; Mon, 13 Jul 2015 14:34:47 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by smtp.gmail.com with ESMTPSA id tm3sm19989693pac.44.2015.07.13.14.34.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jul 2015 14:34:46 -0700 (PDT) From: "Brandon Shoemaker" To: Date: Mon, 13 Jul 2015 14:34:47 -0700 Message-ID: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC9s6/tiV6ZXRV+T4eSAZ+jlmlT+g== Content-Language: en-us X-Antivirus: avast! (VPS 150713-1, 07/13/2015), Outbound message X-Antivirus-Status: Clean Subject: [Xen-users] nested Xen4 CentOS6 freezing after boot in VMWare workstation 11 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi list, I'm trying to setup a testing/learning lab of Xen4 latest 4.4.2-4 on kernel 3.18.12.11 built via SolusVM install script to model my production. I've bought a nice refurb Dell Precision workstation with Xeon W3530 with 24GB RAM so I can lab locally with VMWare Workstation 11.1.2 nesting Xen. I've been able to successfully nest CentOS5 Xen3.4.4 and CentOS6 KVM built via SolusVM but, this CentOS6 Xen is freezing about 10 seconds after booting fully right after giving me login. I tried removing the unneeded devices and single cpu/core suggestions mentioned here > https://www.linkedin.com/grp/post/111929-5803781441602990081 but, they did not solve the issue. I searched for other suggestions but, come up with nothing else. Does anyone know the trick to keep CentOS6 Xen4.4 nested in VMWare workstation 11 from freezing after boot? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 13 21:35:51 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 13 Jul 2015 21:35:51 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZElND-0006sW-JW; Mon, 13 Jul 2015 21:34:51 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZElNC-0006sR-KP for xen-users@lists.xen.org; Mon, 13 Jul 2015 21:34:50 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 77/B6-27764-AFE24A55; Mon, 13 Jul 2015 21:34:50 +0000 X-Env-Sender: brandon@thinkhuge.net X-Msg-Ref: server-4.tower-27.messagelabs.com!1436823288!30583681!1 X-Originating-IP: [209.85.220.51] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25384 invoked from network); 13 Jul 2015 21:34:49 -0000 Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 13 Jul 2015 21:34:49 -0000 Received: by padck2 with SMTP id ck2so48866338pad.0 for ; Mon, 13 Jul 2015 14:34:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=bnDahGgZYPXZQb3R0ewChIH5jUKJlWQkoytqTGyUqIQ=; b=Sk/AZ476HL3usFTHq+LwTzNDxoQ6m9bAYEX93ndCuT34wO3DNni/ZBF+hEGfhSV3M2 U44J/3ac/o12uYB8Ril7kMg+rkY8WxovpGr0WcR3/XKkiYckR7+MWp4Hsv/PGP/0L2Cx 16x8CirwlsEWocIl2p4SQxpjGOOIik6MpeBCeFzFRVcksQ+ZDoZoN0CNh6d8YOmmGEqr cSXoUezKMhVKaOxpadgruZTT7HF/d4CbykE4QS5qnYzZYVlTsoGKBVpuifWOp6ihge0q rg2YkicjY/zaL1EAaDtyoLXB+4m9+q/1DyQNbY0RS7E9DeCDnSfQ8YEBxkNjtMmZslKB iEgw== X-Gm-Message-State: ALoCoQlFOUi80uMJvY358twUFwfP3I2vmOogKZyzcP4OhGTw7LnqdK7f3aV0jcP3HCX3QcLvqVuc X-Received: by 10.66.222.41 with SMTP id qj9mr74184844pac.139.1436823287766; Mon, 13 Jul 2015 14:34:47 -0700 (PDT) Received: from venus (ip70-189-227-212.lv.lv.cox.net. [70.189.227.212]) by smtp.gmail.com with ESMTPSA id tm3sm19989693pac.44.2015.07.13.14.34.45 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 13 Jul 2015 14:34:46 -0700 (PDT) From: "Brandon Shoemaker" To: Date: Mon, 13 Jul 2015 14:34:47 -0700 Message-ID: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdC9s6/tiV6ZXRV+T4eSAZ+jlmlT+g== Content-Language: en-us X-Antivirus: avast! (VPS 150713-1, 07/13/2015), Outbound message X-Antivirus-Status: Clean Subject: [Xen-users] nested Xen4 CentOS6 freezing after boot in VMWare workstation 11 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi list, I'm trying to setup a testing/learning lab of Xen4 latest 4.4.2-4 on kernel 3.18.12.11 built via SolusVM install script to model my production. I've bought a nice refurb Dell Precision workstation with Xeon W3530 with 24GB RAM so I can lab locally with VMWare Workstation 11.1.2 nesting Xen. I've been able to successfully nest CentOS5 Xen3.4.4 and CentOS6 KVM built via SolusVM but, this CentOS6 Xen is freezing about 10 seconds after booting fully right after giving me login. I tried removing the unneeded devices and single cpu/core suggestions mentioned here > https://www.linkedin.com/grp/post/111929-5803781441602990081 but, they did not solve the issue. I searched for other suggestions but, come up with nothing else. Does anyone know the trick to keep CentOS6 Xen4.4 nested in VMWare workstation 11 from freezing after boot? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 07:37:55 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 07:37:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEull-0002uE-DW; Tue, 14 Jul 2015 07:36:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEulj-0002u9-5X for xen-users@lists.xen.org; Tue, 14 Jul 2015 07:36:47 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 4B/F6-06739-E0CB4A55; Tue, 14 Jul 2015 07:36:46 +0000 X-Env-Sender: prvs=630a0ae6d=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436859404!31833262!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6654 invoked from network); 14 Jul 2015 07:36:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 07:36:45 -0000 X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="280709375" Message-ID: <1436859396.7019.129.camel@citrix.com> From: Ian Campbell To: hw Date: Tue, 14 Jul 2015 08:36:36 +0100 In-Reply-To: <55A3F2C6.6010100@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 19:17 +0200, hw wrote: > > Am 13.07.2015 um 18:22 schrieb Ian Campbell: > > On Mon, 2015-07-13 at 18:01 +0200, hw wrote: > >> xc: error: Could not open kernel image (2 = No such file or directory): Internal error > > > > Strange. This suggests that hvmloader isn't available for some reason. > > What version of Xen is this? On what distro > > It's an up-to-date Gentoo, not sure how to find out what xen version it has. > > > Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some > > other path? > > 'find / -name hvmloader' doesn't find any files, so I take it it's not > available. Indeed, and it should be, the fact that it is missing is the root cause of your HVM problems. You should take this up with the Gentoo ebuild maintainers. > Am I supopsed to expect that the VM is booting from the ISO when I > create it (which is what I do), or am I missing something else? As far as HVM guests go you are missing at least hvmloader, I can't say what else might be missing, but if Xen were properly installed this should Just Work. > > [...] > >> '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and > >> it does exist. > > > > Booting a PV guest from an ISO is a bit subtle, > > http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. > > Thanks, maybe that can somehow be applied to the Gentoo ISO. It might > be easier to create a hvm guest booting from the Gentoo ISO --- if it > was possible to boot something at all ... If (all of) Xen were properly installed then booting an HVM guest would be trivial. > I could also boot the whole server from an USB stick to do the > installation, but at least for the windoze guest, I have doubts that it > would run when virtualized. > > Why do they make it so impossible to install guests on xen to begin with? I don't know why Gentoo apparently disables HVM support by default. You could install a PV guest by extracting the kernel+initrd from the iso and giving them as arguments in the cfg file, or by using some other tool (like xen-tools.org) to create a guest, or by downloading an image from somewhere etc. > What sense would it make to look for files which belong to the guest > which is to be installed within the file system of the host? There are two idioms for booting a PV guest, depending on the trust given to the guest admin as a host admin you may want to force a VM to run with a certain kernel which you have supplied. This is (or was) quite common in cloud environments. This avoids all sorts of sharp edges from a security perspective like accessing a potentially untrusted guest filesystem from the toolstack. In fact the Xen toolstack is not itself capable of reading guest file systems, it relies on tools such as pygrub to take on the task of extracting the bootable bits from the guest filesystem such that they can be booted. Like with hvmloader I don't know why Gentoo apparently doesn't include pygrub by default. Pvgrub is another alternative to pygrub which removes some of the security issues inherent in having pygrub open a guest supplied filesystem. > When > specifying such files, of course I expect them to be looked for within > the guest. Then I'm afraid you haven't read the docs properly, e.g. xl.cfg(5) is pretty explicit about where the kernel= option looks for the file named. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 07:37:55 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 07:37:55 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEull-0002uE-DW; Tue, 14 Jul 2015 07:36:49 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEulj-0002u9-5X for xen-users@lists.xen.org; Tue, 14 Jul 2015 07:36:47 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 4B/F6-06739-E0CB4A55; Tue, 14 Jul 2015 07:36:46 +0000 X-Env-Sender: prvs=630a0ae6d=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-27.messagelabs.com!1436859404!31833262!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6654 invoked from network); 14 Jul 2015 07:36:45 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 07:36:45 -0000 X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="280709375" Message-ID: <1436859396.7019.129.camel@citrix.com> From: Ian Campbell To: hw Date: Tue, 14 Jul 2015 08:36:36 +0100 In-Reply-To: <55A3F2C6.6010100@gartencenter-vaehning.de> References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 19:17 +0200, hw wrote: > > Am 13.07.2015 um 18:22 schrieb Ian Campbell: > > On Mon, 2015-07-13 at 18:01 +0200, hw wrote: > >> xc: error: Could not open kernel image (2 = No such file or directory): Internal error > > > > Strange. This suggests that hvmloader isn't available for some reason. > > What version of Xen is this? On what distro > > It's an up-to-date Gentoo, not sure how to find out what xen version it has. > > > Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some > > other path? > > 'find / -name hvmloader' doesn't find any files, so I take it it's not > available. Indeed, and it should be, the fact that it is missing is the root cause of your HVM problems. You should take this up with the Gentoo ebuild maintainers. > Am I supopsed to expect that the VM is booting from the ISO when I > create it (which is what I do), or am I missing something else? As far as HVM guests go you are missing at least hvmloader, I can't say what else might be missing, but if Xen were properly installed this should Just Work. > > [...] > >> '/isolinux/gentoo' is listed in the grub.cfg contained in the ISO, and > >> it does exist. > > > > Booting a PV guest from an ISO is a bit subtle, > > http://wiki.xen.org/wiki/Debian_Guest_Installation_Using_Debian_Installer#Create_Initial_Guest_Configuration_2 shows how it can be done for Debian, I reckon something similar ought to be possible for gentoo. > > Thanks, maybe that can somehow be applied to the Gentoo ISO. It might > be easier to create a hvm guest booting from the Gentoo ISO --- if it > was possible to boot something at all ... If (all of) Xen were properly installed then booting an HVM guest would be trivial. > I could also boot the whole server from an USB stick to do the > installation, but at least for the windoze guest, I have doubts that it > would run when virtualized. > > Why do they make it so impossible to install guests on xen to begin with? I don't know why Gentoo apparently disables HVM support by default. You could install a PV guest by extracting the kernel+initrd from the iso and giving them as arguments in the cfg file, or by using some other tool (like xen-tools.org) to create a guest, or by downloading an image from somewhere etc. > What sense would it make to look for files which belong to the guest > which is to be installed within the file system of the host? There are two idioms for booting a PV guest, depending on the trust given to the guest admin as a host admin you may want to force a VM to run with a certain kernel which you have supplied. This is (or was) quite common in cloud environments. This avoids all sorts of sharp edges from a security perspective like accessing a potentially untrusted guest filesystem from the toolstack. In fact the Xen toolstack is not itself capable of reading guest file systems, it relies on tools such as pygrub to take on the task of extracting the bootable bits from the guest filesystem such that they can be booted. Like with hvmloader I don't know why Gentoo apparently doesn't include pygrub by default. Pvgrub is another alternative to pygrub which removes some of the security issues inherent in having pygrub open a guest supplied filesystem. > When > specifying such files, of course I expect them to be looked for within > the guest. Then I'm afraid you haven't read the docs properly, e.g. xl.cfg(5) is pretty explicit about where the kernel= option looks for the file named. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 08:45:08 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 08:45:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEvom-0005Y7-Mm; Tue, 14 Jul 2015 08:44:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEvol-0005Y2-3d for xen-users@lists.xen.org; Tue, 14 Jul 2015 08:43:59 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 48/B8-30658-ECBC4A55; Tue, 14 Jul 2015 08:43:58 +0000 X-Env-Sender: prvs=630a0ae6d=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436863436!31883629!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6880 invoked from network); 14 Jul 2015 08:43:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 08:43:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="283826039" Message-ID: <1436863402.25044.32.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Tue, 14 Jul 2015 09:43:22 +0100 In-Reply-To: <55A3B02E.7050206@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: > On 07/13/2015 04:29 AM, Ian Campbell wrote: > > On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > > > Is there a 1:1 mapping between (active) interrupts handled by this > > cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > > SPIs would you only be able to use 16 of the devices? > > > > Or does it support multiple interrupt sources triggering a single SPI? > > For the chip I'm working with, it only supports a 1:1 mapping. It > doesn't allow for multiple interrupts to share an SPI line. This simplifies things somewhat for passthrough then, I think. You simply leave routing and assignment of interrupts to SPIs in the hands of dom0, and on passthrough it would pass the SPI to the guest with appropriate values for the interrupt-parent and interrupts properties. > > Right, this is a tricky one. Other than various solutions involving > > trusting the firmware to get it right and requiring dom0 to not muck > > around with it the only other solution I can think of would be a bit of > > code in Xen which traps dom0's attempted changes and validates them, > > preventing dom0 from mucking with the ones Xen cares about. > > > > Given how simple these sorts of interrupt remappers often are that might > > not even be that much code. > > > > Ian. > > > > I think that wouldn't be too difficult to do, but for now, I'm > going to stick with using the device tree to inform Xen and the Kernel. Sure. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 08:45:08 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 08:45:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEvom-0005Y7-Mm; Tue, 14 Jul 2015 08:44:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEvol-0005Y2-3d for xen-users@lists.xen.org; Tue, 14 Jul 2015 08:43:59 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 48/B8-30658-ECBC4A55; Tue, 14 Jul 2015 08:43:58 +0000 X-Env-Sender: prvs=630a0ae6d=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436863436!31883629!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6880 invoked from network); 14 Jul 2015 08:43:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 08:43:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,470,1432598400"; d="scan'208";a="283826039" Message-ID: <1436863402.25044.32.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Tue, 14 Jul 2015 09:43:22 +0100 In-Reply-To: <55A3B02E.7050206@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: > On 07/13/2015 04:29 AM, Ian Campbell wrote: > > On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > > > > Is there a 1:1 mapping between (active) interrupts handled by this > > cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > > SPIs would you only be able to use 16 of the devices? > > > > Or does it support multiple interrupt sources triggering a single SPI? > > For the chip I'm working with, it only supports a 1:1 mapping. It > doesn't allow for multiple interrupts to share an SPI line. This simplifies things somewhat for passthrough then, I think. You simply leave routing and assignment of interrupts to SPIs in the hands of dom0, and on passthrough it would pass the SPI to the guest with appropriate values for the interrupt-parent and interrupts properties. > > Right, this is a tricky one. Other than various solutions involving > > trusting the firmware to get it right and requiring dom0 to not muck > > around with it the only other solution I can think of would be a bit of > > code in Xen which traps dom0's attempted changes and validates them, > > preventing dom0 from mucking with the ones Xen cares about. > > > > Given how simple these sorts of interrupt remappers often are that might > > not even be that much code. > > > > Ian. > > > > I think that wouldn't be too difficult to do, but for now, I'm > going to stick with using the device tree to inform Xen and the Kernel. Sure. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 09:09:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 09:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwCX-0006jX-70; Tue, 14 Jul 2015 09:08:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwCW-0006jS-Et for xen-users@lists.xen.org; Tue, 14 Jul 2015 09:08:32 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id EA/FE-27764-F81D4A55; Tue, 14 Jul 2015 09:08:31 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1436864909!31916597!1 X-Originating-IP: [209.85.218.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17368 invoked from network); 14 Jul 2015 09:08:30 -0000 Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 09:08:30 -0000 Received: by oihq81 with SMTP id q81so2334089oih.2 for ; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rtV6TAoO4vRHUHrm9u62j2JDhVb++0dt9z715aiosCM=; b=oEwmWfVom76LGAEtpgeKIxzQPojQARRIGFaV5qe6OLBUDYfwzeTEQwrxutNicYR/sX UBH14x6TznVsDLrXe7CmaAZvyWCNQ/sGarFayW8zwR3T1snDwuKoJaFTih6BFUo+PGXv 5IEu5rPRhEjeVxNGJSY428pJlWbzYVny/g+gciXeW/3fjygi1nbpzq+aeJxKVcPr47Cu LeHaCgB5wUPnByLLFvoNWUI+YR0pF6MUXedwpiXkLjE4XctpPyZYh873gYntrNOlFkj5 0RuMkH6lBXHQliE2SkJ9Br48V5ltibS1SMLEU2oTRuyF1MegBkmv5KEn+88wRMjQfB8u WQJA== MIME-Version: 1.0 X-Received: by 10.60.50.168 with SMTP id d8mr35976876oeo.41.1436864909243; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) Received: by 10.202.213.143 with HTTP; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) In-Reply-To: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> References: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> Date: Tue, 14 Jul 2015 10:08:29 +0100 X-Google-Sender-Auth: RoQirYT5nmv-AG-1GMCrgnFqrfc Message-ID: From: George Dunlap To: Brandon Shoemaker Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] nested Xen4 CentOS6 freezing after boot in VMWare workstation 11 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, Jul 13, 2015 at 10:34 PM, Brandon Shoemaker wrote: > Hi list, > > I'm trying to setup a testing/learning lab of Xen4 latest 4.4.2-4 on kernel > 3.18.12.11 built via SolusVM install script to model my production. I've > bought a nice refurb Dell Precision workstation with Xeon W3530 with 24GB > RAM so I can lab locally with VMWare Workstation 11.1.2 nesting Xen. I've > been able to successfully nest CentOS5 Xen3.4.4 and CentOS6 KVM built via > SolusVM but, this CentOS6 Xen is freezing about 10 seconds after booting > fully right after giving me login. > > I tried removing the unneeded devices and single cpu/core suggestions > mentioned here > > https://www.linkedin.com/grp/post/111929-5803781441602990081 but, they did > not solve the issue. I searched for other suggestions but, come up with > nothing else. > > Does anyone know the trick to keep CentOS6 Xen4.4 nested in VMWare > workstation 11 from freezing after boot? Does VMWare give you the ability to have any serial output? That might help give us a clue why Xen is crashing / hanging. -George _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 09:09:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 09:09:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwCX-0006jX-70; Tue, 14 Jul 2015 09:08:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwCW-0006jS-Et for xen-users@lists.xen.org; Tue, 14 Jul 2015 09:08:32 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id EA/FE-27764-F81D4A55; Tue, 14 Jul 2015 09:08:31 +0000 X-Env-Sender: dunlapg@gmail.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1436864909!31916597!1 X-Originating-IP: [209.85.218.43] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17368 invoked from network); 14 Jul 2015 09:08:30 -0000 Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by server-13.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 14 Jul 2015 09:08:30 -0000 Received: by oihq81 with SMTP id q81so2334089oih.2 for ; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rtV6TAoO4vRHUHrm9u62j2JDhVb++0dt9z715aiosCM=; b=oEwmWfVom76LGAEtpgeKIxzQPojQARRIGFaV5qe6OLBUDYfwzeTEQwrxutNicYR/sX UBH14x6TznVsDLrXe7CmaAZvyWCNQ/sGarFayW8zwR3T1snDwuKoJaFTih6BFUo+PGXv 5IEu5rPRhEjeVxNGJSY428pJlWbzYVny/g+gciXeW/3fjygi1nbpzq+aeJxKVcPr47Cu LeHaCgB5wUPnByLLFvoNWUI+YR0pF6MUXedwpiXkLjE4XctpPyZYh873gYntrNOlFkj5 0RuMkH6lBXHQliE2SkJ9Br48V5ltibS1SMLEU2oTRuyF1MegBkmv5KEn+88wRMjQfB8u WQJA== MIME-Version: 1.0 X-Received: by 10.60.50.168 with SMTP id d8mr35976876oeo.41.1436864909243; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) Received: by 10.202.213.143 with HTTP; Tue, 14 Jul 2015 02:08:29 -0700 (PDT) In-Reply-To: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> References: <013d01d0bdb3$bf1b56e0$3d5204a0$@thinkhuge.net> Date: Tue, 14 Jul 2015 10:08:29 +0100 X-Google-Sender-Auth: RoQirYT5nmv-AG-1GMCrgnFqrfc Message-ID: From: George Dunlap To: Brandon Shoemaker Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] nested Xen4 CentOS6 freezing after boot in VMWare workstation 11 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, Jul 13, 2015 at 10:34 PM, Brandon Shoemaker wrote: > Hi list, > > I'm trying to setup a testing/learning lab of Xen4 latest 4.4.2-4 on kernel > 3.18.12.11 built via SolusVM install script to model my production. I've > bought a nice refurb Dell Precision workstation with Xeon W3530 with 24GB > RAM so I can lab locally with VMWare Workstation 11.1.2 nesting Xen. I've > been able to successfully nest CentOS5 Xen3.4.4 and CentOS6 KVM built via > SolusVM but, this CentOS6 Xen is freezing about 10 seconds after booting > fully right after giving me login. > > I tried removing the unneeded devices and single cpu/core suggestions > mentioned here > > https://www.linkedin.com/grp/post/111929-5803781441602990081 but, they did > not solve the issue. I searched for other suggestions but, come up with > nothing else. > > Does anyone know the trick to keep CentOS6 Xen4.4 nested in VMWare > workstation 11 from freezing after boot? Does VMWare give you the ability to have any serial output? That might help give us a clue why Xen is crashing / hanging. -George _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 09:10:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 09:10:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwEB-0006mr-Ri; Tue, 14 Jul 2015 09:10:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwEA-0006mi-4x for xen-users@lists.xen.org; Tue, 14 Jul 2015 09:10:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id F0/C1-23832-5F1D4A55; Tue, 14 Jul 2015 09:10:13 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-2.tower-31.messagelabs.com!1436865012!25549680!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6795 invoked from network); 14 Jul 2015 09:10:12 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-2.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jul 2015 09:10:12 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEwE7-0006He-VF for xen-users@lists.xen.org; Tue, 14 Jul 2015 11:10:11 +0200 Message-ID: <55A4D1F3.7090007@gartencenter-vaehning.de> Date: Tue, 14 Jul 2015 11:10:11 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> <1436859396.7019.129.camel@citrix.com> In-Reply-To: <1436859396.7019.129.camel@citrix.com> Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 14.07.2015 um 09:36 schrieb Ian Campbell: > On Mon, 2015-07-13 at 19:17 +0200, hw wrote: >> >> Am 13.07.2015 um 18:22 schrieb Ian Campbell: >>> On Mon, 2015-07-13 at 18:01 +0200, hw wrote: >>>> xc: error: Could not open kernel image (2 = No such file or directory): Internal error >>> >>> Strange. This suggests that hvmloader isn't available for some reason. >>> What version of Xen is this? On what distro >> >> It's an up-to-date Gentoo, not sure how to find out what xen version it has. >> >>> Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some >>> other path? >> >> 'find / -name hvmloader' doesn't find any files, so I take it it's not >> available. > > Indeed, and it should be, the fact that it is missing is the root cause > of your HVM problems. You should take this up with the Gentoo ebuild > maintainers. > >> Am I supopsed to expect that the VM is booting from the ISO when I >> create it (which is what I do), or am I missing something else? > > As far as HVM guests go you are missing at least hvmloader, I can't say > what else might be missing, but if Xen were properly installed this > should Just Work. It seems that there is a USE flag 'hvm' which needs to be enabled. For unknown reasons, this USE flag is disabled which makes it not show up when the flags are queried and leaves me unable to enable it. > If (all of) Xen were properly installed then booting an HVM guest would > be trivial. Well, I thought it would be relatively easy ... >> I could also boot the whole server from an USB stick to do the >> installation, but at least for the windoze guest, I have doubts that it >> would run when virtualized. >> >> Why do they make it so impossible to install guests on xen to begin with? > > I don't know why Gentoo apparently disables HVM support by default. Usually, you check what USE flags there are and enable just the ones you need and disable others you don't need. Like there's no point in building emacs with X11 support when you will never use that anyway, there's no need to enable HVM support in case you don't need it. That's perfectly fine, however, in this case, the USE flag isn't disabled in the usual way but in such a way that you cannot use the flag at all. > You could install a PV guest by extracting the kernel+initrd from the > iso and giving them as arguments in the cfg file, or by using some other > tool (like xen-tools.org) to create a guest, or by downloading an image > from somewhere etc. HVM support is required in the first place, and before that doesn't work, I don't want to waste time with trying to get a PV guest to work. Those really need to be much simpler to install. >> What sense would it make to look for files which belong to the guest >> which is to be installed within the file system of the host? > > There are two idioms for booting a PV guest, depending on the trust > given to the guest admin as a host admin you may want to force a VM to > run with a certain kernel which you have supplied. This is (or was) > quite common in cloud environments. This avoids all sorts of sharp edges > from a security perspective like accessing a potentially untrusted guest > filesystem from the toolstack. Then why not make it so that you need to explicitly specify that the guest shall read files residing on the host? > In fact the Xen toolstack is not itself capable of reading guest file > systems, it relies on tools such as pygrub to take on the task of > extracting the bootable bits from the guest filesystem such that they > can be booted. Like with hvmloader I don't know why Gentoo apparently > doesn't include pygrub by default. > > Pvgrub is another alternative to pygrub which removes some of the > security issues inherent in having pygrub open a guest supplied > filesystem. That still doesn't make sense to me. Why can't I just boot a system which is capable to run as a PV guest without all this ado? Without xen, I plug in the USB stick and boot from it. Xen makes it complicated by not letting me boot from the stick or the ISO it was created from when I want to install a PV guest. > >> When >> specifying such files, of course I expect them to be looked for within >> the guest. > > Then I'm afraid you haven't read the docs properly, e.g. xl.cfg(5) is > pretty explicit about where the kernel= option looks for the file named. Xen is extremely confusing and nothing but frustrating, and the docs on the wiki are a mess. That a guest reads files residing on the host just like that is a good example for bad design. Of course, the kernel does not reside on the host, and if I wanted to force reading a file residing on the host, the option for that should at least give a hint that it does this. Why not use something like 'hostside_kernel' instead of 'kernel', and/or invent a naming convention for items that are on the host and items that are confined within the guest? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 09:10:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 09:10:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwEB-0006mr-Ri; Tue, 14 Jul 2015 09:10:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZEwEA-0006mi-4x for xen-users@lists.xen.org; Tue, 14 Jul 2015 09:10:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id F0/C1-23832-5F1D4A55; Tue, 14 Jul 2015 09:10:13 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-2.tower-31.messagelabs.com!1436865012!25549680!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6795 invoked from network); 14 Jul 2015 09:10:12 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-2.tower-31.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jul 2015 09:10:12 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZEwE7-0006He-VF for xen-users@lists.xen.org; Tue, 14 Jul 2015 11:10:11 +0200 Message-ID: <55A4D1F3.7090007@gartencenter-vaehning.de> Date: Tue, 14 Jul 2015 11:10:11 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> <1436859396.7019.129.camel@citrix.com> In-Reply-To: <1436859396.7019.129.camel@citrix.com> Subject: Re: [Xen-users] how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Am 14.07.2015 um 09:36 schrieb Ian Campbell: > On Mon, 2015-07-13 at 19:17 +0200, hw wrote: >> >> Am 13.07.2015 um 18:22 schrieb Ian Campbell: >>> On Mon, 2015-07-13 at 18:01 +0200, hw wrote: >>>> xc: error: Could not open kernel image (2 = No such file or directory): Internal error >>> >>> Strange. This suggests that hvmloader isn't available for some reason. >>> What version of Xen is this? On what distro >> >> It's an up-to-date Gentoo, not sure how to find out what xen version it has. >> >>> Do you have $prefix/lib/xen/boot/hvmloader ? If not then is it at some >>> other path? >> >> 'find / -name hvmloader' doesn't find any files, so I take it it's not >> available. > > Indeed, and it should be, the fact that it is missing is the root cause > of your HVM problems. You should take this up with the Gentoo ebuild > maintainers. > >> Am I supopsed to expect that the VM is booting from the ISO when I >> create it (which is what I do), or am I missing something else? > > As far as HVM guests go you are missing at least hvmloader, I can't say > what else might be missing, but if Xen were properly installed this > should Just Work. It seems that there is a USE flag 'hvm' which needs to be enabled. For unknown reasons, this USE flag is disabled which makes it not show up when the flags are queried and leaves me unable to enable it. > If (all of) Xen were properly installed then booting an HVM guest would > be trivial. Well, I thought it would be relatively easy ... >> I could also boot the whole server from an USB stick to do the >> installation, but at least for the windoze guest, I have doubts that it >> would run when virtualized. >> >> Why do they make it so impossible to install guests on xen to begin with? > > I don't know why Gentoo apparently disables HVM support by default. Usually, you check what USE flags there are and enable just the ones you need and disable others you don't need. Like there's no point in building emacs with X11 support when you will never use that anyway, there's no need to enable HVM support in case you don't need it. That's perfectly fine, however, in this case, the USE flag isn't disabled in the usual way but in such a way that you cannot use the flag at all. > You could install a PV guest by extracting the kernel+initrd from the > iso and giving them as arguments in the cfg file, or by using some other > tool (like xen-tools.org) to create a guest, or by downloading an image > from somewhere etc. HVM support is required in the first place, and before that doesn't work, I don't want to waste time with trying to get a PV guest to work. Those really need to be much simpler to install. >> What sense would it make to look for files which belong to the guest >> which is to be installed within the file system of the host? > > There are two idioms for booting a PV guest, depending on the trust > given to the guest admin as a host admin you may want to force a VM to > run with a certain kernel which you have supplied. This is (or was) > quite common in cloud environments. This avoids all sorts of sharp edges > from a security perspective like accessing a potentially untrusted guest > filesystem from the toolstack. Then why not make it so that you need to explicitly specify that the guest shall read files residing on the host? > In fact the Xen toolstack is not itself capable of reading guest file > systems, it relies on tools such as pygrub to take on the task of > extracting the bootable bits from the guest filesystem such that they > can be booted. Like with hvmloader I don't know why Gentoo apparently > doesn't include pygrub by default. > > Pvgrub is another alternative to pygrub which removes some of the > security issues inherent in having pygrub open a guest supplied > filesystem. That still doesn't make sense to me. Why can't I just boot a system which is capable to run as a PV guest without all this ado? Without xen, I plug in the USB stick and boot from it. Xen makes it complicated by not letting me boot from the stick or the ISO it was created from when I want to install a PV guest. > >> When >> specifying such files, of course I expect them to be looked for within >> the guest. > > Then I'm afraid you haven't read the docs properly, e.g. xl.cfg(5) is > pretty explicit about where the kernel= option looks for the file named. Xen is extremely confusing and nothing but frustrating, and the docs on the wiki are a mess. That a guest reads files residing on the host just like that is a good example for bad design. Of course, the kernel does not reside on the host, and if I wanted to force reading a file residing on the host, the option for that should at least give a hint that it does this. Why not use something like 'hostside_kernel' instead of 'kernel', and/or invent a naming convention for items that are on the host and items that are confined within the guest? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 15:29:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 15:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZF284-00041P-43; Tue, 14 Jul 2015 15:28:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZF281-00040p-UM for xen-users@lists.xen.org; Tue, 14 Jul 2015 15:28:18 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id F9/06-06739-19A25A55; Tue, 14 Jul 2015 15:28:17 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1436887696!32044352!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30005 invoked from network); 14 Jul 2015 15:28:16 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jul 2015 15:28:16 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZF27z-0006mT-Td for xen-users@lists.xen.org; Tue, 14 Jul 2015 17:28:15 +0200 Message-ID: <55A52A8F.4080101@gartencenter-vaehning.de> Date: Tue, 14 Jul 2015 17:28:15 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> <1436859396.7019.129.camel@citrix.com> In-Reply-To: <1436859396.7019.129.camel@citrix.com> Subject: [Xen-users] solved: how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Gentoo requires you to have a so-called multilib system when you want to have xen with hardware virtulization :( Apparently this is needed because some 32bit software needs to be compiled when installing xen-tools. Otherwise the USE flag 'hvm' cannot be enabled. So I re-installed the server and it's finally working. Thank you very much for your help! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 14 15:29:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 14 Jul 2015 15:29:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZF284-00041P-43; Tue, 14 Jul 2015 15:28:20 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZF281-00040p-UM for xen-users@lists.xen.org; Tue, 14 Jul 2015 15:28:18 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id F9/06-06739-19A25A55; Tue, 14 Jul 2015 15:28:17 +0000 X-Env-Sender: hw@gartencenter-vaehning.de X-Msg-Ref: server-14.tower-27.messagelabs.com!1436887696!32044352!1 X-Originating-IP: [46.227.95.21] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30005 invoked from network); 14 Jul 2015 15:28:16 -0000 Received: from gc-24.de (HELO sunflo-mx.v.h.gc-24.de) (46.227.95.21) by server-14.tower-27.messagelabs.com with AES128-SHA encrypted SMTP; 14 Jul 2015 15:28:16 -0000 Received: from s-backup-03.v.h.gc-24.de ([192.168.220.17]) by sunflo-mx.v.h.gc-24.de with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZF27z-0006mT-Td for xen-users@lists.xen.org; Tue, 14 Jul 2015 17:28:15 +0200 Message-ID: <55A52A8F.4080101@gartencenter-vaehning.de> Date: Tue, 14 Jul 2015 17:28:15 +0200 From: hw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.4.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55A3D70C.2040602@gartencenter-vaehning.de> <1436802496.25044.13.camel@citrix.com> <55A3E0D5.8010501@gartencenter-vaehning.de> <1436804552.25044.21.camel@citrix.com> <55A3F2C6.6010100@gartencenter-vaehning.de> <1436859396.7019.129.camel@citrix.com> In-Reply-To: <1436859396.7019.129.camel@citrix.com> Subject: [Xen-users] solved: how to boot something to get a vm started X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Gentoo requires you to have a so-called multilib system when you want to have xen with hardware virtulization :( Apparently this is needed because some 32bit software needs to be compiled when installing xen-tools. Otherwise the USE flag 'hvm' cannot be enabled. So I re-installed the server and it's finally working. Thank you very much for your help! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 06:03:35 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 06:03:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFFlo-0007PA-GA; Wed, 15 Jul 2015 06:02:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFFln-0007P5-8E for xen-users@lists.xen.org; Wed, 15 Jul 2015 06:02:15 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id AE/DD-18947-667F5A55; Wed, 15 Jul 2015 06:02:14 +0000 X-Env-Sender: alex@wakizashi.info X-Msg-Ref: server-4.tower-27.messagelabs.com!1436940133!30980624!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3479 invoked from network); 15 Jul 2015 06:02:13 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 06:02:13 -0000 Received: by lbbzr7 with SMTP id zr7so18457511lbb.1 for ; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakizashi.info; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=CPNozn6+YPTaM26Axmb+w26Gp1XAEepk+zoWHF12h24=; b=IAkfSlcG7r9zw5+XdaEgint1MmI4DKd/DzJzKC9pLdDMSwPFhT7yObs7u/ibI4dA3g +f2jzeUBeZceJSRYUCnD2U0bYX3lfmbka+026/8CRFU7qSrlK+Pcb3Q/F7x8Xk4Zfeml Z6pgfUpeUgoXQXyEctiIHk8MsodWGDHniZNcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=CPNozn6+YPTaM26Axmb+w26Gp1XAEepk+zoWHF12h24=; b=cC8wArB+XmY5IAlr2Anyxh6jrveNfApGvS/UVt3DKdXl0uVxE40+QdjNH+yUqTHTEy NxpJO0yCOfyr/1pczAwdiMyU43e/y8+zN+lg8Xs+42pSQQURL42C632MfwSFbTPXzbJr FWxIYFDAkYrN5rHZZD4i7vmQdInyHM97XYFB0D6nsmgWZnzbOIom1XPIiw47RlObKzEe hLmWe+I3rXTiom/dS0h5bH/899oYuvG1ZQjr2m3KlqZCjuvvXIb/sIaTYforF9aYcjA7 GMJ78c6nHfR1T5T2svFUhsTOEpVd40VkpzFhLCSvfsjb8Zal6sVhqHIxL8R4iua/ZPgv 9ZWg== X-Gm-Message-State: ALoCoQlVkfR+9X0jTZs7dEVvjY1oq8dekZV8vzFmcbK+v4l7Mz+05Vm2aJdgc2FKe+Zjgbze4Fr2 MIME-Version: 1.0 X-Received: by 10.152.121.42 with SMTP id lh10mr2414876lab.0.1436940133198; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) Received: by 10.152.210.198 with HTTP; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) Date: Wed, 15 Jul 2015 09:02:13 +0300 Message-ID: From: Alex Wakizashi To: xen-users@lists.xen.org Cc: Andrew Cooper Subject: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello, all, I have tried to pass ATI VGA card (R9 290X) to VM using PCI passthrough functionality, and got few issues. System: EVGA X99M + E5-2630v3 (So, UEFI BIOS and all possible features for virtualization), XEN 4.5.1 (compiled from sources), OVMF (tried both XEN and upstream), QEMU (both XEN's 2.2 and upstream 2.3-rc0). First problem: Passed-through card is not working with XEN+OVMF. It just hangs at OVMF load, I suppose. It's working normally with KVM + OVMF (with VFIO), it is working with seabios and QEMU upstream. (Except that drivers need to be installed manualy, not through AMD installer, which crashing). Card have dual BIOS - both EFI and legacy ROM, so, I have tried to boot it with OVMF. Also have tried NVidia G210 (also with UEFI ROM) - same thing. So, if there are some PCIe VGA board passed through to HVM domain, TianoCore doesn't show any picture neither on the VNC display, nor on card's DVI/DP/HDMI. And this is XEN specific issue, as it working like a charm in KVM. Without PCI passthrough HVM+OVMF working fine. According to the XL logs, seems like it always trying to reboot VM. I have tried to disable ROM BIOS on the cards, or boot host system in Legacy mode (to avoid UEFI BIOS initialization), it doesn't matter. Also, tried simple USB controller pass-through - it causing HVM domain with OVMF to hang for few minutes, and only after that show the logo. Does anybody know, how to make it work? Or at least - how to get more information, what is happening with OVMF, retrieve some logs, etc.? -- Second problem - XEN implementation of OVMF doesn't allow to save any settings. Regardless of pflash image, specified in QEMU as "-drive if=pflash..." - it's just not saving settings at all. Again, would be excellent to be able to specify separate OVMF image, like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that is a problem. I've seen discussion in this mail list about separated version of OVMF for XEN, but it stopped few months ago without any links/solutions. (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave some answers). So, would be glad to get hands on such version and test it :) Regards, Alex _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 06:03:35 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 06:03:35 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFFlo-0007PA-GA; Wed, 15 Jul 2015 06:02:16 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFFln-0007P5-8E for xen-users@lists.xen.org; Wed, 15 Jul 2015 06:02:15 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id AE/DD-18947-667F5A55; Wed, 15 Jul 2015 06:02:14 +0000 X-Env-Sender: alex@wakizashi.info X-Msg-Ref: server-4.tower-27.messagelabs.com!1436940133!30980624!1 X-Originating-IP: [209.85.217.173] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3479 invoked from network); 15 Jul 2015 06:02:13 -0000 Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by server-4.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 06:02:13 -0000 Received: by lbbzr7 with SMTP id zr7so18457511lbb.1 for ; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakizashi.info; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=CPNozn6+YPTaM26Axmb+w26Gp1XAEepk+zoWHF12h24=; b=IAkfSlcG7r9zw5+XdaEgint1MmI4DKd/DzJzKC9pLdDMSwPFhT7yObs7u/ibI4dA3g +f2jzeUBeZceJSRYUCnD2U0bYX3lfmbka+026/8CRFU7qSrlK+Pcb3Q/F7x8Xk4Zfeml Z6pgfUpeUgoXQXyEctiIHk8MsodWGDHniZNcI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=CPNozn6+YPTaM26Axmb+w26Gp1XAEepk+zoWHF12h24=; b=cC8wArB+XmY5IAlr2Anyxh6jrveNfApGvS/UVt3DKdXl0uVxE40+QdjNH+yUqTHTEy NxpJO0yCOfyr/1pczAwdiMyU43e/y8+zN+lg8Xs+42pSQQURL42C632MfwSFbTPXzbJr FWxIYFDAkYrN5rHZZD4i7vmQdInyHM97XYFB0D6nsmgWZnzbOIom1XPIiw47RlObKzEe hLmWe+I3rXTiom/dS0h5bH/899oYuvG1ZQjr2m3KlqZCjuvvXIb/sIaTYforF9aYcjA7 GMJ78c6nHfR1T5T2svFUhsTOEpVd40VkpzFhLCSvfsjb8Zal6sVhqHIxL8R4iua/ZPgv 9ZWg== X-Gm-Message-State: ALoCoQlVkfR+9X0jTZs7dEVvjY1oq8dekZV8vzFmcbK+v4l7Mz+05Vm2aJdgc2FKe+Zjgbze4Fr2 MIME-Version: 1.0 X-Received: by 10.152.121.42 with SMTP id lh10mr2414876lab.0.1436940133198; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) Received: by 10.152.210.198 with HTTP; Tue, 14 Jul 2015 23:02:13 -0700 (PDT) Date: Wed, 15 Jul 2015 09:02:13 +0300 Message-ID: From: Alex Wakizashi To: xen-users@lists.xen.org Cc: Andrew Cooper Subject: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello, all, I have tried to pass ATI VGA card (R9 290X) to VM using PCI passthrough functionality, and got few issues. System: EVGA X99M + E5-2630v3 (So, UEFI BIOS and all possible features for virtualization), XEN 4.5.1 (compiled from sources), OVMF (tried both XEN and upstream), QEMU (both XEN's 2.2 and upstream 2.3-rc0). First problem: Passed-through card is not working with XEN+OVMF. It just hangs at OVMF load, I suppose. It's working normally with KVM + OVMF (with VFIO), it is working with seabios and QEMU upstream. (Except that drivers need to be installed manualy, not through AMD installer, which crashing). Card have dual BIOS - both EFI and legacy ROM, so, I have tried to boot it with OVMF. Also have tried NVidia G210 (also with UEFI ROM) - same thing. So, if there are some PCIe VGA board passed through to HVM domain, TianoCore doesn't show any picture neither on the VNC display, nor on card's DVI/DP/HDMI. And this is XEN specific issue, as it working like a charm in KVM. Without PCI passthrough HVM+OVMF working fine. According to the XL logs, seems like it always trying to reboot VM. I have tried to disable ROM BIOS on the cards, or boot host system in Legacy mode (to avoid UEFI BIOS initialization), it doesn't matter. Also, tried simple USB controller pass-through - it causing HVM domain with OVMF to hang for few minutes, and only after that show the logo. Does anybody know, how to make it work? Or at least - how to get more information, what is happening with OVMF, retrieve some logs, etc.? -- Second problem - XEN implementation of OVMF doesn't allow to save any settings. Regardless of pflash image, specified in QEMU as "-drive if=pflash..." - it's just not saving settings at all. Again, would be excellent to be able to specify separate OVMF image, like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that is a problem. I've seen discussion in this mail list about separated version of OVMF for XEN, but it stopped few months ago without any links/solutions. (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave some answers). So, would be glad to get hands on such version and test it :) Regards, Alex _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 13:38:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 13:38:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFMsP-0006K8-G4; Wed, 15 Jul 2015 13:37:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFMsO-0006JS-9P for xen-users@lists.xen.org; Wed, 15 Jul 2015 13:37:32 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 9B/3E-01469-B1266A55; Wed, 15 Jul 2015 13:37:31 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436967449!32347362!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17782 invoked from network); 15 Jul 2015 13:37:30 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jul 2015 13:37:30 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6FDbSsL032453; Wed, 15 Jul 2015 08:37:28 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6FDbS6A010093; Wed, 15 Jul 2015 08:37:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 15 Jul 2015 08:37:03 -0500 Message-ID: <55A65412.6020103@ti.com> Date: Wed, 15 Jul 2015 08:37:38 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> <1436863402.25044.32.camel@citrix.com> In-Reply-To: <1436863402.25044.32.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/14/2015 04:43 AM, Ian Campbell wrote: > On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: >> On 07/13/2015 04:29 AM, Ian Campbell wrote: >>> On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: >>> >>> Is there a 1:1 mapping between (active) interrupts handled by this >>> cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 >>> SPIs would you only be able to use 16 of the devices? >>> >>> Or does it support multiple interrupt sources triggering a single SPI? >> >> For the chip I'm working with, it only supports a 1:1 mapping. It >> doesn't allow for multiple interrupts to share an SPI line. > > This simplifies things somewhat for passthrough then, I think. You > simply leave routing and assignment of interrupts to SPIs in the hands > of dom0, and on passthrough it would pass the SPI to the guest with > appropriate values for the interrupt-parent and interrupts properties. > >>> Right, this is a tricky one. Other than various solutions involving >>> trusting the firmware to get it right and requiring dom0 to not muck >>> around with it the only other solution I can think of would be a bit of >>> code in Xen which traps dom0's attempted changes and validates them, >>> preventing dom0 from mucking with the ones Xen cares about. >>> >>> Given how simple these sorts of interrupt remappers often are that might >>> not even be that much code. >>> >>> Ian. >>> >> >> I think that wouldn't be too difficult to do, but for now, I'm >> going to stick with using the device tree to inform Xen and the Kernel. > > Sure. > Hi Ian, This question pertains to what we've been talking about, so I'm going to keep it on this thread. I was hoping to get some clarification on how secondary interrupts are passed to Dom0 by Xen. My current understanding is as follows. When Xen constructs Dom0, it goes through each entry in the device tree. It then reads out each entry in the "interrupts" property. If the device is connected to the primary interrupt controller, then Xen performs the necessary steps to allocate the IRQ to the guest, and then route it to the guest also. Otherwise, if the controller is not the primary one, then Xen does nothing. This all happens in handle_device(). Here's where my understanding becomes a little less clear. Later on, the kernel will boot, and as needed, will write to its vGIC. This will be trapped into Xen as a data abort, and handled as an MMIO write. Eventually, it makes its way to the function gicv2_irq_enable(), which actually writes to the vGIC and GIC to enable said interrupt. Does this sound right, or am I missing some key components? I'm attempting to enable the kernel to handle the mapping and routing of IRQ's on the crossbar. So, what I'm doing is, for each device in the DT that is a peripheral device (SPI), I'm changing its "interrupt-parent" property to be a device node representing the crossbar. However, this is leading to data aborts and/or interrupts not being delivered to the kernel. Either the kernel encounters a data abort (presumably due to the fact that it does not have permission for the IRQ), or I find the kernel running in "idle_loop()" (which in my experience means its waiting for an interrupt to be delivered). Is the functionality in Xen to allow me to passthrough secondary interrupts like this, or will some changes be needed? If so, could you point me in the right direction? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 13:38:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 13:38:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFMsP-0006K8-G4; Wed, 15 Jul 2015 13:37:33 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFMsO-0006JS-9P for xen-users@lists.xen.org; Wed, 15 Jul 2015 13:37:32 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 9B/3E-01469-B1266A55; Wed, 15 Jul 2015 13:37:31 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436967449!32347362!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17782 invoked from network); 15 Jul 2015 13:37:30 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jul 2015 13:37:30 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6FDbSsL032453; Wed, 15 Jul 2015 08:37:28 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6FDbS6A010093; Wed, 15 Jul 2015 08:37:28 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 15 Jul 2015 08:37:03 -0500 Message-ID: <55A65412.6020103@ti.com> Date: Wed, 15 Jul 2015 08:37:38 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> <1436863402.25044.32.camel@citrix.com> In-Reply-To: <1436863402.25044.32.camel@citrix.com> X-Originating-IP: [128.247.93.131] Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/14/2015 04:43 AM, Ian Campbell wrote: > On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: >> On 07/13/2015 04:29 AM, Ian Campbell wrote: >>> On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: >>> >>> Is there a 1:1 mapping between (active) interrupts handled by this >>> cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 >>> SPIs would you only be able to use 16 of the devices? >>> >>> Or does it support multiple interrupt sources triggering a single SPI? >> >> For the chip I'm working with, it only supports a 1:1 mapping. It >> doesn't allow for multiple interrupts to share an SPI line. > > This simplifies things somewhat for passthrough then, I think. You > simply leave routing and assignment of interrupts to SPIs in the hands > of dom0, and on passthrough it would pass the SPI to the guest with > appropriate values for the interrupt-parent and interrupts properties. > >>> Right, this is a tricky one. Other than various solutions involving >>> trusting the firmware to get it right and requiring dom0 to not muck >>> around with it the only other solution I can think of would be a bit of >>> code in Xen which traps dom0's attempted changes and validates them, >>> preventing dom0 from mucking with the ones Xen cares about. >>> >>> Given how simple these sorts of interrupt remappers often are that might >>> not even be that much code. >>> >>> Ian. >>> >> >> I think that wouldn't be too difficult to do, but for now, I'm >> going to stick with using the device tree to inform Xen and the Kernel. > > Sure. > Hi Ian, This question pertains to what we've been talking about, so I'm going to keep it on this thread. I was hoping to get some clarification on how secondary interrupts are passed to Dom0 by Xen. My current understanding is as follows. When Xen constructs Dom0, it goes through each entry in the device tree. It then reads out each entry in the "interrupts" property. If the device is connected to the primary interrupt controller, then Xen performs the necessary steps to allocate the IRQ to the guest, and then route it to the guest also. Otherwise, if the controller is not the primary one, then Xen does nothing. This all happens in handle_device(). Here's where my understanding becomes a little less clear. Later on, the kernel will boot, and as needed, will write to its vGIC. This will be trapped into Xen as a data abort, and handled as an MMIO write. Eventually, it makes its way to the function gicv2_irq_enable(), which actually writes to the vGIC and GIC to enable said interrupt. Does this sound right, or am I missing some key components? I'm attempting to enable the kernel to handle the mapping and routing of IRQ's on the crossbar. So, what I'm doing is, for each device in the DT that is a peripheral device (SPI), I'm changing its "interrupt-parent" property to be a device node representing the crossbar. However, this is leading to data aborts and/or interrupts not being delivered to the kernel. Either the kernel encounters a data abort (presumably due to the fact that it does not have permission for the IRQ), or I find the kernel running in "idle_loop()" (which in my experience means its waiting for an interrupt to be delivered). Is the functionality in Xen to allow me to passthrough secondary interrupts like this, or will some changes be needed? If so, could you point me in the right direction? Brandon _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 14:21:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 14:21:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFNY1-0002i2-MQ; Wed, 15 Jul 2015 14:20:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFNY0-0002hl-E2 for xen-users@lists.xen.org; Wed, 15 Jul 2015 14:20:32 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id 95/23-25653-F2C66A55; Wed, 15 Jul 2015 14:20:31 +0000 X-Env-Sender: prvs=631330d48=Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1436970029!21339938!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 15 Jul 2015 14:20:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 14:20:30 -0000 X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="281214043" Message-ID: <1436970026.32371.91.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 15 Jul 2015 15:20:26 +0100 In-Reply-To: <55A65412.6020103@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> <1436863402.25044.32.camel@citrix.com> <55A65412.6020103@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-15 at 08:37 -0400, Brandon Perez wrote: > On 07/14/2015 04:43 AM, Ian Campbell wrote: > > On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: > >> On 07/13/2015 04:29 AM, Ian Campbell wrote: > >>> On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > >>> > >>> Is there a 1:1 mapping between (active) interrupts handled by this > >>> cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > >>> SPIs would you only be able to use 16 of the devices? > >>> > >>> Or does it support multiple interrupt sources triggering a single SPI? > >> > >> For the chip I'm working with, it only supports a 1:1 mapping. It > >> doesn't allow for multiple interrupts to share an SPI line. > > > > This simplifies things somewhat for passthrough then, I think. You > > simply leave routing and assignment of interrupts to SPIs in the hands > > of dom0, and on passthrough it would pass the SPI to the guest with > > appropriate values for the interrupt-parent and interrupts properties. > > > >>> Right, this is a tricky one. Other than various solutions involving > >>> trusting the firmware to get it right and requiring dom0 to not muck > >>> around with it the only other solution I can think of would be a bit of > >>> code in Xen which traps dom0's attempted changes and validates them, > >>> preventing dom0 from mucking with the ones Xen cares about. > >>> > >>> Given how simple these sorts of interrupt remappers often are that might > >>> not even be that much code. > >>> > >>> Ian. > >>> > >> > >> I think that wouldn't be too difficult to do, but for now, I'm > >> going to stick with using the device tree to inform Xen and the Kernel. > > > > Sure. > > > > Hi Ian, > > This question pertains to what we've been talking about, so I'm > going to keep it on this thread. > > I was hoping to get some clarification on how secondary interrupts > are passed to Dom0 by Xen. I think I should start by clarifying: Yours is the first platform we've (or at least I've) come across which has this requirement and wants to run Xen. So the answer may we be something like "not well" or "my sheer coincidence"... > My current understanding is as follows. When > Xen constructs Dom0, it goes through each entry in the device tree. It > then reads out each entry in the "interrupts" property. If the device is > connected to the primary interrupt controller, then Xen performs the > necessary steps to allocate the IRQ to the guest, and then route it to > the guest also. Otherwise, if the controller is not the primary one, > then Xen does nothing. This all happens in handle_device(). Yes, I think that's mostly right. Recently I added support for handling the interrupt-map field for nodes with device_type = "pci" (i.e. PCI buses), but this is limited to PCI. It could perhaps be made more general. > Here's where my understanding becomes a little less clear. Later > on, the kernel will boot, and as needed, will write to its vGIC. This > will be trapped into Xen as a data abort, and handled as an MMIO write. > Eventually, it makes its way to the function gicv2_irq_enable(), which > actually writes to the vGIC and GIC to enable said interrupt. Does this > sound right, or am I missing some key components? That sounds about correct, yes. > I'm attempting to enable the kernel to handle the mapping and > routing of IRQ's on the crossbar. So, what I'm doing is, for each device > in the DT that is a peripheral device (SPI), I'm changing its > "interrupt-parent" property to be a device node representing the crossbar. the "crossbar" is the thing which takes some pool of interrupts coming from devices and maps them into specific SPIs in the GIC, is that right? Does the node representing the cross-bar have the correct interrupt-parent, i.e. pointing to the GIC? If you change the interrupt-parent then I think you likely also need to change the interrupts property, since it now needs to refer to things in the "input irq space" of the cross bar and not the output (AKA SPIs). The format for an interrupt-entry is defined by the interrupt-parent, which includes the #interrupt-cells, but also the meaning of those cells, which is defined in the relevant bindings. e.g. for GIC it is https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/gic.txt which declares that #interrupt-cells shall be 3 and they will be (type, nr, flags). What I'm not sure about is how bindings are defined for interrupt controllers which can map inputs to outputs dynamically, since the DT cannot express that. Perhaps a specific driver is therefore needed. If you are changing device tree things then you should take a look at ePAPR which is the spec used on PPC which defined the framework for a lot of this stuff. It might have some info about dynamic interrupts too. > However, this is leading to data aborts and/or interrupts not being > delivered to the kernel. Either the kernel encounters a data abort > (presumably due to the fact that it does not have permission for the > IRQ), or I find the kernel running in "idle_loop()" (which in my > experience means its waiting for an interrupt to be delivered). I wouldn't expect a data abort from an access to the vgic, even if the interrupt corresponding to the register isn't allowed to the guest. Do you have your DT and kernel modifications working natively, i.e. without Xen underneath? > Is the functionality in Xen to allow me to passthrough secondary > interrupts like this, or will some changes be needed? Almost certainly changes will be needed. > If so, could you point me in the right direction? I can try, although it is getting outside the realms of my device-tree knowledge it seems. In any case it would be a lot easier to advise on the Xen specific aspects if I could see the code changes and the device tree etc. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 14:21:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 14:21:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFNY1-0002i2-MQ; Wed, 15 Jul 2015 14:20:33 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFNY0-0002hl-E2 for xen-users@lists.xen.org; Wed, 15 Jul 2015 14:20:32 +0000 Received: from [85.158.139.211] by server-8.bemta-5.messagelabs.com id 95/23-25653-F2C66A55; Wed, 15 Jul 2015 14:20:31 +0000 X-Env-Sender: prvs=631330d48=Ian.Campbell@citrix.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1436970029!21339938!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22099 invoked from network); 15 Jul 2015 14:20:30 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-12.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 14:20:30 -0000 X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="281214043" Message-ID: <1436970026.32371.91.camel@citrix.com> From: Ian Campbell To: Brandon Perez Date: Wed, 15 Jul 2015 15:20:26 +0100 In-Reply-To: <55A65412.6020103@ti.com> References: <559560F8.7070001@ti.com> <5596645D.7030401@citrix.com> <559AB900.3050403@ti.com> <559BD9EF.4060902@citrix.com> <559BD5B5.70308@ti.com> <559C28D5.3040203@ti.com> <559C3D1F.3040300@ti.com> <1436344210.25646.274.camel@citrix.com> <559D25AC.5080706@ti.com> <1436366449.23508.59.camel@citrix.com> <559D2B9E.50405@ti.com> <1436367656.23508.65.camel@citrix.com> <559D2EA2.9050400@ti.com> <559D3F44.5080607@citrix.com> <559D357D.3030002@ti.com> <1436443588.23508.127.camel@citrix.com> <559E7D63.3050804@ti.com> <559E9362.3000402@citrix.com> <559E90A7.7010809@ti.com> <1436520645.23508.193.camel@citrix.com> <559FE2FE.8050608@ti.com> <1436776174.7019.25.camel@citrix.com> <55A3B02E.7050206@ti.com> <1436863402.25044.32.camel@citrix.com> <55A65412.6020103@ti.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , xen-users@lists.xen.org Subject: Re: [Xen-users] Issues Booting DomU on TI DRA72 Chip X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-15 at 08:37 -0400, Brandon Perez wrote: > On 07/14/2015 04:43 AM, Ian Campbell wrote: > > On Mon, 2015-07-13 at 08:33 -0400, Brandon Perez wrote: > >> On 07/13/2015 04:29 AM, Ian Campbell wrote: > >>> On Fri, 2015-07-10 at 11:21 -0400, Brandon Perez wrote: > >>> > >>> Is there a 1:1 mapping between (active) interrupts handled by this > >>> cascaded controller a SPIs? i.e. if there were 32 interrupts but only 16 > >>> SPIs would you only be able to use 16 of the devices? > >>> > >>> Or does it support multiple interrupt sources triggering a single SPI? > >> > >> For the chip I'm working with, it only supports a 1:1 mapping. It > >> doesn't allow for multiple interrupts to share an SPI line. > > > > This simplifies things somewhat for passthrough then, I think. You > > simply leave routing and assignment of interrupts to SPIs in the hands > > of dom0, and on passthrough it would pass the SPI to the guest with > > appropriate values for the interrupt-parent and interrupts properties. > > > >>> Right, this is a tricky one. Other than various solutions involving > >>> trusting the firmware to get it right and requiring dom0 to not muck > >>> around with it the only other solution I can think of would be a bit of > >>> code in Xen which traps dom0's attempted changes and validates them, > >>> preventing dom0 from mucking with the ones Xen cares about. > >>> > >>> Given how simple these sorts of interrupt remappers often are that might > >>> not even be that much code. > >>> > >>> Ian. > >>> > >> > >> I think that wouldn't be too difficult to do, but for now, I'm > >> going to stick with using the device tree to inform Xen and the Kernel. > > > > Sure. > > > > Hi Ian, > > This question pertains to what we've been talking about, so I'm > going to keep it on this thread. > > I was hoping to get some clarification on how secondary interrupts > are passed to Dom0 by Xen. I think I should start by clarifying: Yours is the first platform we've (or at least I've) come across which has this requirement and wants to run Xen. So the answer may we be something like "not well" or "my sheer coincidence"... > My current understanding is as follows. When > Xen constructs Dom0, it goes through each entry in the device tree. It > then reads out each entry in the "interrupts" property. If the device is > connected to the primary interrupt controller, then Xen performs the > necessary steps to allocate the IRQ to the guest, and then route it to > the guest also. Otherwise, if the controller is not the primary one, > then Xen does nothing. This all happens in handle_device(). Yes, I think that's mostly right. Recently I added support for handling the interrupt-map field for nodes with device_type = "pci" (i.e. PCI buses), but this is limited to PCI. It could perhaps be made more general. > Here's where my understanding becomes a little less clear. Later > on, the kernel will boot, and as needed, will write to its vGIC. This > will be trapped into Xen as a data abort, and handled as an MMIO write. > Eventually, it makes its way to the function gicv2_irq_enable(), which > actually writes to the vGIC and GIC to enable said interrupt. Does this > sound right, or am I missing some key components? That sounds about correct, yes. > I'm attempting to enable the kernel to handle the mapping and > routing of IRQ's on the crossbar. So, what I'm doing is, for each device > in the DT that is a peripheral device (SPI), I'm changing its > "interrupt-parent" property to be a device node representing the crossbar. the "crossbar" is the thing which takes some pool of interrupts coming from devices and maps them into specific SPIs in the GIC, is that right? Does the node representing the cross-bar have the correct interrupt-parent, i.e. pointing to the GIC? If you change the interrupt-parent then I think you likely also need to change the interrupts property, since it now needs to refer to things in the "input irq space" of the cross bar and not the output (AKA SPIs). The format for an interrupt-entry is defined by the interrupt-parent, which includes the #interrupt-cells, but also the meaning of those cells, which is defined in the relevant bindings. e.g. for GIC it is https://git.kernel.org/cgit/linux/kernel/git/devicetree/devicetree-rebasing.git/tree/Bindings/arm/gic.txt which declares that #interrupt-cells shall be 3 and they will be (type, nr, flags). What I'm not sure about is how bindings are defined for interrupt controllers which can map inputs to outputs dynamically, since the DT cannot express that. Perhaps a specific driver is therefore needed. If you are changing device tree things then you should take a look at ePAPR which is the spec used on PPC which defined the framework for a lot of this stuff. It might have some info about dynamic interrupts too. > However, this is leading to data aborts and/or interrupts not being > delivered to the kernel. Either the kernel encounters a data abort > (presumably due to the fact that it does not have permission for the > IRQ), or I find the kernel running in "idle_loop()" (which in my > experience means its waiting for an interrupt to be delivered). I wouldn't expect a data abort from an access to the vgic, even if the interrupt corresponding to the register isn't allowed to the guest. Do you have your DT and kernel modifications working natively, i.e. without Xen underneath? > Is the functionality in Xen to allow me to passthrough secondary > interrupts like this, or will some changes be needed? Almost certainly changes will be needed. > If so, could you point me in the right direction? I can try, although it is getting outside the realms of my device-tree knowledge it seems. In any case it would be a lot easier to advise on the Xen specific aspects if I could see the code changes and the device tree etc. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:26:21 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:26:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOYl-00015A-80; Wed, 15 Jul 2015 15:25:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOYj-000154-W2 for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:25:22 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 74/1F-21300-16B76A55; Wed, 15 Jul 2015 15:25:21 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436973920!32330624!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24249 invoked from network); 15 Jul 2015 15:25:20 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:25:20 -0000 Received: by lagx9 with SMTP id x9so26868150lag.1 for ; Wed, 15 Jul 2015 08:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=worC8rM9gsOQ+NRpywG91iFKWhy/HX2kJOFvqmNhoLY=; b=GnBh1oauEIya8mj99+g+kB9C4ZQgeWyph7ogNW2CY4rCjo8mcVEgne4+NrJWyqnZZB c9gsLu9qPohDQAvSRY+D4qkSbPZDmkfTnBpbU6qnbwgO8ANi+k9dSic9jeRLK8ZNwUBr 55g3lvhZ7h5zGvXrLUogWsJdN7Pj8t7sJPn0d+/ztBTVxZIP4Q5gLRIEcKE/YQeELdwf 5b3Lv206qnd7SNmIQd+shI0R8AEy6S0vmbDpaBQk/cbOI0xmZaD34NPUkeB7efXinfrl 4Y4eIeB4AmKOyGPm9we+pYwGUTfkkIkwdulKN/QpEn5ghA+e6hlK8SlAZ5X1LuEEZSJ7 zmpA== X-Received: by 10.112.25.69 with SMTP id a5mr4710585lbg.16.1436973919761; Wed, 15 Jul 2015 08:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 08:25:00 -0700 (PDT) From: John Paul Walters Date: Wed, 15 Jul 2015 11:25:00 -0400 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, I'm trying to boot Xen on the ARM Juno r0 board and I'm running into some difficulties. I've built xen and a Xen-enabled Dom0 kernel. I've confirmed that the dom0 kernel boots outside of Xen. I'm aware of a prior thread involving issues booting Xen from the EFI boot menu: http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg02525.html As you can see from below, I'm avoiding this issue by starting Xen directly from the EFI shell. I'm using ARM's latest distributed firmware as opposed to Linaro's. Are there particular Xen dependencies on one versus the other? It appears that I'm running into at least a couple of issues. First is that only a single CPU is brought up. Second is that the dom0 kernel appears to crash early in the boot process. Has anyone successfully booted Xen on the Juno board recently? thanks, JP UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) [1] Linux from NOR Flash [2] Debian ARMv8 [3] KVM [4] Xen from NOR Flash [5] Shell [6] Boot Manager Start: 5 UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) Mapping table FS2: Alias(s):F10:;BLK1: VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) FS0: Alias(s):F3: MemoryMapped(0xB,0xE0000000,0xE00EFFFF) FS1: Alias(s):F4: MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) BLK0: Alias(s): VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) Shell> fs2: FS2:\> xen -cfg=cfg 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader junoX: 0x00000009faf87000-0x00000009faf89b89 ImageX: 0x00000009fa3ce000-0x00000009fac07000 Xen 4.5.1 (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Error: PSCI version 0x10000 is not supported. (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 16 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -1) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -1) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -1) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -1) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -1) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa3ce000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 280kB init memory. (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:26:21 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:26:21 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOYl-00015A-80; Wed, 15 Jul 2015 15:25:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOYj-000154-W2 for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:25:22 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 74/1F-21300-16B76A55; Wed, 15 Jul 2015 15:25:21 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436973920!32330624!1 X-Originating-IP: [209.85.215.41] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24249 invoked from network); 15 Jul 2015 15:25:20 -0000 Received: from mail-la0-f41.google.com (HELO mail-la0-f41.google.com) (209.85.215.41) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:25:20 -0000 Received: by lagx9 with SMTP id x9so26868150lag.1 for ; Wed, 15 Jul 2015 08:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=worC8rM9gsOQ+NRpywG91iFKWhy/HX2kJOFvqmNhoLY=; b=GnBh1oauEIya8mj99+g+kB9C4ZQgeWyph7ogNW2CY4rCjo8mcVEgne4+NrJWyqnZZB c9gsLu9qPohDQAvSRY+D4qkSbPZDmkfTnBpbU6qnbwgO8ANi+k9dSic9jeRLK8ZNwUBr 55g3lvhZ7h5zGvXrLUogWsJdN7Pj8t7sJPn0d+/ztBTVxZIP4Q5gLRIEcKE/YQeELdwf 5b3Lv206qnd7SNmIQd+shI0R8AEy6S0vmbDpaBQk/cbOI0xmZaD34NPUkeB7efXinfrl 4Y4eIeB4AmKOyGPm9we+pYwGUTfkkIkwdulKN/QpEn5ghA+e6hlK8SlAZ5X1LuEEZSJ7 zmpA== X-Received: by 10.112.25.69 with SMTP id a5mr4710585lbg.16.1436973919761; Wed, 15 Jul 2015 08:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 08:25:00 -0700 (PDT) From: John Paul Walters Date: Wed, 15 Jul 2015 11:25:00 -0400 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, I'm trying to boot Xen on the ARM Juno r0 board and I'm running into some difficulties. I've built xen and a Xen-enabled Dom0 kernel. I've confirmed that the dom0 kernel boots outside of Xen. I'm aware of a prior thread involving issues booting Xen from the EFI boot menu: http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg02525.html As you can see from below, I'm avoiding this issue by starting Xen directly from the EFI shell. I'm using ARM's latest distributed firmware as opposed to Linaro's. Are there particular Xen dependencies on one versus the other? It appears that I'm running into at least a couple of issues. First is that only a single CPU is brought up. Second is that the dom0 kernel appears to crash early in the boot process. Has anyone successfully booted Xen on the Juno board recently? thanks, JP UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) [1] Linux from NOR Flash [2] Debian ARMv8 [3] KVM [4] Xen from NOR Flash [5] Shell [6] Boot Manager Start: 5 UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) Mapping table FS2: Alias(s):F10:;BLK1: VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) FS0: Alias(s):F3: MemoryMapped(0xB,0xE0000000,0xE00EFFFF) FS1: Alias(s):F4: MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) BLK0: Alias(s): VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) Shell> fs2: FS2:\> xen -cfg=cfg 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader junoX: 0x00000009faf87000-0x00000009faf89b89 ImageX: 0x00000009fa3ce000-0x00000009fac07000 Xen 4.5.1 (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Error: PSCI version 0x10000 is not supported. (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 16 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -1) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -1) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -1) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -1) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -1) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa3ce000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: Errors and warnings (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 280kB init memory. (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch input to DOM0) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:35:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:35:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOiY-0002mJ-5A; Wed, 15 Jul 2015 15:35:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOiX-0002m9-9D for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:35:29 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 56/5A-18676-0CD76A55; Wed, 15 Jul 2015 15:35:28 +0000 X-Env-Sender: prvs=631330d48=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436974526!32388102!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18168 invoked from network); 15 Jul 2015 15:35:27 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:35:27 -0000 X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="284364091" Message-ID: <1436974518.32371.116.camel@citrix.com> From: Ian Campbell To: John Paul Walters Date: Wed, 15 Jul 2015 16:35:18 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-15 at 11:25 -0400, John Paul Walters wrote: > Hi all, > > I'm trying to boot Xen on the ARM Juno r0 board and I'm running into > some difficulties. I've built xen and a Xen-enabled Dom0 kernel. > I've confirmed that the dom0 kernel boots outside of Xen. > > I'm aware of a prior thread involving issues booting Xen from the EFI boot menu: > http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg02525.html > > As you can see from below, I'm avoiding this issue by starting Xen > directly from the EFI shell. I'm using ARM's latest distributed > firmware as opposed to Linaro's. Are there particular Xen > dependencies on one versus the other? Not AFAIK. > It appears that I'm running into at least a couple of issues. First > is that only a single CPU is brought up. Second is that the dom0 > kernel appears to crash early in the boot process. Has anyone > successfully booted Xen on the Juno board recently? I've not tried for several months I'm afraid. Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra info. It would also be useful to see your file "cfg", in particular the various command lines which it will contain. I take it your dom0 kernel binary boot successfully with all CPUs natively? > > thanks, > JP > > UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) > [1] Linux from NOR Flash > [2] Debian ARMv8 > [3] KVM > [4] Xen from NOR Flash > [5] Shell > [6] Boot Manager > Start: 5 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) > Mapping table > FS2: Alias(s):F10:;BLK1: > VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > FS0: Alias(s):F3: > MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > FS1: Alias(s):F4: > MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) > BLK0: Alias(s): > VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > Shell> fs2: > FS2:\> xen -cfg=cfg > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader > junoX: 0x00000009faf87000-0x00000009faf89b89 > ImageX: 0x00000009fa3ce000-0x00000009fac07000 > Xen 4.5.1 > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Error: PSCI version 0x10000 is not supported. > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 16 KiB. > (XEN) Bringing up CPU1 > (XEN) Failed to bring up CPU1 > (XEN) Failed to bring up CPU 1 (error -1) > (XEN) Bringing up CPU2 > (XEN) Failed to bring up CPU2 > (XEN) Failed to bring up CPU 2 (error -1) > (XEN) Bringing up CPU3 > (XEN) Failed to bring up CPU3 > (XEN) Failed to bring up CPU 3 (error -1) > (XEN) Bringing up CPU4 > (XEN) Failed to bring up CPU4 > (XEN) Failed to bring up CPU 4 (error -1) > (XEN) Bringing up CPU5 > (XEN) Failed to bring up CPU5 > (XEN) Failed to bring up CPU 5 (error -1) > (XEN) Brought up 1 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa3ce000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > (XEN) ................................................................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 280kB init memory. > (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch > input to DOM0) > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:35:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:35:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOiY-0002mJ-5A; Wed, 15 Jul 2015 15:35:30 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFOiX-0002m9-9D for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:35:29 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 56/5A-18676-0CD76A55; Wed, 15 Jul 2015 15:35:28 +0000 X-Env-Sender: prvs=631330d48=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1436974526!32388102!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18168 invoked from network); 15 Jul 2015 15:35:27 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:35:27 -0000 X-IronPort-AV: E=Sophos;i="5.15,480,1432598400"; d="scan'208";a="284364091" Message-ID: <1436974518.32371.116.camel@citrix.com> From: Ian Campbell To: John Paul Walters Date: Wed, 15 Jul 2015 16:35:18 +0100 In-Reply-To: References: X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-15 at 11:25 -0400, John Paul Walters wrote: > Hi all, > > I'm trying to boot Xen on the ARM Juno r0 board and I'm running into > some difficulties. I've built xen and a Xen-enabled Dom0 kernel. > I've confirmed that the dom0 kernel boots outside of Xen. > > I'm aware of a prior thread involving issues booting Xen from the EFI boot menu: > http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg02525.html > > As you can see from below, I'm avoiding this issue by starting Xen > directly from the EFI shell. I'm using ARM's latest distributed > firmware as opposed to Linaro's. Are there particular Xen > dependencies on one versus the other? Not AFAIK. > It appears that I'm running into at least a couple of issues. First > is that only a single CPU is brought up. Second is that the dom0 > kernel appears to crash early in the boot process. Has anyone > successfully booted Xen on the Juno board recently? I've not tried for several months I'm afraid. Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra info. It would also be useful to see your file "cfg", in particular the various command lines which it will contain. I take it your dom0 kernel binary boot successfully with all CPUs natively? > > thanks, > JP > > UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) > [1] Linux from NOR Flash > [2] Debian ARMv8 > [3] KVM > [4] Xen from NOR Flash > [5] Shell > [6] Boot Manager > Start: 5 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) > Mapping table > FS2: Alias(s):F10:;BLK1: > VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > FS0: Alias(s):F3: > MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > FS1: Alias(s):F4: > MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) > BLK0: Alias(s): > VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > Shell> fs2: > FS2:\> xen -cfg=cfg > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader > junoX: 0x00000009faf87000-0x00000009faf89b89 > ImageX: 0x00000009fa3ce000-0x00000009fac07000 > Xen 4.5.1 > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Error: PSCI version 0x10000 is not supported. > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 16 KiB. > (XEN) Bringing up CPU1 > (XEN) Failed to bring up CPU1 > (XEN) Failed to bring up CPU 1 (error -1) > (XEN) Bringing up CPU2 > (XEN) Failed to bring up CPU2 > (XEN) Failed to bring up CPU 2 (error -1) > (XEN) Bringing up CPU3 > (XEN) Failed to bring up CPU3 > (XEN) Failed to bring up CPU 3 (error -1) > (XEN) Bringing up CPU4 > (XEN) Failed to bring up CPU4 > (XEN) Failed to bring up CPU 4 (error -1) > (XEN) Bringing up CPU5 > (XEN) Failed to bring up CPU5 > (XEN) Failed to bring up CPU 5 (error -1) > (XEN) Brought up 1 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa3ce000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > (XEN) ................................................................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: Errors and warnings > (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 280kB init memory. > (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch > input to DOM0) > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:54:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:54:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFP0y-0000Fm-2L; Wed, 15 Jul 2015 15:54:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFP0w-0000FA-5T for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:54:30 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id E3/B5-11060-53286A55; Wed, 15 Jul 2015 15:54:29 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1436975668!26123863!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15479 invoked from network); 15 Jul 2015 15:54:28 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:54:28 -0000 Received: by lbbyj8 with SMTP id yj8so27671667lbb.0 for ; Wed, 15 Jul 2015 08:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BitqKDTXQgFnBewRls8Em205Ps2OA8dicOWrwkW7Qes=; b=tP7YiTVUiOg1MCYxIFK4SL/gdpV4SQkPVV8ttCmEwiavGbvdDWhZl+o9daQKFQrcMc UDIqqTWMUEPQt2UEN8XRlpCyq58QVbkEQBiNIlPBMHNkUcSkvs2Iw66kqG0sgdvH7YxA P+KYWGWAN8qfHfs5fcop37bnF+m/BCNce1Q2oeLAZcSerJAvdWfVeRWXiMnf3ZKD+JI/ xLl2fDZTuf/bOU4K2oZSJ7mu8m6y74Jr4AxaFH7hw74TGr8n5ZhqAMX08dqzDkPW2qGi WUQUXnixNK69o7UAM/p3z6SZ/DuwISFfCLd8wF1yriXMSwqCErT63PvD52rE7ibREsW3 oNzA== X-Received: by 10.112.171.68 with SMTP id as4mr4857542lbc.64.1436975668375; Wed, 15 Jul 2015 08:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 08:54:08 -0700 (PDT) In-Reply-To: <1436974518.32371.116.camel@citrix.com> References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Wed, 15 Jul 2015 11:54:08 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Ian, > > Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra > info. It would also be useful to see your file "cfg", in particular the > various command lines which it will contain. > I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but to answer your other questions, my cfg file: [global] default=default [default] options=console=dtuart dtuart=serial0 conswitch=x kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 dtb=junoX I copied that from the link I referenced earlier, I believe. The only differences are that I differentiated my default kernel and dtb from the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My root device is indeed /dev/sda3. > I take it your dom0 kernel binary boot successfully with all CPUs > natively? Yes, my dom0 kernel boots all CPUs successfully. I didn't really exercise them, but I can see all six of them. > >> >> thanks, >> JP >> >> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >> [1] Linux from NOR Flash >> [2] Debian ARMv8 >> [3] KVM >> [4] Xen from NOR Flash >> [5] Shell >> [6] Boot Manager >> Start: 5 >> UEFI Interactive Shell v2.1 >> EDK II >> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >> Mapping table >> FS2: Alias(s):F10:;BLK1: >> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >> FS0: Alias(s):F3: >> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >> FS1: Alias(s):F4: >> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >> BLK0: Alias(s): >> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >> Shell> fs2: >> FS2:\> xen -cfg=cfg >> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >> junoX: 0x00000009faf87000-0x00000009faf89b89 >> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >> Xen 4.5.1 >> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >> (XEN) 64-bit Execution: >> (XEN) Processor Features: 0000000000002222 0000000000000000 >> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >> (XEN) Extensions: FloatingPoint AdvancedSIMD >> (XEN) Debug Features: 0000000010305106 0000000000000000 >> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >> (XEN) ISA Features: 0000000000011120 0000000000000000 >> (XEN) 32-bit Execution: >> (XEN) Processor Features: 00000131:00011011 >> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >> (XEN) Extensions: GenericTimer Security >> (XEN) Debug Features: 03010066 >> (XEN) Auxiliary Features: 00000000 >> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >> (XEN) Error: PSCI version 0x10000 is not supported. >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >> (XEN) Using generic timer at 50000 KHz >> (XEN) GICv2 initialization: >> (XEN) gic_dist_addr=000000002c010000 >> (XEN) gic_cpu_addr=000000002c02f000 >> (XEN) gic_hyp_addr=000000002c04f000 >> (XEN) gic_vcpu_addr=000000002c06f000 >> (XEN) gic_maintenance_irq=25 >> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) I/O virtualisation disabled >> (XEN) Allocated console ring of 16 KiB. >> (XEN) Bringing up CPU1 >> (XEN) Failed to bring up CPU1 >> (XEN) Failed to bring up CPU 1 (error -1) >> (XEN) Bringing up CPU2 >> (XEN) Failed to bring up CPU2 >> (XEN) Failed to bring up CPU 2 (error -1) >> (XEN) Bringing up CPU3 >> (XEN) Failed to bring up CPU3 >> (XEN) Failed to bring up CPU 3 (error -1) >> (XEN) Bringing up CPU4 >> (XEN) Failed to bring up CPU4 >> (XEN) Failed to bring up CPU 4 (error -1) >> (XEN) Bringing up CPU5 >> (XEN) Failed to bring up CPU5 >> (XEN) Failed to bring up CPU 5 (error -1) >> (XEN) Brought up 1 CPUs >> (XEN) P2M: 40-bit IPA with 40-bit PA >> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >> (XEN) *** LOADING DOMAIN 0 *** >> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >> (XEN) ................................................................done. >> (XEN) Initial low memory virq threshold set at 0x4000 pages. >> (XEN) Std. Loglevel: Errors and warnings >> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >> input to Xen) >> (XEN) Freed 280kB init memory. >> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >> input to DOM0) >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 15:54:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 15:54:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFP0y-0000Fm-2L; Wed, 15 Jul 2015 15:54:32 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFP0w-0000FA-5T for xen-users@lists.xen.org; Wed, 15 Jul 2015 15:54:30 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id E3/B5-11060-53286A55; Wed, 15 Jul 2015 15:54:29 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1436975668!26123863!1 X-Originating-IP: [209.85.217.171] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15479 invoked from network); 15 Jul 2015 15:54:28 -0000 Received: from mail-lb0-f171.google.com (HELO mail-lb0-f171.google.com) (209.85.217.171) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 15:54:28 -0000 Received: by lbbyj8 with SMTP id yj8so27671667lbb.0 for ; Wed, 15 Jul 2015 08:54:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BitqKDTXQgFnBewRls8Em205Ps2OA8dicOWrwkW7Qes=; b=tP7YiTVUiOg1MCYxIFK4SL/gdpV4SQkPVV8ttCmEwiavGbvdDWhZl+o9daQKFQrcMc UDIqqTWMUEPQt2UEN8XRlpCyq58QVbkEQBiNIlPBMHNkUcSkvs2Iw66kqG0sgdvH7YxA P+KYWGWAN8qfHfs5fcop37bnF+m/BCNce1Q2oeLAZcSerJAvdWfVeRWXiMnf3ZKD+JI/ xLl2fDZTuf/bOU4K2oZSJ7mu8m6y74Jr4AxaFH7hw74TGr8n5ZhqAMX08dqzDkPW2qGi WUQUXnixNK69o7UAM/p3z6SZ/DuwISFfCLd8wF1yriXMSwqCErT63PvD52rE7ibREsW3 oNzA== X-Received: by 10.112.171.68 with SMTP id as4mr4857542lbc.64.1436975668375; Wed, 15 Jul 2015 08:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 08:54:08 -0700 (PDT) In-Reply-To: <1436974518.32371.116.camel@citrix.com> References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Wed, 15 Jul 2015 11:54:08 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Ian, > > Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra > info. It would also be useful to see your file "cfg", in particular the > various command lines which it will contain. > I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but to answer your other questions, my cfg file: [global] default=default [default] options=console=dtuart dtuart=serial0 conswitch=x kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 dtb=junoX I copied that from the link I referenced earlier, I believe. The only differences are that I differentiated my default kernel and dtb from the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My root device is indeed /dev/sda3. > I take it your dom0 kernel binary boot successfully with all CPUs > natively? Yes, my dom0 kernel boots all CPUs successfully. I didn't really exercise them, but I can see all six of them. > >> >> thanks, >> JP >> >> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >> [1] Linux from NOR Flash >> [2] Debian ARMv8 >> [3] KVM >> [4] Xen from NOR Flash >> [5] Shell >> [6] Boot Manager >> Start: 5 >> UEFI Interactive Shell v2.1 >> EDK II >> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >> Mapping table >> FS2: Alias(s):F10:;BLK1: >> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >> FS0: Alias(s):F3: >> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >> FS1: Alias(s):F4: >> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >> BLK0: Alias(s): >> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >> Shell> fs2: >> FS2:\> xen -cfg=cfg >> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >> junoX: 0x00000009faf87000-0x00000009faf89b89 >> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >> Xen 4.5.1 >> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >> (XEN) 64-bit Execution: >> (XEN) Processor Features: 0000000000002222 0000000000000000 >> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >> (XEN) Extensions: FloatingPoint AdvancedSIMD >> (XEN) Debug Features: 0000000010305106 0000000000000000 >> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >> (XEN) ISA Features: 0000000000011120 0000000000000000 >> (XEN) 32-bit Execution: >> (XEN) Processor Features: 00000131:00011011 >> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >> (XEN) Extensions: GenericTimer Security >> (XEN) Debug Features: 03010066 >> (XEN) Auxiliary Features: 00000000 >> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >> (XEN) Error: PSCI version 0x10000 is not supported. >> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >> (XEN) Using generic timer at 50000 KHz >> (XEN) GICv2 initialization: >> (XEN) gic_dist_addr=000000002c010000 >> (XEN) gic_cpu_addr=000000002c02f000 >> (XEN) gic_hyp_addr=000000002c04f000 >> (XEN) gic_vcpu_addr=000000002c06f000 >> (XEN) gic_maintenance_irq=25 >> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >> (XEN) Using scheduler: SMP Credit Scheduler (credit) >> (XEN) I/O virtualisation disabled >> (XEN) Allocated console ring of 16 KiB. >> (XEN) Bringing up CPU1 >> (XEN) Failed to bring up CPU1 >> (XEN) Failed to bring up CPU 1 (error -1) >> (XEN) Bringing up CPU2 >> (XEN) Failed to bring up CPU2 >> (XEN) Failed to bring up CPU 2 (error -1) >> (XEN) Bringing up CPU3 >> (XEN) Failed to bring up CPU3 >> (XEN) Failed to bring up CPU 3 (error -1) >> (XEN) Bringing up CPU4 >> (XEN) Failed to bring up CPU4 >> (XEN) Failed to bring up CPU 4 (error -1) >> (XEN) Bringing up CPU5 >> (XEN) Failed to bring up CPU5 >> (XEN) Failed to bring up CPU 5 (error -1) >> (XEN) Brought up 1 CPUs >> (XEN) P2M: 40-bit IPA with 40-bit PA >> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >> (XEN) *** LOADING DOMAIN 0 *** >> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >> (XEN) ................................................................done. >> (XEN) Initial low memory virq threshold set at 0x4000 pages. >> (XEN) Std. Loglevel: Errors and warnings >> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >> input to Xen) >> (XEN) Freed 280kB init memory. >> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >> input to DOM0) >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 20:42:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 20:42:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFTUh-0006AH-0x; Wed, 15 Jul 2015 20:41:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFTUg-0006AA-23 for xen-users@lists.xen.org; Wed, 15 Jul 2015 20:41:30 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id E4/38-03371-975C6A55; Wed, 15 Jul 2015 20:41:29 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436992887!32397841!1 X-Originating-IP: [209.85.215.42] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5511 invoked from network); 15 Jul 2015 20:41:28 -0000 Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 20:41:28 -0000 Received: by lagx9 with SMTP id x9so31824327lag.1 for ; Wed, 15 Jul 2015 13:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xbewHzFYYWTdwrM+TnaiOFA7VS6EKBlT9MqlHdytc/4=; b=0Xykl6Mw+K+yMDW4KbaNWt45V7ULSbP1gH1FvGGxEwL9+BL9u4lHYCLcq5QsX3v/zM /JXy97eQDMWWt4zu2QBm/iAJ3dLuz0SN2rf3W30YjyBxq8feu7+hwsrONEMczGWpZMAs Kgk8ilH8TB5uITFsimLfPx08gt6Bl6QpbWraDc5si5u+auM/gFk0a4F8ix4uZDmCW4At X0VQ5tb4RiUOFX0VIIVU6nFvQsDUAWAthgQGhV+Q8ctkq2MbTj46V2BOBQ0Ym/6ak4U5 MmmBqjB0z24Ftn3VdIJ9UW+hfKbjO1tIkJbgUlMKn+a693afDDo4TBlMROujAb5S2rzj 7Bpw== X-Received: by 10.152.87.231 with SMTP id bb7mr5984441lab.16.1436992887324; Wed, 15 Jul 2015 13:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 13:41:07 -0700 (PDT) In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Wed, 15 Jul 2015 16:41:07 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I've included the output of building xen with debug=y and CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional CPUs aren't coming up, but I noticed an error message early in the Xen output: (XEN) Error: PSCI version 0x10000 is not supported. Then the dom0 kernel appears to crash inside of some PSCI initialization: (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: [] psci_init+0x2c/0x40 (XEN) DOM0: [] setup_arch+0x420/0x5ac (XEN) DOM0: [] start_kernel+0xa0/0x3a4 Any suggestions would be welcome. thanks, JP FS2:\> xen -cfg=cfg 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader junoX: 0x00000009faf87000-0x00000009faf89b89 ImageX: 0x00000009fa3be000-0x00000009fabf7000 - UART enabled - - CPU 00000100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000dfffffff (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff (XEN) RAM: 00000000feba0000 - 00000000febabfff (XEN) RAM: 00000000febac000 - 00000000feffffff (XEN) RAM: 0000000880000000 - 00000009fa3bdfff (XEN) RAM: 00000009fade9000 - 00000009faecffff (XEN) RAM: 00000009faf80000 - 00000009faf82fff (XEN) RAM: 00000009faf87000 - 00000009faf8afff (XEN) RAM: 00000009faf8c000 - 00000009febe3fff (XEN) RAM: 00000009febe4000 - 00000009ff142fff (XEN) RAM: 00000009ff143000 - 00000009ff144fff (XEN) RAM: 00000009ff145000 - 00000009ff16dfff (XEN) RAM: 00000009ff16e000 - 00000009ff170fff (XEN) RAM: 00000009ff171000 - 00000009ffdbffff (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff (XEN) RAM: 00000009fff90000 - 00000009fff9ffff (XEN) RAM: 00000009ffff0000 - 00000009ffffefff (XEN) RAM: 00000009fffff000 - 00000009ffffffff (XEN) (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 (XEN) (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => 00000000dfe00000-00000000dff0ad81 (XEN) PFN compression on bits 21...22 (XEN) Domain heap initialised (XEN) Looking for UART console serial0 Xen 4.5.1 (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: VERSATILE EXPRESS (XEN) Error: PSCI version 0x10000 is not supported. (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -1) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -1) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -1) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -1) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -1) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa3be000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) DOM0: Booting Linux on physical CPU 0x0 (XEN) DOM0: Initializing cgroup subsys cpu (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 (XEN) DOM0: (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 (XEN) DOM0: Detected VIPT I-cache on CPU0 (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, 827319, 824069 (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') (XEN) DOM0: bootconsole [uart0] enabled (XEN) DOM0: efi: Getting EFI parameters from FDT: (XEN) DOM0: efi: UEFI not found. (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 (XEN) DOM0: psci: probing for conduit method from DT. (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP (XEN) DOM0: Modules linked in: (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: ffffffc000860000 (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 (XEN) DOM0: sp : ffffffc000863ee0 (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 (XEN) DOM0: (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 00000000 008bc000 ffffffc0 (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 ffffffc0 00817874 ffffffc0 (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 ffffffc0 00815670 ffffffc0 (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 ffffffc0 00866000 ffffffc0 (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 00000000 d08f0000 00000000 (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 00000000 64667467 ff616b73 (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 00000000 00000e11 00000000 (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 00000000 d0000000 00000000 (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 00000000 00000000 00000000 (XEN) DOM0: Call trace: (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: [] psci_init+0x2c/0x40 (XEN) DOM0: [] setup_arch+0x420/0x5ac (XEN) DOM0: [] start_kernel+0xa0/0x3a4 (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the idle task! On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters wrote: > Hi Ian, > >> >> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra >> info. It would also be useful to see your file "cfg", in particular the >> various command lines which it will contain. >> > I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but > to answer your other questions, my cfg file: > > [global] > default=default > > [default] > options=console=dtuart dtuart=serial0 conswitch=x > kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait > root=/dev/sda3 > dtb=junoX > > I copied that from the link I referenced earlier, I believe. The only > differences are that I differentiated my default kernel and dtb from > the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My > root device is indeed /dev/sda3. > > > >> I take it your dom0 kernel binary boot successfully with all CPUs >> natively? > > Yes, my dom0 kernel boots all CPUs successfully. I didn't really > exercise them, but I can see all six of them. > >> >>> >>> thanks, >>> JP >>> > > > > > >>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >>> [1] Linux from NOR Flash >>> [2] Debian ARMv8 >>> [3] KVM >>> [4] Xen from NOR Flash >>> [5] Shell >>> [6] Boot Manager >>> Start: 5 >>> UEFI Interactive Shell v2.1 >>> EDK II >>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >>> Mapping table >>> FS2: Alias(s):F10:;BLK1: >>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >>> FS0: Alias(s):F3: >>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >>> FS1: Alias(s):F4: >>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >>> BLK0: Alias(s): >>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >>> Shell> fs2: >>> FS2:\> xen -cfg=cfg >>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >>> junoX: 0x00000009faf87000-0x00000009faf89b89 >>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >>> Xen 4.5.1 >>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >>> (XEN) 64-bit Execution: >>> (XEN) Processor Features: 0000000000002222 0000000000000000 >>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>> (XEN) Extensions: FloatingPoint AdvancedSIMD >>> (XEN) Debug Features: 0000000010305106 0000000000000000 >>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >>> (XEN) ISA Features: 0000000000011120 0000000000000000 >>> (XEN) 32-bit Execution: >>> (XEN) Processor Features: 00000131:00011011 >>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>> (XEN) Extensions: GenericTimer Security >>> (XEN) Debug Features: 03010066 >>> (XEN) Auxiliary Features: 00000000 >>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >>> (XEN) Error: PSCI version 0x10000 is not supported. >>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >>> (XEN) Using generic timer at 50000 KHz >>> (XEN) GICv2 initialization: >>> (XEN) gic_dist_addr=000000002c010000 >>> (XEN) gic_cpu_addr=000000002c02f000 >>> (XEN) gic_hyp_addr=000000002c04f000 >>> (XEN) gic_vcpu_addr=000000002c06f000 >>> (XEN) gic_maintenance_irq=25 >>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >>> (XEN) Using scheduler: SMP Credit Scheduler (credit) >>> (XEN) I/O virtualisation disabled >>> (XEN) Allocated console ring of 16 KiB. >>> (XEN) Bringing up CPU1 >>> (XEN) Failed to bring up CPU1 >>> (XEN) Failed to bring up CPU 1 (error -1) >>> (XEN) Bringing up CPU2 >>> (XEN) Failed to bring up CPU2 >>> (XEN) Failed to bring up CPU 2 (error -1) >>> (XEN) Bringing up CPU3 >>> (XEN) Failed to bring up CPU3 >>> (XEN) Failed to bring up CPU 3 (error -1) >>> (XEN) Bringing up CPU4 >>> (XEN) Failed to bring up CPU4 >>> (XEN) Failed to bring up CPU 4 (error -1) >>> (XEN) Bringing up CPU5 >>> (XEN) Failed to bring up CPU5 >>> (XEN) Failed to bring up CPU 5 (error -1) >>> (XEN) Brought up 1 CPUs >>> (XEN) P2M: 40-bit IPA with 40-bit PA >>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >>> (XEN) *** LOADING DOMAIN 0 *** >>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >>> (XEN) ................................................................done. >>> (XEN) Initial low memory virq threshold set at 0x4000 pages. >>> (XEN) Std. Loglevel: Errors and warnings >>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >>> input to Xen) >>> (XEN) Freed 280kB init memory. >>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >>> input to DOM0) >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xen.org >>> http://lists.xen.org/xen-users >> >> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 15 20:42:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 15 Jul 2015 20:42:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFTUh-0006AH-0x; Wed, 15 Jul 2015 20:41:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFTUg-0006AA-23 for xen-users@lists.xen.org; Wed, 15 Jul 2015 20:41:30 +0000 Received: from [193.109.254.147] by server-9.bemta-14.messagelabs.com id E4/38-03371-975C6A55; Wed, 15 Jul 2015 20:41:29 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-10.tower-27.messagelabs.com!1436992887!32397841!1 X-Originating-IP: [209.85.215.42] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5511 invoked from network); 15 Jul 2015 20:41:28 -0000 Received: from mail-la0-f42.google.com (HELO mail-la0-f42.google.com) (209.85.215.42) by server-10.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 15 Jul 2015 20:41:28 -0000 Received: by lagx9 with SMTP id x9so31824327lag.1 for ; Wed, 15 Jul 2015 13:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xbewHzFYYWTdwrM+TnaiOFA7VS6EKBlT9MqlHdytc/4=; b=0Xykl6Mw+K+yMDW4KbaNWt45V7ULSbP1gH1FvGGxEwL9+BL9u4lHYCLcq5QsX3v/zM /JXy97eQDMWWt4zu2QBm/iAJ3dLuz0SN2rf3W30YjyBxq8feu7+hwsrONEMczGWpZMAs Kgk8ilH8TB5uITFsimLfPx08gt6Bl6QpbWraDc5si5u+auM/gFk0a4F8ix4uZDmCW4At X0VQ5tb4RiUOFX0VIIVU6nFvQsDUAWAthgQGhV+Q8ctkq2MbTj46V2BOBQ0Ym/6ak4U5 MmmBqjB0z24Ftn3VdIJ9UW+hfKbjO1tIkJbgUlMKn+a693afDDo4TBlMROujAb5S2rzj 7Bpw== X-Received: by 10.152.87.231 with SMTP id bb7mr5984441lab.16.1436992887324; Wed, 15 Jul 2015 13:41:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Wed, 15 Jul 2015 13:41:07 -0700 (PDT) In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Wed, 15 Jul 2015 16:41:07 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I've included the output of building xen with debug=y and CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional CPUs aren't coming up, but I noticed an error message early in the Xen output: (XEN) Error: PSCI version 0x10000 is not supported. Then the dom0 kernel appears to crash inside of some PSCI initialization: (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: [] psci_init+0x2c/0x40 (XEN) DOM0: [] setup_arch+0x420/0x5ac (XEN) DOM0: [] start_kernel+0xa0/0x3a4 Any suggestions would be welcome. thanks, JP FS2:\> xen -cfg=cfg 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader junoX: 0x00000009faf87000-0x00000009faf89b89 ImageX: 0x00000009fa3be000-0x00000009fabf7000 - UART enabled - - CPU 00000100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000dfffffff (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff (XEN) RAM: 00000000feba0000 - 00000000febabfff (XEN) RAM: 00000000febac000 - 00000000feffffff (XEN) RAM: 0000000880000000 - 00000009fa3bdfff (XEN) RAM: 00000009fade9000 - 00000009faecffff (XEN) RAM: 00000009faf80000 - 00000009faf82fff (XEN) RAM: 00000009faf87000 - 00000009faf8afff (XEN) RAM: 00000009faf8c000 - 00000009febe3fff (XEN) RAM: 00000009febe4000 - 00000009ff142fff (XEN) RAM: 00000009ff143000 - 00000009ff144fff (XEN) RAM: 00000009ff145000 - 00000009ff16dfff (XEN) RAM: 00000009ff16e000 - 00000009ff170fff (XEN) RAM: 00000009ff171000 - 00000009ffdbffff (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff (XEN) RAM: 00000009fff90000 - 00000009fff9ffff (XEN) RAM: 00000009ffff0000 - 00000009ffffefff (XEN) RAM: 00000009fffff000 - 00000009ffffffff (XEN) (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 (XEN) (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => 00000000dfe00000-00000000dff0ad81 (XEN) PFN compression on bits 21...22 (XEN) Domain heap initialised (XEN) Looking for UART console serial0 Xen 4.5.1 (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: VERSATILE EXPRESS (XEN) Error: PSCI version 0x10000 is not supported. (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 (XEN) Failed to bring up CPU1 (XEN) Failed to bring up CPU 1 (error -1) (XEN) Bringing up CPU2 (XEN) Failed to bring up CPU2 (XEN) Failed to bring up CPU 2 (error -1) (XEN) Bringing up CPU3 (XEN) Failed to bring up CPU3 (XEN) Failed to bring up CPU 3 (error -1) (XEN) Bringing up CPU4 (XEN) Failed to bring up CPU4 (XEN) Failed to bring up CPU 4 (error -1) (XEN) Bringing up CPU5 (XEN) Failed to bring up CPU5 (XEN) Failed to bring up CPU 5 (error -1) (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa3be000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) DOM0: Booting Linux on physical CPU 0x0 (XEN) DOM0: Initializing cgroup subsys cpu (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 (XEN) DOM0: (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 (XEN) DOM0: Detected VIPT I-cache on CPU0 (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, 827319, 824069 (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') (XEN) DOM0: bootconsole [uart0] enabled (XEN) DOM0: efi: Getting EFI parameters from FDT: (XEN) DOM0: efi: UEFI not found. (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 (XEN) DOM0: psci: probing for conduit method from DT. (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP (XEN) DOM0: Modules linked in: (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: ffffffc000860000 (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 (XEN) DOM0: sp : ffffffc000863ee0 (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 (XEN) DOM0: (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 00000000 008bc000 ffffffc0 (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 ffffffc0 00817874 ffffffc0 (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 ffffffc0 00815670 ffffffc0 (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 ffffffc0 00866000 ffffffc0 (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 00000000 d08f0000 00000000 (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 00000000 64667467 ff616b73 (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 00000000 00000e11 00000000 (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 00000000 d0000000 00000000 (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 00000000 00000000 00000000 (XEN) DOM0: Call trace: (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 (XEN) DOM0: [] psci_init+0x2c/0x40 (XEN) DOM0: [] setup_arch+0x420/0x5ac (XEN) DOM0: [] start_kernel+0xa0/0x3a4 (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the idle task! On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters wrote: > Hi Ian, > >> >> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra >> info. It would also be useful to see your file "cfg", in particular the >> various command lines which it will contain. >> > I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but > to answer your other questions, my cfg file: > > [global] > default=default > > [default] > options=console=dtuart dtuart=serial0 conswitch=x > kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait > root=/dev/sda3 > dtb=junoX > > I copied that from the link I referenced earlier, I believe. The only > differences are that I differentiated my default kernel and dtb from > the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My > root device is indeed /dev/sda3. > > > >> I take it your dom0 kernel binary boot successfully with all CPUs >> natively? > > Yes, my dom0 kernel boots all CPUs successfully. I didn't really > exercise them, but I can see all six of them. > >> >>> >>> thanks, >>> JP >>> > > > > > >>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >>> [1] Linux from NOR Flash >>> [2] Debian ARMv8 >>> [3] KVM >>> [4] Xen from NOR Flash >>> [5] Shell >>> [6] Boot Manager >>> Start: 5 >>> UEFI Interactive Shell v2.1 >>> EDK II >>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >>> Mapping table >>> FS2: Alias(s):F10:;BLK1: >>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >>> FS0: Alias(s):F3: >>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >>> FS1: Alias(s):F4: >>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >>> BLK0: Alias(s): >>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >>> Shell> fs2: >>> FS2:\> xen -cfg=cfg >>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >>> junoX: 0x00000009faf87000-0x00000009faf89b89 >>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >>> Xen 4.5.1 >>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >>> (XEN) 64-bit Execution: >>> (XEN) Processor Features: 0000000000002222 0000000000000000 >>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>> (XEN) Extensions: FloatingPoint AdvancedSIMD >>> (XEN) Debug Features: 0000000010305106 0000000000000000 >>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >>> (XEN) ISA Features: 0000000000011120 0000000000000000 >>> (XEN) 32-bit Execution: >>> (XEN) Processor Features: 00000131:00011011 >>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>> (XEN) Extensions: GenericTimer Security >>> (XEN) Debug Features: 03010066 >>> (XEN) Auxiliary Features: 00000000 >>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >>> (XEN) Error: PSCI version 0x10000 is not supported. >>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >>> (XEN) Using generic timer at 50000 KHz >>> (XEN) GICv2 initialization: >>> (XEN) gic_dist_addr=000000002c010000 >>> (XEN) gic_cpu_addr=000000002c02f000 >>> (XEN) gic_hyp_addr=000000002c04f000 >>> (XEN) gic_vcpu_addr=000000002c06f000 >>> (XEN) gic_maintenance_irq=25 >>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >>> (XEN) Using scheduler: SMP Credit Scheduler (credit) >>> (XEN) I/O virtualisation disabled >>> (XEN) Allocated console ring of 16 KiB. >>> (XEN) Bringing up CPU1 >>> (XEN) Failed to bring up CPU1 >>> (XEN) Failed to bring up CPU 1 (error -1) >>> (XEN) Bringing up CPU2 >>> (XEN) Failed to bring up CPU2 >>> (XEN) Failed to bring up CPU 2 (error -1) >>> (XEN) Bringing up CPU3 >>> (XEN) Failed to bring up CPU3 >>> (XEN) Failed to bring up CPU 3 (error -1) >>> (XEN) Bringing up CPU4 >>> (XEN) Failed to bring up CPU4 >>> (XEN) Failed to bring up CPU 4 (error -1) >>> (XEN) Bringing up CPU5 >>> (XEN) Failed to bring up CPU5 >>> (XEN) Failed to bring up CPU 5 (error -1) >>> (XEN) Brought up 1 CPUs >>> (XEN) P2M: 40-bit IPA with 40-bit PA >>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >>> (XEN) *** LOADING DOMAIN 0 *** >>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >>> (XEN) ................................................................done. >>> (XEN) Initial low memory virq threshold set at 0x4000 pages. >>> (XEN) Std. Loglevel: Errors and warnings >>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >>> input to Xen) >>> (XEN) Freed 280kB init memory. >>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >>> input to DOM0) >>> >>> _______________________________________________ >>> Xen-users mailing list >>> Xen-users@lists.xen.org >>> http://lists.xen.org/xen-users >> >> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 09:53:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 09:53:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFfqU-0004o6-LV; Thu, 16 Jul 2015 09:52:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFfqS-0004nt-N1 for xen-users@lists.xen.org; Thu, 16 Jul 2015 09:52:48 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 43/B6-11060-FEE77A55; Thu, 16 Jul 2015 09:52:47 +0000 X-Env-Sender: krichy@tvnetwork.hu X-Msg-Ref: server-4.tower-31.messagelabs.com!1437040366!25113956!1 X-Originating-IP: [109.61.101.194] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4318 invoked from network); 16 Jul 2015 09:52:46 -0000 Received: from krichy.tvnetwork.hu (HELO krichy.tvnetwork.hu) (109.61.101.194) by server-4.tower-31.messagelabs.com with SMTP; 16 Jul 2015 09:52:46 -0000 Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 520CB4187C; Thu, 16 Jul 2015 11:52:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 517154187B for ; Thu, 16 Jul 2015 11:52:46 +0200 (CEST) Date: Thu, 16 Jul 2015 11:52:46 +0200 (CEST) From: krichy@tvnetwork.hu To: xen-users@lists.xen.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Subject: Re: [Xen-users] xen dom0 nfs hangs X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Dear Xen users, I also had an issue strangely with the same symptoms as Mike had. We run ganeti, all nodes have a /srv/ganeti/shared-file-storage mountpoint from an nfs server, and with debian jessie's xen (4.4) if a node has a high overall iops from all of its guests, it will stall sometimes. The same problem as Mike's: qemu processes remain in D state, the nfs path can be read but not written to it. Mike, could you solve your issue somehow? Earlier we were using debian wheezy with kernel 3.2 and xen 4.1. I dont know id the linux nfs client implementation has some bug or the handling of file backed vbds cause the issue. Unfortunately I cannot reproduce the problem, it just arises randomly. I assume it is related to high iops. Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatika Zrt. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 09:53:49 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 09:53:49 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFfqU-0004o6-LV; Thu, 16 Jul 2015 09:52:50 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFfqS-0004nt-N1 for xen-users@lists.xen.org; Thu, 16 Jul 2015 09:52:48 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 43/B6-11060-FEE77A55; Thu, 16 Jul 2015 09:52:47 +0000 X-Env-Sender: krichy@tvnetwork.hu X-Msg-Ref: server-4.tower-31.messagelabs.com!1437040366!25113956!1 X-Originating-IP: [109.61.101.194] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4318 invoked from network); 16 Jul 2015 09:52:46 -0000 Received: from krichy.tvnetwork.hu (HELO krichy.tvnetwork.hu) (109.61.101.194) by server-4.tower-31.messagelabs.com with SMTP; 16 Jul 2015 09:52:46 -0000 Received: by krichy.tvnetwork.hu (Postfix, from userid 1000) id 520CB4187C; Thu, 16 Jul 2015 11:52:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by krichy.tvnetwork.hu (Postfix) with ESMTP id 517154187B for ; Thu, 16 Jul 2015 11:52:46 +0200 (CEST) Date: Thu, 16 Jul 2015 11:52:46 +0200 (CEST) From: krichy@tvnetwork.hu To: xen-users@lists.xen.org Message-ID: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Subject: Re: [Xen-users] xen dom0 nfs hangs X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Dear Xen users, I also had an issue strangely with the same symptoms as Mike had. We run ganeti, all nodes have a /srv/ganeti/shared-file-storage mountpoint from an nfs server, and with debian jessie's xen (4.4) if a node has a high overall iops from all of its guests, it will stall sometimes. The same problem as Mike's: qemu processes remain in D state, the nfs path can be read but not written to it. Mike, could you solve your issue somehow? Earlier we were using debian wheezy with kernel 3.2 and xen 4.1. I dont know id the linux nfs client implementation has some bug or the handling of file backed vbds cause the issue. Unfortunately I cannot reproduce the problem, it just arises randomly. I assume it is related to high iops. Thanks in advance, Kojedzinszky Richard Euronet Magyarorszag Informatika Zrt. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 10:45:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 10:45:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFgej-0000YM-Md; Thu, 16 Jul 2015 10:44:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFgei-0000YH-00 for xen-users@lists.xen.org; Thu, 16 Jul 2015 10:44:44 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 1B/6C-32733-B1B87A55; Thu, 16 Jul 2015 10:44:43 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-7.tower-27.messagelabs.com!1437043482!32596706!1 X-Originating-IP: [80.0.253.72] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27913 invoked from network); 16 Jul 2015 10:44:42 -0000 Received: from know-smtprelay-omc-8.server.virginmedia.net (HELO know-smtprelay-omc-8.server.virginmedia.net) (80.0.253.72) by server-7.tower-27.messagelabs.com with SMTP; 16 Jul 2015 10:44:42 -0000 Received: from dingwall.me.uk ([82.33.62.46]) by know-smtprelay-8-imp with bizsmtp id sykh1q00S0zrmay01ykhx3; Thu, 16 Jul 2015 11:44:42 +0100 X-Originating-IP: [82.33.62.46] X-Spam: 0 X-Authority: v=2.1 cv=UKUgZ3ry c=1 sm=1 tr=0 a=43HWeVr0mW5rhQls5iFsjw==:117 a=43HWeVr0mW5rhQls5iFsjw==:17 a=5IRWAbXhAAAA:8 a=yEdEr6MRgwAA:10 a=kj9zAlcOel0A:10 a=zOBTXjUuO1YA:10 a=F2-eySjI3ahu28C-0B0A:9 a=CjuIK1q_8ugA:10 Received: (qmail 10084 invoked from network); 16 Jul 2015 10:44:41 -0000 Received: from behemoth.dingwall.me.uk (192.168.1.5) by mail0.xen.dingwall.me.uk with SMTP; 16 Jul 2015 10:44:41 -0000 Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000) id 2239BD08C20; Thu, 16 Jul 2015 11:44:41 +0100 (BST) Date: Thu, 16 Jul 2015 11:44:40 +0100 From: James Dingwall To: Alex Wakizashi Message-ID: <20150716104440.GA2986@dingwall.me.uk> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: xen-users@lists.xen.org, Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, Jul 15, 2015 at 09:02:13AM +0300, Alex Wakizashi wrote: > Second problem - XEN implementation of OVMF doesn't allow to save any settings. > Regardless of pflash image, specified in QEMU as "-drive if=pflash..." > - it's just not saving settings at all. > > Again, would be excellent to be able to specify separate OVMF image, > like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that > is a problem. > > I've seen discussion in this mail list about separated version of OVMF > for XEN, but it stopped few months ago without any links/solutions. > (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA > Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave > some answers). > > So, would be glad to get hands on such version and test it :) I did some experimentation with uefi guests recently, iirc if your disk image has an ef00 partition then settings will be saved there. I would need to go back and confirm that this is the case since it was several months since I did this. There is a ./configure option for the xen build which allows an external ovmf binary too be used. ./configure --with-system-ovmf=/my/ovmf/build/OVMF.fd --enable-ovmf James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 10:45:50 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 10:45:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFgej-0000YM-Md; Thu, 16 Jul 2015 10:44:45 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFgei-0000YH-00 for xen-users@lists.xen.org; Thu, 16 Jul 2015 10:44:44 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 1B/6C-32733-B1B87A55; Thu, 16 Jul 2015 10:44:43 +0000 X-Env-Sender: james@dingwall.me.uk X-Msg-Ref: server-7.tower-27.messagelabs.com!1437043482!32596706!1 X-Originating-IP: [80.0.253.72] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27913 invoked from network); 16 Jul 2015 10:44:42 -0000 Received: from know-smtprelay-omc-8.server.virginmedia.net (HELO know-smtprelay-omc-8.server.virginmedia.net) (80.0.253.72) by server-7.tower-27.messagelabs.com with SMTP; 16 Jul 2015 10:44:42 -0000 Received: from dingwall.me.uk ([82.33.62.46]) by know-smtprelay-8-imp with bizsmtp id sykh1q00S0zrmay01ykhx3; Thu, 16 Jul 2015 11:44:42 +0100 X-Originating-IP: [82.33.62.46] X-Spam: 0 X-Authority: v=2.1 cv=UKUgZ3ry c=1 sm=1 tr=0 a=43HWeVr0mW5rhQls5iFsjw==:117 a=43HWeVr0mW5rhQls5iFsjw==:17 a=5IRWAbXhAAAA:8 a=yEdEr6MRgwAA:10 a=kj9zAlcOel0A:10 a=zOBTXjUuO1YA:10 a=F2-eySjI3ahu28C-0B0A:9 a=CjuIK1q_8ugA:10 Received: (qmail 10084 invoked from network); 16 Jul 2015 10:44:41 -0000 Received: from behemoth.dingwall.me.uk (192.168.1.5) by mail0.xen.dingwall.me.uk with SMTP; 16 Jul 2015 10:44:41 -0000 Received: by behemoth.dingwall.me.uk (Postfix, from userid 1000) id 2239BD08C20; Thu, 16 Jul 2015 11:44:41 +0100 (BST) Date: Thu, 16 Jul 2015 11:44:40 +0100 From: James Dingwall To: Alex Wakizashi Message-ID: <20150716104440.GA2986@dingwall.me.uk> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: xen-users@lists.xen.org, Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, Jul 15, 2015 at 09:02:13AM +0300, Alex Wakizashi wrote: > Second problem - XEN implementation of OVMF doesn't allow to save any settings. > Regardless of pflash image, specified in QEMU as "-drive if=pflash..." > - it's just not saving settings at all. > > Again, would be excellent to be able to specify separate OVMF image, > like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that > is a problem. > > I've seen discussion in this mail list about separated version of OVMF > for XEN, but it stopped few months ago without any links/solutions. > (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA > Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave > some answers). > > So, would be glad to get hands on such version and test it :) I did some experimentation with uefi guests recently, iirc if your disk image has an ef00 partition then settings will be saved there. I would need to go back and confirm that this is the case since it was several months since I did this. There is a ./configure option for the xen build which allows an external ovmf binary too be used. ./configure --with-system-ovmf=/my/ovmf/build/OVMF.fd --enable-ovmf James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 15:26:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 15:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFl2O-0002PT-7P; Thu, 16 Jul 2015 15:25:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFl2M-0002PO-3u for xen-users@lists.xen.org; Thu, 16 Jul 2015 15:25:26 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 9E/E6-18676-5ECC7A55; Thu, 16 Jul 2015 15:25:25 +0000 X-Env-Sender: shameerali.kolothum.thodi@huawei.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1437060324!32694707!1 X-Originating-IP: [194.213.3.17] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28682 invoked from network); 16 Jul 2015 15:25:24 -0000 Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 15:25:24 -0000 Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVG76240; Thu, 16 Jul 2015 15:25:23 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 16 Jul 2015 16:25:15 +0100 From: Shameerali Kolothum Thodi To: "xen-users@lists.xen.org" Thread-Topic: Enabling Xen on HiSilicon HIP05 board Thread-Index: AdC/251i+NuBdUzGQjeNno2OKWRg/A== Date: Thu, 16 Jul 2015 15:25:15 +0000 Message-ID: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.137.235] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Julien Grall , Zoltan Kiss , Ian Campbell Subject: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2095908660014434974==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2095908660014434974== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_" --_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I am trying to enable Xen on our AARCh64 board, HIP05 D02(http://hisilicon.= github.io/2015/04/17/D02-hacking-manual) I have taken the latest Xen source code and build it with the board dtb fil= e. The dts file was modified to include Xen and dom0(3.19 based kernel) bootar= gs. +*/ + chosen { + #address-cells =3D <1>; + #size-cells =3D <1>; + + xen,xen-bootargs =3D "dom0_mem=3D128M console=3Ddtuart dtu= art=3Dserial0"; + xen,dom0-bootargs =3D "console=3Dhvc0 earlyprintk root=3D/= dev/sda2 rw loglevel=3D7"; + module@0x7000000 { + compatible =3D "xen,linux-kernel", "xen,multiboot-= module"; + reg =3D <0x7000000 0x300000>; + }; + }; + I have to make the following changes to the Xen src to get it booted on the= board. The changes are basically to enable UART and GIC. Our GIC is slight= ly different from ARM GICv3, but I have kept the changes minimal such that = it boots on the board(I am yet to figure out the exact differences with ARM= GICv3 spec and our implementation and its impact on Xen). diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index e27f573..3e3c4ac 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -49,6 +49,7 @@ EARLY_PRINTK_dra7 :=3D 8250,0x4806A000,2 EARLY_PRINTK_fastmodel :=3D pl011,0x1c090000,115200 EARLY_PRINTK_exynos5250 :=3D exynos4210,0x12c20000 EARLY_PRINTK_hip04-d01 :=3D 8250,0xE4007000,2 +EARLY_PRINTK_hip05-d02 :=3D 8250,0x80300000,2 EARLY_PRINTK_juno :=3D pl011,0x7ff80000 EARLY_PRINTK_lager :=3D scif,0xe6e60000 EARLY_PRINTK_midway :=3D pl011,0xfff36000 diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 30682cf..10028d2 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -54,7 +54,7 @@ static struct { paddr_t dbase_size; void __iomem *map_dbase; /* Mapped address of distributor registers *= / struct rdist_region *rdist_regions; - uint32_t rdist_stride; + uint64_t rdist_stride; unsigned int rdist_count; /* Number of rdist regions count */ unsigned int nr_priorities; spinlock_t lock; @@ -635,7 +635,8 @@ static int __init gicv3_populate_rdist(void) void __iomem *ptr =3D gicv3.rdist_regions[i].map_base; reg =3D readl_relaxed(ptr + GICR_PIDR2) & GICR_PIDR2_ARCH_REV_MASK= ; - if ( (reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3= ) + if ( ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV= 3 ) && + ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV4= )) { dprintk(XENLOG_ERR, "GICv3: No redistributor present @%"PRIpaddr"\n", @@ -1221,7 +1222,8 @@ static int __init gicv3_init(void) panic("GICv3: Failed to ioremap for GIC distributor\n"); reg =3D readl_relaxed(GICD + GICD_PIDR2) & GICD_PIDR2_ARCH_REV_MASK; - if ( ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) ) + if ( ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) &= & + ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV4) ) panic("GICv3: no distributor detected\n"); if ( !dt_property_read_u32(node, "#redistributor-regions", @@ -1251,7 +1253,7 @@ static int __init gicv3_init(void) /* The vGIC code requires the region to be sorted */ sort(rdist_regs, gicv3.rdist_count, sizeof(*rdist_regs), cmp_rdist, NU= LL); - if ( !dt_property_read_u32(node, "redistributor-stride", &gicv3.rdist_= stride) ) + if ( !dt_property_read_u64(node, "redistributor-stride", &gicv3.rdist_= stride) ) gicv3.rdist_stride =3D 0; gicv3.rdist_regions=3D rdist_regs; @@ -1277,7 +1279,7 @@ static int __init gicv3_init(void) " gic_dist_size=3D%"PRIpaddr"\n" " gic_dist_mapaddr=3D%p\n" " gic_rdist_regions=3D%d\n" - " gic_rdist_stride=3D%x\n" + " gic_rdist_stride=3D%lx\n" " gic_rdist_base=3D%"PRIpaddr"\n" " gic_rdist_base_size=3D%"PRIpaddr"\n" " gic_rdist_base_mapaddr=3D%p\n" diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index f1a087e..2df6f85 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -111,7 +111,7 @@ struct arch_domain unsigned int first_cpu; /* First CPU handled */ } rdist_regions[MAX_RDIST_COUNT]; int nr_regions; /* Number of rdist regions */ - uint32_t rdist_stride; /* Re-Distributor stride */ + uint64_t rdist_stride; /* Re-Distributor stride */ #endif } vgic; diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h index 9e2acb7..e533583 100644 --- a/xen/include/asm-arm/gic.h +++ b/xen/include/asm-arm/gic.h @@ -160,7 +160,8 @@ DT_MATCH_COMPATIBLE("arm,cortex-a7-gic"), \ DT_MATCH_COMPATIBLE("arm,gic-400") -#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3") +//#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3") +#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("hisilicon,gic-v3") /* * GICv3 registers that needs to be saved/restored diff --git a/xen/include/asm-arm/gic_v3_defs.h b/xen/include/asm-arm/gic_v3= _defs.h index 556f114..ed360a1 100644 --- a/xen/include/asm-arm/gic_v3_defs.h +++ b/xen/include/asm-arm/gic_v3_defs.h @@ -62,10 +62,12 @@ #define GICD_PIDR2_ARCH_REV_MASK (0xf0) #define GICD_PIDR2_ARCH_REV_SHIFT (0x4) #define GICD_PIDR2_ARCH_GICV3 (0x3) +#define GICD_PIDR2_ARCH_GICV4 (0x4) #define GICR_PIDR2_ARCH_REV_MASK GICD_PIDR2_ARCH_REV_MASK #define GICR_PIDR2_ARCH_REV_SHIFT GICD_PIDR2_ARCH_REV_SHIFT #define GICR_PIDR2_ARCH_GICV3 GICD_PIDR2_ARCH_GICV3 +#define GICR_PIDR2_ARCH_GICV4 GICD_PIDR2_ARCH_GICV4 #define GICR_SYNCR_NOT_BUSY 1 /* The xen image and dom0 kernel image is written into nor flash and UEFI boot= s Xen instead of a normal linux kernel. The Xen then, loads the dom0 image = to memory and tries to boot it. The problem is in getting the dom0 booted. I can't see any prints from dom0= . Please find attached log for details. As I said, our GIC is slightly different from ARM GICv3, but I am not 100% = sure the dom0 boot issue is related to GIC or not. From what I could analys= e, dom0 stops very early. The pc points to the __error_p (arch/arm64/kernel= /head.S) symbol as per System.map file. And it looks to be Invalid processo= r type return after lookup_processor_type Could you please take a look at the attached logs and please let me know if= you find anything suspicious in what I am doing. Thanks, Shameer FDTConfigTable Address: 0x7FBD0000 [LPC] SATA ExitBootServicesEvent [LPC] GMAC ExitBootServicesEvent - UART enabled - - CPU 00020000 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000000000000 - 000000007fffffff (XEN) (XEN) MODULE[0]: 000000000018ad80 - 000000000018d29a Device Tree (XEN) MODULE[1]: 0000000007000000 - 0000000007300000 Kernel (XEN) (XEN) Command line: dom0_mem=3D128M console=3Ddtuart dtuart=3Dserial0 (XEN) Placing Xen at 0x000000007fe00000-0x0000000080000000 (XEN) Update BOOTMOD_XEN from 0000000000080000-000000000018ad81 =3D> 000000= 007fe00000-000000007ff0ad81 (XEN) Domain heap initialised (XEN) Platform: Generic System (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (root@) (aarch64-linux-gnu-gcc (crosstool-NG= linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 4.9.2 20140904 (prerel= ease)) debug=3Dy Thu Jul 16 14:31:47 BST 2015 (XEN) Latest ChangeSet: Fri Jun 26 18:24:22 2015 +0100 git:c40317f-dirty (XEN) Processor: 411fd071: "ARM Limited", variant: 0x1, part 0xd07, rev 0x1 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000001002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001124 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:10011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 NOTICE: [psci_smc_handler]:[239L] PSCI_VERSION CALL NOTICE: [psci_version]:[76L] PSCI_MAJOR_VER: 0: PSCI_MINOR_VER: 2 00258>04 (XEN) Using PSCI-0.2 for SMP bringup (XEN) Generic Timer IRQ: phys=3D30 hyp=3D26 virt=3D27 Freq: 50000 KHz (XEN) GICv3 initialization: (XEN) gic_dist_addr=3D000000008d000000 (XEN) gic_dist_size=3D0000000000010000 (XEN) gic_dist_mapaddr=3D000000004001a000 (XEN) gic_rdist_regions=3D1 (XEN) gic_rdist_stride=3D30000 (XEN) gic_rdist_base=3D000000008d100000 (XEN) gic_rdist_base_size=3D0000000000300000 (XEN) gic_rdist_base_mapaddr=3D000000004002b000 (XEN) gic_maintenance_irq=3D25 (XEN) GICv3: 1024 lines, (IID 0204043b). (XEN) GICv3: CPU0: Found redistributor in region 0 @000000004002b000 (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 128 KiB. (XEN) Bringing up CPU1 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20001 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19790 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1b9c0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19790 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020001 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU1: Found redistributor in region 0 @000000004005b000 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20002 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc199a0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1ba40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc199a0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020002 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU2: Found redistributor in region 0 @000000004008b000 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20003 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19bb0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bac0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19bb0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020003 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU3: Found redistributor in region 0 @00000000400bb000 (XEN) CPU 3 booted. (XEN) Bringing up CPU4 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20100 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19dc0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bb40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19dc0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU4: Found redistributor in region 0 @00000000400eb000 (XEN) CPU 4 booted. (XEN) Bringing up CPU5 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20101 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19fd0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bbc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19fd0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020101 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU5: Found redistributor in region 0 @000000004011b000 (XEN) CPU 5 booted. (XEN) Bringing up CPU6 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20102 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a1e0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bc40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a1e0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020102 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU6: Found redistributor in region 0 @000000004014b000 (XEN) CPU 6 booted. (XEN) Bringing up CPU7 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20103 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a3f0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bcc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a3f0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020103 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU7: Found redistributor in region 0 @000000004017b000 (XEN) CPU 7 booted. (XEN) Bringing up CPU8 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20200 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a600 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bd40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a600 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020200 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU8: Found redistributor in region 0 @00000000401ab000 (XEN) CPU 8 booted. (XEN) Bringing up CPU9 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20201 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a810 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bdc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a810 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020201 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU9: Found redistributor in region 0 @00000000401db000 (XEN) CPU 9 booted. (XEN) Bringing up CPU10 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20202 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1aa20 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1be40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1aa20 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020202 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU10: Found redistributor in region 0 @000000004020b000 (XEN) CPU 10 booted. (XEN) Bringing up CPU11 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20203 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1ac30 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bec0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1ac30 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020203 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU11: Found redistributor in region 0 @000000004023b000 (XEN) CPU 11 booted. (XEN) Bringing up CPU12 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20300 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1ae40 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bf40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1ae40 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020300 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU12: Found redistributor in region 0 @000000004026b000 (XEN) CPU 12 booted. (XEN) Bringing up CPU13 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20301 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b050 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bfc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b050 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020301 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU13: Found redistributor in region 0 @000000004029b000 (XEN) CPU 13 booted. (XEN) Bringing up CPU14 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20302 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b260 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1c040 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b260 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020302 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU14: Found redistributor in region 0 @00000000402cb000 (XEN) CPU 14 booted. (XEN) Bringing up CPU15 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20303 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b470 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1c0c0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b470 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020303 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU15: Found redistributor in region 0 @00000000402fb000 (XEN) CPU 15 booted. (XEN) Brought up 16 CPUs (XEN) P2M: 44-bit IPA with 44-bit PA (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 0000000007000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) (XEN) Loading zImage from 0000000007000000 to 0000000008080000-000000000838= 0000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs (XEN) .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 264kB init memory. (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to= DOM0) (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 guest state (d0v0): *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 0 (XEN) PC: 0000000008082760 (XEN) LR: 000000000808101c (XEN) SP_EL0: 0000000000000000 (XEN) SP_EL1: 0000000000000000 (XEN) CPSR: 800001c5 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000000 X1: 0000004008000000 X2: ffffffc0000827a8 (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000000 (XEN) X6: 0000000000000000 X7: 0000000000000000 X8: 0000000000000000 (XEN) X9: 0000000000000000 X10: 0000000000000000 X11: 0000000000000000 (XEN) X12: 0000000000000000 X13: 0000000000000016 X14: 0000000000000000 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 0000000000000000 X20: 0000000000000e11 (XEN) X21: 000000000fe00000 X22: 00000000411fd071 X23: 0000000000000000 (XEN) X24: 0000000008000000 X25: 0000000000000000 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000004008000000 FP: 0000000000000000 (XEN) (XEN) ELR_EL1: 0000000000000000 (XEN) ESR_EL1: 00000000 (XEN) FAR_EL1: 0000000000000000 (XEN) (XEN) SCTLR_EL1: 00c50838 (XEN) TCR_EL1: 00000000 (XEN) TTBR0_EL1: 0000000000000000 (XEN) TTBR1_EL1: 0000000000000000 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 000100007fdd6000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000008038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Guest stack trace from sp=3D0: (XEN) Failed to convert stack to physical address (XEN) (XEN) *** Dumping CPU1 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 1 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffdfe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000001 X2: 0000000000304450 (XEN) X3: 000080007ff12028 X4: 000080007fc08700 X5: 0000000002faf080 (XEN) X6: 000080007ff0d8d0 X7: 000080007ff0d8e8 X8: 000080007ff120b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020001 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffdfe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffdfe70: (XEN) 000080007ffdfe80 000000000024ff54 000000000030ac98 000000000000000= 1 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000001>] 0000000000000001 (XEN) (XEN) *** Dumping CPU2 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 2 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffcfe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000002 X2: 0000000000304450 (XEN) X3: 000080007ff10028 X4: 000080007fc06700 X5: 0000000002faf080 (XEN) X6: 000080007ff0dbc0 X7: 000080007ff0dbd8 X8: 000080007ff100b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000032 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020002 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffcfe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffcfe70: (XEN) 000080007ffcfe80 000000000024ff54 000000000030ac98 000000000000000= 2 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000002>] 0000000000000002 (XEN) (XEN) *** Dumping CPU3 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 3 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffc7e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000003 X2: 0000000000304450 (XEN) X3: 000080007ffd4028 X4: 000080007fcca700 X5: 0000000002faf080 (XEN) X6: 000080007ff0de20 X7: 000080007ff0de38 X8: 000080007ffd40b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000200 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020003 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffc7e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffc7e70: (XEN) 000080007ffc7e80 000000000024ff54 000000000030ac98 000000000000000= 3 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000003>] 0000000000000003 (XEN) (XEN) *** Dumping CPU4 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 4 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff7fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000004 X2: 0000000000304450 (XEN) X3: 000080007ffd2028 X4: 000080007fcc8700 X5: 0000000002faf080 (XEN) X6: 000080007ffd10a0 X7: 000080007ffd10b8 X8: 000080007ffd20b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000034 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020100 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff7fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff7fe70: (XEN) 000080007ff7fe80 000000000024ff54 000000000030ac98 000000000000000= 4 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000004>] 0000000000000004 (XEN) (XEN) *** Dumping CPU5 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 5 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff6fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000005 X2: 0000000000304450 (XEN) X3: 000080007ff76028 X4: 000080007fc6c700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1300 X7: 000080007ffd1318 X8: 000080007ff760b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000035 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020101 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff6fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff6fe70: (XEN) 000080007ff6fe80 000000000024ff54 000000000030ac98 000000000000000= 5 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000005>] 0000000000000005 (XEN) (XEN) *** Dumping CPU6 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 6 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff67e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000006 X2: 0000000000304450 (XEN) X3: 000080007ff72028 X4: 000080007fc68700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1560 X7: 000080007ffd1578 X8: 000080007ff720b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000036 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020102 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff67e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff67e70: (XEN) 000080007ff67e80 000000000024ff54 000000000030ac98 000000000000000= 6 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000006>] 0000000000000006 (XEN) (XEN) *** Dumping CPU7 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 7 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff57e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000007 X2: 0000000000304450 (XEN) X3: 000080007ff70028 X4: 000080007fc66700 X5: 0000000002faf080 (XEN) X6: 000080007ffd17c0 X7: 000080007ffd17d8 X8: 000080007ff700b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000037 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020103 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff57e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff57e70: (XEN) 000080007ff57e80 000000000024ff54 000000000030ac98 000000000000000= 7 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000007>] 0000000000000007 (XEN) (XEN) *** Dumping CPU8 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 8 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff4fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000008 X2: 0000000000304450 (XEN) X3: 000080007ff5c028 X4: 000080007fc52700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1a20 X7: 000080007ffd1a38 X8: 000080007ff5c0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000038 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020200 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff4fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff4fe70: (XEN) 000080007ff4fe80 000000000024ff54 000000000030ac98 000000000000000= 8 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000008>] 0000000000000008 (XEN) (XEN) *** Dumping CPU9 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 9 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff47e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000009 X2: 0000000000304450 (XEN) X3: 000080007ff5a028 X4: 000080007fc50700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1c80 X7: 000080007ffd1c98 X8: 000080007ff5a0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000039 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020201 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff47e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff47e70: (XEN) 000080007ff47e80 000000000024ff54 000000000030ac98 000000000000000= 9 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000009>] 0000000000000009 (XEN) (XEN) *** Dumping CPU10 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 10 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffb7e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000a X2: 0000000000304450 (XEN) X3: 000080007ffbe028 X4: 000080007fcb4700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1ee0 X7: 000080007ffd1ef8 X8: 000080007ffbe0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020202 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffb7e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffb7e70: (XEN) 000080007ffb7e80 000000000024ff54 000000000030ac98 000000000000000= a (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000a>] 000000000000000a (XEN) (XEN) *** Dumping CPU11 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 11 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffafe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000b X2: 0000000000304450 (XEN) X3: 000080007ffba028 X4: 000080007fcb0700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd180 X7: 000080007ffbd198 X8: 000080007ffba0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020203 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffafe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffafe70: (XEN) 000080007ffafe80 000000000024ff54 000000000030ac98 000000000000000= b (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000b>] 000000000000000b (XEN) (XEN) *** Dumping CPU12 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 12 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff9fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000c X2: 0000000000304450 (XEN) X3: 000080007ffb8028 X4: 000080007fcae700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd3e0 X7: 000080007ffbd3f8 X8: 000080007ffb80b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020300 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff9fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff9fe70: (XEN) 000080007ff9fe80 000000000024ff54 000000000030ac98 000000000000000= c (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000c>] 000000000000000c (XEN) (XEN) *** Dumping CPU13 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 13 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff97e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000d X2: 0000000000304450 (XEN) X3: 000080007ffa4028 X4: 000080007fc9a700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd640 X7: 000080007ffbd658 X8: 000080007ffa40b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020301 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff97e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff97e70: (XEN) 000080007ff97e80 000000000024ff54 000000000030ac98 000000000000000= d (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000d>] 000000000000000d (XEN) (XEN) *** Dumping CPU14 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 14 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff8fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000e X2: 0000000000304450 (XEN) X3: 000080007ffa2028 X4: 000080007fc98700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd8a0 X7: 000080007ffbd8b8 X8: 000080007ffa20b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020302 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff8fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff8fe70: (XEN) 000080007ff8fe80 000000000024ff54 000000000030ac98 000000000000000= e (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000e>] 000000000000000e (XEN) (XEN) *** Dumping CPU15 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 15 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007fdffe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000f X2: 0000000000304450 (XEN) X3: 000080007ff86028 X4: 000080007fc7c700 X5: 0000000002faf080 (XEN) X6: 000080007ffbdb00 X7: 000080007ffbdb18 X8: 000080007ff860b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020303 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007fdffe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007fdffe70: (XEN) 000080007fdffe80 000000000024ff54 000000000030ac98 000000000000000= f (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000f>] 000000000000000f (XEN) (XEN) 'q' pressed -> dumping domain info (now=3D0x8:BFE1C2E8) (XEN) General information for domain 0: (XEN) refcnt=3D3 dying=3D0 pause_count=3D0 (XEN) nr_pages=3D32768 xenheap_pages=3D5 shared_pages=3D0 paged_pages= =3D0 dirty_cpus=3D{} max_pages=3D4294967295 (XEN) handle=3D00000000-0000-0000-0000-000000000000 vm_assist=3D0000000= 0 (XEN) p2m mappings for domain 0 (vmid 1): (XEN) 1G mappings: 0 (shattered 0) (XEN) 2M mappings: 64 (shattered 0) (XEN) 4K mappings: 328 (XEN) Rangesets belonging to domain 0: (XEN) Interrupts { 344-345, 348, 350 } (XEN) I/O Memory { 80040-80041, 802e0-80300, 80310-80340, 8c030-8c040, = a0040-a0041, a00e0-a0110, a1000-a1020, a3030-a3040, b0000-b0010, b0040-b004= 1, b0080-b00a0, b00d0-b00f0, b1000-b1013, b7030-b7040, c0040-c0041, c6030-c= 6040, 22000000-22000001, 24000000-24000001 } (XEN) NODE affinity for domain 0: [0] (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D01 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D0 (XEN) GICH_LRs (vcpu 0) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU1: CPU1 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 1) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU2: CPU2 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 2) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU3: CPU3 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 3) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU4: CPU4 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 4) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU5: CPU5 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 5) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU6: CPU6 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 6) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU7: CPU7 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 7) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 0) (XEN) Notifying guest 0:1 (virq 1, port 0) (XEN) Notifying guest 0:2 (virq 1, port 0) (XEN) Notifying guest 0:3 (virq 1, port 0) (XEN) Notifying guest 0:4 (virq 1, port 0) (XEN) Notifying guest 0:5 (virq 1, port 0) (XEN) Notifying guest 0:6 (virq 1, port 0) (XEN) Notifying guest 0:7 (virq 1, port 0) --_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I am trying to enable Xen on our AARCh64 board, H= IP05 D02(http://hisilicon.github.io/2015/04/17/D02-hacking-manual)=

 

I have taken the latest Xen source code and build= it with the board dtb file.

 

The dts file was modified to include Xen and dom0= (3.19 based kernel) bootargs.

 

+*/

+        c= hosen {

+       &n= bsp;        #address-cells =3D <1>= ;

+       &n= bsp;        #size-cells =3D <1>;

+ 

+       &n= bsp;        xen,xen-bootargs =3D "d= om0_mem=3D128M console=3Ddtuart dtuart=3Dserial0";

+       &n= bsp;        xen,dom0-bootargs =3D "= console=3Dhvc0 earlyprintk root=3D/dev/sda2 rw loglevel=3D7";

+       &n= bsp;        module@0x7000000 {

+       &n= bsp;            = ;    compatible =3D "xen,linux-kernel", "xen,= multiboot-module";

+       &n= bsp;            = ;    reg =3D <0x7000000 0x300000>;

+       &n= bsp;        };

+        }= ;

+

 

I have to make the following changes to the Xen s= rc to get it booted on the board. The changes are basically to enable UART = and GIC. Our GIC is slightly different from ARM GICv3, but I have kept the = changes minimal such that it boots on the board(I am yet to figure out the exact differences with ARM GICv3 s= pec and our implementation and its impact on Xen).

 

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm= /Rules.mk

index e27f573..3e3c4ac 100644

--- a/xen/arch/arm/Rules.mk

+++ b/xen/arch/arm/Rules.mk

@@ -49,6 +49,7 @@ EARLY_PRINTK_dra7 &nbs= p;         :=3D 8250,0x4806A000,2

 EARLY_PRINTK_fastmodel   &nb= sp;  :=3D pl011,0x1c090000,115200

 EARLY_PRINTK_exynos5250   &n= bsp; :=3D exynos4210,0x12c20000

 EARLY_PRINTK_hip04-d01   &nb= sp;  :=3D 8250,0xE4007000,2

+EARLY_PRINTK_hip05-d02   &nbs= p;  :=3D 8250,0x80300000,2

 EARLY_PRINTK_juno    &n= bsp;      :=3D pl011,0x7ff80000

 EARLY_PRINTK_lager    &= nbsp;     :=3D scif,0xe6e60000

 EARLY_PRINTK_midway    =      :=3D pl011,0xfff36000

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm= /gic-v3.c

index 30682cf..10028d2 100644

--- a/xen/arch/arm/gic-v3.c

+++ b/xen/arch/arm/gic-v3.c

@@ -54,7 +54,7 @@ static struct {<= /p>

     paddr_t dbase_size;=

     void __iomem *map_dbase;=   /* Mapped address of distributor registers */

     struct rdist_region *rdi= st_regions;

-    uint32_t  rdist_stride;<= o:p>

+    uint64_t  rdist_stri= de;

     unsigned int rdist_count= ; /* Number of rdist regions count */

     unsigned int nr_prioriti= es;

     spinlock_t lock;

@@ -635,7 +635,8 @@ static int __init gicv3_p= opulate_rdist(void)

         = void __iomem *ptr =3D gicv3.rdist_regions[i].map_base;

 

         = reg =3D readl_relaxed(ptr + GICR_PIDR2) & GICR_PIDR2_ARCH_REV_MASK;=

-        if ( = (reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3 )<= /o:p>

+        i= f ( ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3 ) = &&

+       &n= bsp;    ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_= PIDR2_ARCH_GICV4))

         = {

        &= nbsp;    dprintk(XENLOG_ERR,

        &= nbsp;            &qu= ot;GICv3: No redistributor present @%"PRIpaddr"\n",

@@ -1221,7 +1222,8 @@ static int __init gicv3= _init(void)

         = panic("GICv3: Failed to ioremap for GIC distributor\n");

 

     reg =3D readl_relaxed(GI= CD + GICD_PIDR2) & GICD_PIDR2_ARCH_REV_MASK;

-    if ( ((reg >> GICD_PIDR= 2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) )

+    if ( ((reg >> GICD_= PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) &&

+       &n= bsp; ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV4) = )

        &= nbsp; panic("GICv3: no distributor detected\n");

 

     if ( !dt_property_read_u= 32(node, "#redistributor-regions",

@@ -1251,7 +1253,7 @@ static int __init gicv3= _init(void)

     /* The vGIC code require= s the region to be sorted */

     sort(rdist_regs, gicv3.r= dist_count, sizeof(*rdist_regs), cmp_rdist, NULL);

 

-    if ( !dt_property_read_u32(no= de, "redistributor-stride", &gicv3.rdist_stride) )=

+    if ( !dt_property_read_u6= 4(node, "redistributor-stride", &gicv3.rdist_stride) )

         = gicv3.rdist_stride =3D 0;

 

     gicv3.rdist_regions=3D r= dist_regs;

@@ -1277,7 +1279,7 @@ static int __init gicv3= _init(void)

        &= nbsp;   "      gic_dist_size=3D%&qu= ot;PRIpaddr"\n"

        &= nbsp;   "      gic_dist_mapaddr=3D%= p\n"

        &= nbsp;   "      gic_rdist_regions=3D= %d\n"

-        =    "      gic_rdist_stride=3D%x\n&q= uot;

+       &n= bsp;   "      gic_rdist_stride=3D%l= x\n"

        &= nbsp;   "      gic_rdist_base=3D%&q= uot;PRIpaddr"\n"

        &= nbsp;   "      gic_rdist_base_size= =3D%"PRIpaddr"\n"

        &= nbsp;   "      gic_rdist_base_mapad= dr=3D%p\n"

diff --git a/xen/include/asm-arm/domain.h b/xen/i= nclude/asm-arm/domain.h

index f1a087e..2df6f85 100644

--- a/xen/include/asm-arm/domain.h

+++ b/xen/include/asm-arm/domain.h

@@ -111,7 +111,7 @@ struct arch_domain

        &= nbsp;    unsigned int first_cpu;    &nbs= p;    /* First CPU handled */

         = } rdist_regions[MAX_RDIST_COUNT];

         = int nr_regions;          =            /* Number of r= dist regions */

-        uint3= 2_t rdist_stride;         &nbs= p;    /* Re-Distributor stride */

+        u= int64_t rdist_stride;         =      /* Re-Distributor stride */

 #endif

     } vgic;

 

diff --git a/xen/include/asm-arm/gic.h b/xen/incl= ude/asm-arm/gic.h

index 9e2acb7..e533583 100644

--- a/xen/include/asm-arm/gic.h

+++ b/xen/include/asm-arm/gic.h<= /o:p>

@@ -160,7 +160,8 @@

     DT_MATCH_COMPATIBLE(&quo= t;arm,cortex-a7-gic"),        =             &nb= sp;  \

     DT_MATCH_COMPATIBLE(&quo= t;arm,gic-400")

 

-#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(&quo= t;arm,gic-v3")

+//#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBL= E("arm,gic-v3")

+#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(= "hisilicon,gic-v3")

 

 /*

  * GICv3 registers that needs to be saved/r= estored

diff --git a/xen/include/asm-arm/gic_v3_defs.h b/= xen/include/asm-arm/gic_v3_defs.h

index 556f114..ed360a1 100644

--- a/xen/include/asm-arm/gic_v3_defs.h

+++ b/xen/include/asm-arm/gic_v3_defs= .h

@@ -62,10 +62,12 @@

 #define GICD_PIDR2_ARCH_REV_MASK  = ;   (0xf0)

 #define GICD_PIDR2_ARCH_REV_SHIFT &nbs= p;  (0x4)

 #define GICD_PIDR2_ARCH_GICV3  &n= bsp;     (0x3)

+#define GICD_PIDR2_ARCH_GICV4  &nb= sp;     (0x4)

 

 #define GICR_PIDR2_ARCH_REV_MASK  = ;   GICD_PIDR2_ARCH_REV_MASK

 #define GICR_PIDR2_ARCH_REV_SHIFT &nbs= p;  GICD_PIDR2_ARCH_REV_SHIFT

 #define GICR_PIDR2_ARCH_GICV3  &n= bsp;     GICD_PIDR2_ARCH_GICV3

+#define GICR_PIDR2_ARCH_GICV4  &nb= sp;     GICD_PIDR2_ARCH_GICV4

 

 #define GICR_SYNCR_NOT_BUSY  &nbs= p;       1

 /*

 

 

The xen image and dom0 kernel image is written in= to nor flash and UEFI boots Xen instead of a normal linux kernel. The Xen t= hen, loads the dom0 image to memory and tries to boot it.

The problem is in getting the dom0 booted. I can'= t see any prints from dom0. Please find attached log for details.

 

As I said, our GIC is slightly different from ARM= GICv3, but I am not 100% sure the dom0 boot issue is related to GIC or not= . From what I could analyse, dom0 stops very early. The pc points to the __= error_p (arch/arm64/kernel/head.S) symbol as per System.map file. And it looks to be Invalid processor type r= eturn after lookup_processor_type

 

Could you please take a look at the attached logs= and please let me know if you find anything suspicious in what I am doing.=

 

Thanks,

Shameer

 

FDTConfigTable Address: 0x7FBD0000

[LPC] SATA ExitBootServicesEvent

[LPC] GMAC ExitBootServicesEvent

- UART enabled -

- CPU 00020000 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Zero BSS -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) Checking for initrd in /chosen

(XEN) RAM: 0000000000000000 - 000000007fffffff

(XEN)

(XEN) MODULE[0]: 000000000018ad80 - 000000000018d= 29a Device Tree

(XEN) MODULE[1]: 0000000007000000 - 0000000007300= 000 Kernel

(XEN)

(XEN) Command line: dom0_mem=3D128M console=3Ddtu= art dtuart=3Dserial0

(XEN) Placing Xen at 0x000000007fe00000-0x0000000= 080000000

(XEN) Update BOOTMOD_XEN from 0000000000080000-00= 0000000018ad81 =3D> 000000007fe00000-000000007ff0ad81

(XEN) Domain heap initialised

(XEN) Platform: Generic System

(XEN) Looking for dtuart at "serial0", = options ""

 Xen 4.6-unstable

(XEN) Xen version 4.6-unstable (root@) (aarch64-l= inux-gnu-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.= 09) 4.9.2 20140904 (prerelease)) debug=3Dy Thu Jul 16 14:31:47 BST 2015

(XEN) Latest ChangeSet: Fri Jun 26 18:24:22 2015 = +0100 git:c40317f-dirty

(XEN) Processor: 411fd071: "ARM Limited"= ;, variant: 0x1, part 0xd07, rev 0x1

(XEN) 64-bit Execution:

(XEN)   Processor Features: 00000000010= 02222 0000000000000000

(XEN)     Exception Levels: E= L3:64+32 EL2:64+32 EL1:64+32 EL0:64+32

(XEN)     Extensions: Floatin= gPoint AdvancedSIMD GICv3-SysReg

(XEN)   Debug Features: 000000001030510= 6 0000000000000000

(XEN)   Auxiliary Features: 00000000000= 00000 0000000000000000

(XEN)   Memory Model Features: 00000000= 00001124 0000000000000000

(XEN)   ISA Features:  00000000000= 11120 0000000000000000

(XEN) 32-bit Execution:

(XEN)   Processor Features: 00000131:10= 011011

(XEN)     Instruction Sets: A= Arch32 A32 Thumb Thumb-2 Jazelle

(XEN)     Extensions: Generic= Timer Security

(XEN)   Debug Features: 03010066

(XEN)   Auxiliary Features: 00000000

(XEN)   Memory Model Features: 10101105= 40000000 01260000 02102211

(XEN)  ISA Features: 02101110 13112111 21232= 042 01112131 00011142 00011121

NOTICE:  [psci_smc_handler]:[239L] PSCI_VERS= ION CALL

NOTICE:  [psci_version]:[76L] PSCI_MAJOR_VER= : 0: PSCI_MINOR_VER: 2

 

00258>04

(XEN) Using PSCI-0.2 for SMP bringup

(XEN) Generic Timer IRQ: phys=3D30 hyp=3D26 virt= =3D27 Freq: 50000 KHz

(XEN) GICv3 initialization:

(XEN)       gic_dis= t_addr=3D000000008d000000

(XEN)       gic_dis= t_size=3D0000000000010000

(XEN)       gic_dis= t_mapaddr=3D000000004001a000

(XEN)       gic_rdi= st_regions=3D1

(XEN)       gic_rdi= st_stride=3D30000

(XEN)       gic_rdi= st_base=3D000000008d100000

(XEN)       gic_rdi= st_base_size=3D0000000000300000

(XEN)       gic_rdi= st_base_mapaddr=3D000000004002b000

(XEN)       gic_mai= ntenance_irq=3D25

(XEN) GICv3: 1024 lines, (IID 0204043b).

(XEN) GICv3: CPU0: Found redistributor in region = 0 @000000004002b000

(XEN) Using scheduler: SMP Credit Scheduler (cred= it)

(XEN) Allocated console ring of 128 KiB.

(XEN) Bringing up CPU1

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 001 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19790

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1b9c0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19790

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020001 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU1: Found redistributor in region = 0 @000000004005b000

(XEN) CPU 1 booted.

(XEN) Bringing up CPU2

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 002 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc199a0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1ba40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc199a0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020002 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU2: Found redistributor in region = 0 @000000004008b000

(XEN) CPU 2 booted.

(XEN) Bringing up CPU3

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 003 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19bb0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bac0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19bb0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020003 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU3: Found redistributor in region = 0 @00000000400bb000

(XEN) CPU 3 booted.

(XEN) Bringing up CPU4

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 100 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19dc0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bb40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19dc0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020100 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU4: Found redistributor in region = 0 @00000000400eb000

(XEN) CPU 4 booted.

(XEN) Bringing up CPU5

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 101 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19fd0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bbc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19fd0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020101 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU5: Found redistributor in region = 0 @000000004011b000

(XEN) CPU 5 booted.

(XEN) Bringing up CPU6

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 102 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a1e0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bc40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a1e0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020102 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU6: Found redistributor in region = 0 @000000004014b000

(XEN) CPU 6 booted.

(XEN) Bringing up CPU7

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 103 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a3f0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bcc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a3f0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020103 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU7: Found redistributor in region = 0 @000000004017b000

(XEN) CPU 7 booted.

(XEN) Bringing up CPU8

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 200 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a600

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bd40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a600

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020200 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU8: Found redistributor in region = 0 @00000000401ab000

(XEN) CPU 8 booted.

(XEN) Bringing up CPU9

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 201 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a810

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bdc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a810

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020201 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU9: Found redistributor in region = 0 @00000000401db000

(XEN) CPU 9 booted.

(XEN) Bringing up CPU10

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 202 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1aa20

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1be40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1aa20

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020202 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU10: Found redistributor in region= 0 @000000004020b000

(XEN) CPU 10 booted.

(XEN) Bringing up CPU11

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 203 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1ac30

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bec0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1ac30

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020203 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU11: Found redistributor in region= 0 @000000004023b000

(XEN) CPU 11 booted.

(XEN) Bringing up CPU12

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 300 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1ae40

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bf40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1ae40

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020300 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU12: Found redistributor in region= 0 @000000004026b000

(XEN) CPU 12 booted.

(XEN) Bringing up CPU13

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 301 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b050

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bfc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b050

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020301 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU13: Found redistributor in region= 0 @000000004029b000

(XEN) CPU 13 booted.

(XEN) Bringing up CPU14

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 302 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b260

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1c040

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b260

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020302 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU14: Found redistributor in region= 0 @00000000402cb000

(XEN) CPU 14 booted.

(XEN) Bringing up CPU15

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 303 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b470

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1c0c0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b470

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020303 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU15: Found redistributor in region= 0 @00000000402fb000

(XEN) CPU 15 booted.

(XEN) Brought up 16 CPUs

(XEN) P2M: 44-bit IPA with 44-bit PA

(XEN) P2M: 4 levels with order-0 root, VTCR 0x800= 43594

(XEN) I/O virtualisation disabled

(XEN) *** LOADING DOMAIN 0 ***

(XEN) Loading kernel from boot module @ 000000000= 7000000

(XEN) Allocating 1:1 mappings totalling 128MB for= dom0:

(XEN) BANK[0] 0x00000008000000-0x00000010000000 (= 128MB)

(XEN) Loading zImage from 0000000007000000 to 000= 0000008080000-0000000008380000

(XEN) Allocating PPI 16 for event channel interru= pt

(XEN) Loading dom0 DTB to 0x000000000fe00000-0x00= 0000000fe01ea5

(XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs=

(XEN) .done.

(XEN) Initial low memory virq threshold set at 0x= 4000 pages.

(XEN) Std. Loglevel: All

(XEN) Guest Loglevel: All

(XEN) *** Serial input -> DOM0 (type 'CTRL-a' = three times to switch input to Xen)

(XEN) Freed 264kB init memory.

(XEN) *** Serial input -> Xen (type 'CTRL-a' t= hree times to switch input to DOM0)

(XEN) 'd' pressed -> dumping registers

(XEN)

(XEN) *** Dumping CPU0 guest state (d0v0): ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    0

(XEN) PC:     000000000808276= 0

(XEN) LR:     000000000808101= c

(XEN) SP_EL0: 0000000000000000

(XEN) SP_EL1: 0000000000000000

(XEN) CPSR:   800001c5 MODE:64-bit EL1h= (Guest Kernel, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000004008000000  X2: ffffffc0000827a8

(XEN)      X3: 000000000= 0000000  X4: 0000000000000000  X5: 0000000000000000

(XEN)      X6: 000000000= 0000000  X7: 0000000000000000  X8: 0000000000000000

(XEN)      X9: 000000000= 0000000 X10: 0000000000000000 X11: 0000000000000000

(XEN)     X12: 00000000000000= 00 X13: 0000000000000016 X14: 0000000000000000

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 0000000000000000 X20: 0000000000000e11

(XEN)     X21: 000000000fe000= 00 X22: 00000000411fd071 X23: 0000000000000000

(XEN)     X24: 00000000080000= 00 X25: 0000000000000000 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000004008000000  FP: 0000000000000000

(XEN)

(XEN)    ELR_EL1: 0000000000000000=

(XEN)    ESR_EL1: 00000000

(XEN)    FAR_EL1: 0000000000000000=

(XEN)

(XEN)  SCTLR_EL1: 00c50838

(XEN)    TCR_EL1: 00000000

(XEN)  TTBR0_EL1: 0000000000000000

(XEN)  TTBR1_EL1: 0000000000000000

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 000100007fdd6000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000008038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Guest stack trace from sp=3D0:

(XEN)   Failed to convert stack to phys= ical address

(XEN)

(XEN) *** Dumping CPU1 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    1

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffdfe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000001  X2: 0000000000304450

(XEN)      X3: 000080007= ff12028  X4: 000080007fc08700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0d8d0  X7: 000080007ff0d8e8  X8: 000080007ff120b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffdfe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffdfe70:=

(XEN)    000080007ffdfe80 00000000= 0024ff54 000000000030ac98 0000000000000001

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000001>= ] 0000000000000001

(XEN)

(XEN) *** Dumping CPU2 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    2

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffcfe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000002  X2: 0000000000304450

(XEN)      X3: 000080007= ff10028  X4: 000080007fc06700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0dbc0  X7: 000080007ff0dbd8  X8: 000080007ff100b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000032

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffcfe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffcfe70:=

(XEN)    000080007ffcfe80 00000000= 0024ff54 000000000030ac98 0000000000000002

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000002>= ] 0000000000000002

(XEN)

(XEN) *** Dumping CPU3 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    3

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffc7e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000003  X2: 0000000000304450

(XEN)      X3: 000080007= ffd4028  X4: 000080007fcca700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0de20  X7: 000080007ff0de38  X8: 000080007ffd40b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000200

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffc7e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffc7e70:=

(XEN)    000080007ffc7e80 00000000= 0024ff54 000000000030ac98 0000000000000003

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000003>= ] 0000000000000003

(XEN)

(XEN) *** Dumping CPU4 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    4

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff7fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000004  X2: 0000000000304450

(XEN)      X3: 000080007= ffd2028  X4: 000080007fcc8700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd10a0  X7: 000080007ffd10b8  X8: 000080007ffd20b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000034

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff7fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff7fe70:=

(XEN)    000080007ff7fe80 00000000= 0024ff54 000000000030ac98 0000000000000004

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000004>= ] 0000000000000004

(XEN)

(XEN) *** Dumping CPU5 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    5

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff6fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000005  X2: 0000000000304450

(XEN)      X3: 000080007= ff76028  X4: 000080007fc6c700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1300  X7: 000080007ffd1318  X8: 000080007ff760b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000035

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff6fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff6fe70:=

(XEN)    000080007ff6fe80 00000000= 0024ff54 000000000030ac98 0000000000000005

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000005>= ] 0000000000000005

(XEN)

(XEN) *** Dumping CPU6 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    6

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff67e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000006  X2: 0000000000304450

(XEN)      X3: 000080007= ff72028  X4: 000080007fc68700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1560  X7: 000080007ffd1578  X8: 000080007ff720b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000036

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff67e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff67e70:=

(XEN)    000080007ff67e80 00000000= 0024ff54 000000000030ac98 0000000000000006

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000006>= ] 0000000000000006

(XEN)

(XEN) *** Dumping CPU7 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    7

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff57e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000007  X2: 0000000000304450

(XEN)      X3: 000080007= ff70028  X4: 000080007fc66700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd17c0  X7: 000080007ffd17d8  X8: 000080007ff700b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000037

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff57e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff57e70:=

(XEN)    000080007ff57e80 00000000= 0024ff54 000000000030ac98 0000000000000007

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000007>= ] 0000000000000007

(XEN)

(XEN) *** Dumping CPU8 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    8

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff4fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000008  X2: 0000000000304450

(XEN)      X3: 000080007= ff5c028  X4: 000080007fc52700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1a20  X7: 000080007ffd1a38  X8: 000080007ff5c0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000038

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff4fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff4fe70:=

(XEN)    000080007ff4fe80 00000000= 0024ff54 000000000030ac98 0000000000000008

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000008>= ] 0000000000000008

(XEN)

(XEN) *** Dumping CPU9 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    9

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff47e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000009  X2: 0000000000304450

(XEN)      X3: 000080007= ff5a028  X4: 000080007fc50700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1c80  X7: 000080007ffd1c98  X8: 000080007ff5a0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000039

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff47e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff47e70:=

(XEN)    000080007ff47e80 00000000= 0024ff54 000000000030ac98 0000000000000009

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000009>= ] 0000000000000009

(XEN)

(XEN) *** Dumping CPU10 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    10

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffb7e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000a  X2: 0000000000304450

(XEN)      X3: 000080007= ffbe028  X4: 000080007fcb4700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1ee0  X7: 000080007ffd1ef8  X8: 000080007ffbe0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffb7e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffb7e70:=

(XEN)    000080007ffb7e80 00000000= 0024ff54 000000000030ac98 000000000000000a

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000a>= ] 000000000000000a

(XEN)

(XEN) *** Dumping CPU11 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    11

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffafe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000b  X2: 0000000000304450

(XEN)      X3: 000080007= ffba028  X4: 000080007fcb0700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd180  X7: 000080007ffbd198  X8: 000080007ffba0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffafe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffafe70:=

(XEN)    000080007ffafe80 00000000= 0024ff54 000000000030ac98 000000000000000b

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000b>= ] 000000000000000b

(XEN)

(XEN) *** Dumping CPU12 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    12

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff9fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000c  X2: 0000000000304450

(XEN)      X3: 000080007= ffb8028  X4: 000080007fcae700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd3e0  X7: 000080007ffbd3f8  X8: 000080007ffb80b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff9fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff9fe70:=

(XEN)    000080007ff9fe80 00000000= 0024ff54 000000000030ac98 000000000000000c

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000c>= ] 000000000000000c

(XEN)

(XEN) *** Dumping CPU13 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    13

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff97e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000d  X2: 0000000000304450

(XEN)      X3: 000080007= ffa4028  X4: 000080007fc9a700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd640  X7: 000080007ffbd658  X8: 000080007ffa40b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff97e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff97e70:=

(XEN)    000080007ff97e80 00000000= 0024ff54 000000000030ac98 000000000000000d

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000d>= ] 000000000000000d

(XEN)

(XEN) *** Dumping CPU14 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    14

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff8fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000e  X2: 0000000000304450

(XEN)      X3: 000080007= ffa2028  X4: 000080007fc98700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd8a0  X7: 000080007ffbd8b8  X8: 000080007ffa20b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff8fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff8fe70:=

(XEN)    000080007ff8fe80 00000000= 0024ff54 000000000030ac98 000000000000000e

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000e>= ] 000000000000000e

(XEN)

(XEN) *** Dumping CPU15 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    15

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007fdffe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000f  X2: 0000000000304450

(XEN)      X3: 000080007= ff86028  X4: 000080007fc7c700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbdb00  X7: 000080007ffbdb18  X8: 000080007ff860b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007fdffe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007fdffe70:=

(XEN)    000080007fdffe80 00000000= 0024ff54 000000000030ac98 000000000000000f

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000f>= ] 000000000000000f

(XEN)

(XEN) 'q' pressed -> dumping domain info (now= =3D0x8:BFE1C2E8)

(XEN) General information for domain 0:

(XEN)     refcnt=3D3 dying=3D= 0 pause_count=3D0

(XEN)     nr_pages=3D32768 xe= nheap_pages=3D5 shared_pages=3D0 paged_pages=3D0 dirty_cpus=3D{} max_pages= =3D4294967295

(XEN)     handle=3D00000000-0= 000-0000-0000-000000000000 vm_assist=3D00000000

(XEN) p2m mappings for domain 0 (vmid 1):

(XEN)   1G mappings: 0 (shattered 0)

(XEN)   2M mappings: 64 (shattered 0)

(XEN)   4K mappings: 328

(XEN) Rangesets belonging to domain 0:=

(XEN)     Interrupts { 344-34= 5, 348, 350 }

(XEN)     I/O Memory { 80040-= 80041, 802e0-80300, 80310-80340, 8c030-8c040, a0040-a0041, a00e0-a0110, a10= 00-a1020, a3030-a3040, b0000-b0010, b0040-b0041, b0080-b00a0, b00d0-b00f0, = b1000-b1013, b7030-b7040, c0040-c0041, c6030-c6040, 22000000-22000001, 24000000-24000001 }

(XEN) NODE affinity for domain 0: [0]<= /p>

(XEN) VCPU information and callbacks for domain 0= :

(XEN)     VCPU0: CPU0 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D01 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D0

(XEN) GICH_LRs (vcpu 0) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU1: CPU1 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 1) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU2: CPU2 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 2) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU3: CPU3 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 3) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU4: CPU4 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 4) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU5: CPU5 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 5) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU6: CPU6 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 6) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU7: CPU7 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 7) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN) Notifying guest 0:0 (virq 1, port 0)

(XEN) Notifying guest 0:1 (virq 1, port 0)

(XEN) Notifying guest 0:2 (virq 1, port 0)

(XEN) Notifying guest 0:3 (virq 1, port 0)

(XEN) Notifying guest 0:4 (virq 1, port 0)

(XEN) Notifying guest 0:5 (virq 1, port 0)

(XEN) Notifying guest 0:6 (virq 1, port 0)

(XEN) Notifying guest 0:7 (virq 1, port 0)

 

--_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_-- --===============2095908660014434974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2095908660014434974==-- From xen-users-bounces@lists.xen.org Thu Jul 16 15:26:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 15:26:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFl2O-0002PT-7P; Thu, 16 Jul 2015 15:25:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFl2M-0002PO-3u for xen-users@lists.xen.org; Thu, 16 Jul 2015 15:25:26 +0000 Received: from [193.109.254.147] by server-3.bemta-14.messagelabs.com id 9E/E6-18676-5ECC7A55; Thu, 16 Jul 2015 15:25:25 +0000 X-Env-Sender: shameerali.kolothum.thodi@huawei.com X-Msg-Ref: server-7.tower-27.messagelabs.com!1437060324!32694707!1 X-Originating-IP: [194.213.3.17] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28682 invoked from network); 16 Jul 2015 15:25:24 -0000 Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17) by server-7.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 15:25:24 -0000 Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVG76240; Thu, 16 Jul 2015 15:25:23 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml404-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Thu, 16 Jul 2015 16:25:15 +0100 From: Shameerali Kolothum Thodi To: "xen-users@lists.xen.org" Thread-Topic: Enabling Xen on HiSilicon HIP05 board Thread-Index: AdC/251i+NuBdUzGQjeNno2OKWRg/A== Date: Thu, 16 Jul 2015 15:25:15 +0000 Message-ID: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.137.235] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Julien Grall , Zoltan Kiss , Ian Campbell Subject: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2095908660014434974==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2095908660014434974== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_" --_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, I am trying to enable Xen on our AARCh64 board, HIP05 D02(http://hisilicon.= github.io/2015/04/17/D02-hacking-manual) I have taken the latest Xen source code and build it with the board dtb fil= e. The dts file was modified to include Xen and dom0(3.19 based kernel) bootar= gs. +*/ + chosen { + #address-cells =3D <1>; + #size-cells =3D <1>; + + xen,xen-bootargs =3D "dom0_mem=3D128M console=3Ddtuart dtu= art=3Dserial0"; + xen,dom0-bootargs =3D "console=3Dhvc0 earlyprintk root=3D/= dev/sda2 rw loglevel=3D7"; + module@0x7000000 { + compatible =3D "xen,linux-kernel", "xen,multiboot-= module"; + reg =3D <0x7000000 0x300000>; + }; + }; + I have to make the following changes to the Xen src to get it booted on the= board. The changes are basically to enable UART and GIC. Our GIC is slight= ly different from ARM GICv3, but I have kept the changes minimal such that = it boots on the board(I am yet to figure out the exact differences with ARM= GICv3 spec and our implementation and its impact on Xen). diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm/Rules.mk index e27f573..3e3c4ac 100644 --- a/xen/arch/arm/Rules.mk +++ b/xen/arch/arm/Rules.mk @@ -49,6 +49,7 @@ EARLY_PRINTK_dra7 :=3D 8250,0x4806A000,2 EARLY_PRINTK_fastmodel :=3D pl011,0x1c090000,115200 EARLY_PRINTK_exynos5250 :=3D exynos4210,0x12c20000 EARLY_PRINTK_hip04-d01 :=3D 8250,0xE4007000,2 +EARLY_PRINTK_hip05-d02 :=3D 8250,0x80300000,2 EARLY_PRINTK_juno :=3D pl011,0x7ff80000 EARLY_PRINTK_lager :=3D scif,0xe6e60000 EARLY_PRINTK_midway :=3D pl011,0xfff36000 diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm/gic-v3.c index 30682cf..10028d2 100644 --- a/xen/arch/arm/gic-v3.c +++ b/xen/arch/arm/gic-v3.c @@ -54,7 +54,7 @@ static struct { paddr_t dbase_size; void __iomem *map_dbase; /* Mapped address of distributor registers *= / struct rdist_region *rdist_regions; - uint32_t rdist_stride; + uint64_t rdist_stride; unsigned int rdist_count; /* Number of rdist regions count */ unsigned int nr_priorities; spinlock_t lock; @@ -635,7 +635,8 @@ static int __init gicv3_populate_rdist(void) void __iomem *ptr =3D gicv3.rdist_regions[i].map_base; reg =3D readl_relaxed(ptr + GICR_PIDR2) & GICR_PIDR2_ARCH_REV_MASK= ; - if ( (reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3= ) + if ( ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV= 3 ) && + ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV4= )) { dprintk(XENLOG_ERR, "GICv3: No redistributor present @%"PRIpaddr"\n", @@ -1221,7 +1222,8 @@ static int __init gicv3_init(void) panic("GICv3: Failed to ioremap for GIC distributor\n"); reg =3D readl_relaxed(GICD + GICD_PIDR2) & GICD_PIDR2_ARCH_REV_MASK; - if ( ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) ) + if ( ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) &= & + ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV4) ) panic("GICv3: no distributor detected\n"); if ( !dt_property_read_u32(node, "#redistributor-regions", @@ -1251,7 +1253,7 @@ static int __init gicv3_init(void) /* The vGIC code requires the region to be sorted */ sort(rdist_regs, gicv3.rdist_count, sizeof(*rdist_regs), cmp_rdist, NU= LL); - if ( !dt_property_read_u32(node, "redistributor-stride", &gicv3.rdist_= stride) ) + if ( !dt_property_read_u64(node, "redistributor-stride", &gicv3.rdist_= stride) ) gicv3.rdist_stride =3D 0; gicv3.rdist_regions=3D rdist_regs; @@ -1277,7 +1279,7 @@ static int __init gicv3_init(void) " gic_dist_size=3D%"PRIpaddr"\n" " gic_dist_mapaddr=3D%p\n" " gic_rdist_regions=3D%d\n" - " gic_rdist_stride=3D%x\n" + " gic_rdist_stride=3D%lx\n" " gic_rdist_base=3D%"PRIpaddr"\n" " gic_rdist_base_size=3D%"PRIpaddr"\n" " gic_rdist_base_mapaddr=3D%p\n" diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h index f1a087e..2df6f85 100644 --- a/xen/include/asm-arm/domain.h +++ b/xen/include/asm-arm/domain.h @@ -111,7 +111,7 @@ struct arch_domain unsigned int first_cpu; /* First CPU handled */ } rdist_regions[MAX_RDIST_COUNT]; int nr_regions; /* Number of rdist regions */ - uint32_t rdist_stride; /* Re-Distributor stride */ + uint64_t rdist_stride; /* Re-Distributor stride */ #endif } vgic; diff --git a/xen/include/asm-arm/gic.h b/xen/include/asm-arm/gic.h index 9e2acb7..e533583 100644 --- a/xen/include/asm-arm/gic.h +++ b/xen/include/asm-arm/gic.h @@ -160,7 +160,8 @@ DT_MATCH_COMPATIBLE("arm,cortex-a7-gic"), \ DT_MATCH_COMPATIBLE("arm,gic-400") -#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3") +//#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("arm,gic-v3") +#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE("hisilicon,gic-v3") /* * GICv3 registers that needs to be saved/restored diff --git a/xen/include/asm-arm/gic_v3_defs.h b/xen/include/asm-arm/gic_v3= _defs.h index 556f114..ed360a1 100644 --- a/xen/include/asm-arm/gic_v3_defs.h +++ b/xen/include/asm-arm/gic_v3_defs.h @@ -62,10 +62,12 @@ #define GICD_PIDR2_ARCH_REV_MASK (0xf0) #define GICD_PIDR2_ARCH_REV_SHIFT (0x4) #define GICD_PIDR2_ARCH_GICV3 (0x3) +#define GICD_PIDR2_ARCH_GICV4 (0x4) #define GICR_PIDR2_ARCH_REV_MASK GICD_PIDR2_ARCH_REV_MASK #define GICR_PIDR2_ARCH_REV_SHIFT GICD_PIDR2_ARCH_REV_SHIFT #define GICR_PIDR2_ARCH_GICV3 GICD_PIDR2_ARCH_GICV3 +#define GICR_PIDR2_ARCH_GICV4 GICD_PIDR2_ARCH_GICV4 #define GICR_SYNCR_NOT_BUSY 1 /* The xen image and dom0 kernel image is written into nor flash and UEFI boot= s Xen instead of a normal linux kernel. The Xen then, loads the dom0 image = to memory and tries to boot it. The problem is in getting the dom0 booted. I can't see any prints from dom0= . Please find attached log for details. As I said, our GIC is slightly different from ARM GICv3, but I am not 100% = sure the dom0 boot issue is related to GIC or not. From what I could analys= e, dom0 stops very early. The pc points to the __error_p (arch/arm64/kernel= /head.S) symbol as per System.map file. And it looks to be Invalid processo= r type return after lookup_processor_type Could you please take a look at the attached logs and please let me know if= you find anything suspicious in what I am doing. Thanks, Shameer FDTConfigTable Address: 0x7FBD0000 [LPC] SATA ExitBootServicesEvent [LPC] GMAC ExitBootServicesEvent - UART enabled - - CPU 00020000 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000000000000 - 000000007fffffff (XEN) (XEN) MODULE[0]: 000000000018ad80 - 000000000018d29a Device Tree (XEN) MODULE[1]: 0000000007000000 - 0000000007300000 Kernel (XEN) (XEN) Command line: dom0_mem=3D128M console=3Ddtuart dtuart=3Dserial0 (XEN) Placing Xen at 0x000000007fe00000-0x0000000080000000 (XEN) Update BOOTMOD_XEN from 0000000000080000-000000000018ad81 =3D> 000000= 007fe00000-000000007ff0ad81 (XEN) Domain heap initialised (XEN) Platform: Generic System (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (root@) (aarch64-linux-gnu-gcc (crosstool-NG= linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.09) 4.9.2 20140904 (prerel= ease)) debug=3Dy Thu Jul 16 14:31:47 BST 2015 (XEN) Latest ChangeSet: Fri Jun 26 18:24:22 2015 +0100 git:c40317f-dirty (XEN) Processor: 411fd071: "ARM Limited", variant: 0x1, part 0xd07, rev 0x1 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000001002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD GICv3-SysReg (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001124 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:10011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 NOTICE: [psci_smc_handler]:[239L] PSCI_VERSION CALL NOTICE: [psci_version]:[76L] PSCI_MAJOR_VER: 0: PSCI_MINOR_VER: 2 00258>04 (XEN) Using PSCI-0.2 for SMP bringup (XEN) Generic Timer IRQ: phys=3D30 hyp=3D26 virt=3D27 Freq: 50000 KHz (XEN) GICv3 initialization: (XEN) gic_dist_addr=3D000000008d000000 (XEN) gic_dist_size=3D0000000000010000 (XEN) gic_dist_mapaddr=3D000000004001a000 (XEN) gic_rdist_regions=3D1 (XEN) gic_rdist_stride=3D30000 (XEN) gic_rdist_base=3D000000008d100000 (XEN) gic_rdist_base_size=3D0000000000300000 (XEN) gic_rdist_base_mapaddr=3D000000004002b000 (XEN) gic_maintenance_irq=3D25 (XEN) GICv3: 1024 lines, (IID 0204043b). (XEN) GICv3: CPU0: Found redistributor in region 0 @000000004002b000 (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 128 KiB. (XEN) Bringing up CPU1 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20001 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19790 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1b9c0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19790 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020001 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU1: Found redistributor in region 0 @000000004005b000 (XEN) CPU 1 booted. (XEN) Bringing up CPU2 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20002 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc199a0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1ba40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc199a0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020002 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU2: Found redistributor in region 0 @000000004008b000 (XEN) CPU 2 booted. (XEN) Bringing up CPU3 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20003 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19bb0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x1 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bac0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19bb0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020003 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU3: Found redistributor in region 0 @00000000400bb000 (XEN) CPU 3 booted. (XEN) Bringing up CPU4 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20100 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19dc0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x1 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bb40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19dc0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU4: Found redistributor in region 0 @00000000400eb000 (XEN) CPU 4 booted. (XEN) Bringing up CPU5 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20101 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc19fd0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bbc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc19fd0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020101 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU5: Found redistributor in region 0 @000000004011b000 (XEN) CPU 5 booted. (XEN) Bringing up CPU6 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20102 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a1e0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bc40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a1e0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020102 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU6: Found redistributor in region 0 @000000004014b000 (XEN) CPU 6 booted. (XEN) Bringing up CPU7 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20103 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a3f0 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x3 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bcc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a3f0 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020103 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU7: Found redistributor in region 0 @000000004017b000 (XEN) CPU 7 booted. (XEN) Bringing up CPU8 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20200 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a600 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x3 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bd40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a600 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020200 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU8: Found redistributor in region 0 @00000000401ab000 (XEN) CPU 8 booted. (XEN) Bringing up CPU9 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20201 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1a810 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bdc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1a810 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020201 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU9: Found redistributor in region 0 @00000000401db000 (XEN) CPU 9 booted. (XEN) Bringing up CPU10 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20202 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1aa20 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1be40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1aa20 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020202 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU10: Found redistributor in region 0 @000000004020b000 (XEN) CPU 10 booted. (XEN) Bringing up CPU11 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20203 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1ac30 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0x7 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bec0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1ac30 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020203 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU11: Found redistributor in region 0 @000000004023b000 (XEN) CPU 11 booted. (XEN) Bringing up CPU12 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20300 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1ae40 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0x7 NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bf40 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1ae40 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020300 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU12: Found redistributor in region 0 @000000004026b000 (XEN) CPU 12 booted. (XEN) Bringing up CPU13 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20301 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b050 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1bfc0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b050 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020301 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU13: Found redistributor in region 0 @000000004029b000 (XEN) CPU 13 booted. (XEN) Bringing up CPU14 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20302 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b260 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1c040 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b260 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020302 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU14: Found redistributor in region 0 @00000000402cb000 (XEN) CPU 14 booted. (XEN) Bringing up CPU15 NOTICE: [psci_smc_handler]:[252L] PSCI_CPU_ON_AARCH32 CALL NOTICE: [psci_smc_handler]:[253L] x1=3D0x20303 x2=3D0x7fe00184 x3=3D0x0 NOTICE: [cm_init_context]:[238L] ctx add =3D 7fc1b470 NOTICE: [scpi_set_css_power_state]:[100L] domain_cluster=3D0xf NOTICE: [scpi_set_css_power_state]:[113L] domain_cluster=3D0xf 00258A>B04 NOTICE: [psci_afflvl_power_on_finish]:[496L] NOTICE: [cm_prepare_el3_exit]:[254L] read_tpidr_el3 =3D 7fc1c0c0 NOTICE: [cm_prepare_el3_exit]:[298L] ctx add =3D 7fc1b470 NOTICE: [psci_afflvl_power_on_finish]:[557L] 7?>00184 - CPU 00020303 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) GICv3: CPU15: Found redistributor in region 0 @00000000402fb000 (XEN) CPU 15 booted. (XEN) Brought up 16 CPUs (XEN) P2M: 44-bit IPA with 44-bit PA (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 0000000007000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) (XEN) Loading zImage from 0000000007000000 to 0000000008080000-000000000838= 0000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs (XEN) .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input t= o Xen) (XEN) Freed 264kB init memory. (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to= DOM0) (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 guest state (d0v0): *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 0 (XEN) PC: 0000000008082760 (XEN) LR: 000000000808101c (XEN) SP_EL0: 0000000000000000 (XEN) SP_EL1: 0000000000000000 (XEN) CPSR: 800001c5 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000000 X1: 0000004008000000 X2: ffffffc0000827a8 (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000000 (XEN) X6: 0000000000000000 X7: 0000000000000000 X8: 0000000000000000 (XEN) X9: 0000000000000000 X10: 0000000000000000 X11: 0000000000000000 (XEN) X12: 0000000000000000 X13: 0000000000000016 X14: 0000000000000000 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 0000000000000000 X20: 0000000000000e11 (XEN) X21: 000000000fe00000 X22: 00000000411fd071 X23: 0000000000000000 (XEN) X24: 0000000008000000 X25: 0000000000000000 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000004008000000 FP: 0000000000000000 (XEN) (XEN) ELR_EL1: 0000000000000000 (XEN) ESR_EL1: 00000000 (XEN) FAR_EL1: 0000000000000000 (XEN) (XEN) SCTLR_EL1: 00c50838 (XEN) TCR_EL1: 00000000 (XEN) TTBR0_EL1: 0000000000000000 (XEN) TTBR1_EL1: 0000000000000000 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 000100007fdd6000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000008038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Guest stack trace from sp=3D0: (XEN) Failed to convert stack to physical address (XEN) (XEN) *** Dumping CPU1 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 1 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffdfe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000001 X2: 0000000000304450 (XEN) X3: 000080007ff12028 X4: 000080007fc08700 X5: 0000000002faf080 (XEN) X6: 000080007ff0d8d0 X7: 000080007ff0d8e8 X8: 000080007ff120b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020001 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffdfe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffdfe70: (XEN) 000080007ffdfe80 000000000024ff54 000000000030ac98 000000000000000= 1 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000001>] 0000000000000001 (XEN) (XEN) *** Dumping CPU2 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 2 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffcfe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000002 X2: 0000000000304450 (XEN) X3: 000080007ff10028 X4: 000080007fc06700 X5: 0000000002faf080 (XEN) X6: 000080007ff0dbc0 X7: 000080007ff0dbd8 X8: 000080007ff100b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000032 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020002 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffcfe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffcfe70: (XEN) 000080007ffcfe80 000000000024ff54 000000000030ac98 000000000000000= 2 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000002>] 0000000000000002 (XEN) (XEN) *** Dumping CPU3 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 3 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffc7e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000003 X2: 0000000000304450 (XEN) X3: 000080007ffd4028 X4: 000080007fcca700 X5: 0000000002faf080 (XEN) X6: 000080007ff0de20 X7: 000080007ff0de38 X8: 000080007ffd40b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000200 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020003 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffc7e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffc7e70: (XEN) 000080007ffc7e80 000000000024ff54 000000000030ac98 000000000000000= 3 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000003>] 0000000000000003 (XEN) (XEN) *** Dumping CPU4 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 4 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff7fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000004 X2: 0000000000304450 (XEN) X3: 000080007ffd2028 X4: 000080007fcc8700 X5: 0000000002faf080 (XEN) X6: 000080007ffd10a0 X7: 000080007ffd10b8 X8: 000080007ffd20b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000034 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020100 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff7fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff7fe70: (XEN) 000080007ff7fe80 000000000024ff54 000000000030ac98 000000000000000= 4 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000004>] 0000000000000004 (XEN) (XEN) *** Dumping CPU5 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 5 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff6fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000005 X2: 0000000000304450 (XEN) X3: 000080007ff76028 X4: 000080007fc6c700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1300 X7: 000080007ffd1318 X8: 000080007ff760b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000035 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020101 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff6fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff6fe70: (XEN) 000080007ff6fe80 000000000024ff54 000000000030ac98 000000000000000= 5 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000005>] 0000000000000005 (XEN) (XEN) *** Dumping CPU6 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 6 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff67e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000006 X2: 0000000000304450 (XEN) X3: 000080007ff72028 X4: 000080007fc68700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1560 X7: 000080007ffd1578 X8: 000080007ff720b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000036 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020102 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff67e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff67e70: (XEN) 000080007ff67e80 000000000024ff54 000000000030ac98 000000000000000= 6 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000006>] 0000000000000006 (XEN) (XEN) *** Dumping CPU7 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 7 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff57e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000007 X2: 0000000000304450 (XEN) X3: 000080007ff70028 X4: 000080007fc66700 X5: 0000000002faf080 (XEN) X6: 000080007ffd17c0 X7: 000080007ffd17d8 X8: 000080007ff700b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000037 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020103 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff57e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff57e70: (XEN) 000080007ff57e80 000000000024ff54 000000000030ac98 000000000000000= 7 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000007>] 0000000000000007 (XEN) (XEN) *** Dumping CPU8 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 8 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff4fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000008 X2: 0000000000304450 (XEN) X3: 000080007ff5c028 X4: 000080007fc52700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1a20 X7: 000080007ffd1a38 X8: 000080007ff5c0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000038 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020200 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff4fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff4fe70: (XEN) 000080007ff4fe80 000000000024ff54 000000000030ac98 000000000000000= 8 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000008>] 0000000000000008 (XEN) (XEN) *** Dumping CPU9 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 9 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff47e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 0000000000000009 X2: 0000000000304450 (XEN) X3: 000080007ff5a028 X4: 000080007fc50700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1c80 X7: 000080007ffd1c98 X8: 000080007ff5a0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000039 (XEN) X12: 0000000000000001 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020201 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff47e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff47e70: (XEN) 000080007ff47e80 000000000024ff54 000000000030ac98 000000000000000= 9 (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<0000000000000009>] 0000000000000009 (XEN) (XEN) *** Dumping CPU10 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 10 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffb7e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000a X2: 0000000000304450 (XEN) X3: 000080007ffbe028 X4: 000080007fcb4700 X5: 0000000002faf080 (XEN) X6: 000080007ffd1ee0 X7: 000080007ffd1ef8 X8: 000080007ffbe0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020202 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffb7e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffb7e70: (XEN) 000080007ffb7e80 000000000024ff54 000000000030ac98 000000000000000= a (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000a>] 000000000000000a (XEN) (XEN) *** Dumping CPU11 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 11 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ffafe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000b X2: 0000000000304450 (XEN) X3: 000080007ffba028 X4: 000080007fcb0700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd180 X7: 000080007ffbd198 X8: 000080007ffba0b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020203 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ffafe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ffafe70: (XEN) 000080007ffafe80 000000000024ff54 000000000030ac98 000000000000000= b (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000b>] 000000000000000b (XEN) (XEN) *** Dumping CPU12 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 12 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff9fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000c X2: 0000000000304450 (XEN) X3: 000080007ffb8028 X4: 000080007fcae700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd3e0 X7: 000080007ffbd3f8 X8: 000080007ffb80b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020300 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff9fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff9fe70: (XEN) 000080007ff9fe80 000000000024ff54 000000000030ac98 000000000000000= c (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000c>] 000000000000000c (XEN) (XEN) *** Dumping CPU13 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 13 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff97e70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000d X2: 0000000000304450 (XEN) X3: 000080007ffa4028 X4: 000080007fc9a700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd640 X7: 000080007ffbd658 X8: 000080007ffa40b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020301 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff97e70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff97e70: (XEN) 000080007ff97e80 000000000024ff54 000000000030ac98 000000000000000= d (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000d>] 000000000000000d (XEN) (XEN) *** Dumping CPU14 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 14 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007ff8fe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000e X2: 0000000000304450 (XEN) X3: 000080007ffa2028 X4: 000080007fc98700 X5: 0000000002faf080 (XEN) X6: 000080007ffbd8a0 X7: 000080007ffbd8b8 X8: 000080007ffa20b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020302 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007ff8fe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007ff8fe70: (XEN) 000080007ff8fe80 000000000024ff54 000000000030ac98 000000000000000= e (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000e>] 000000000000000e (XEN) (XEN) *** Dumping CPU15 host state: *** (XEN) ----[ Xen-4.6-unstable arm64 debug=3Dy Not tainted ]---- (XEN) CPU: 15 (XEN) PC: 00000000002437a4 idle_loop+0x12c/0x154 (XEN) LR: 00000000002437ac (XEN) SP: 000080007fdffe70 (XEN) CPSR: 20000249 MODE:64-bit EL2h (Hypervisor, handler) (XEN) X0: 0000000000000000 X1: 000000000000000f X2: 0000000000304450 (XEN) X3: 000080007ff86028 X4: 000080007fc7c700 X5: 0000000002faf080 (XEN) X6: 000080007ffbdb00 X7: 000080007ffbdb18 X8: 000080007ff860b0 (XEN) X9: 0000000000000200 X10: 0000000000000100 X11: 0000000000000031 (XEN) X12: 0000000000000002 X13: 0000000000262e18 X14: 0000000000000020 (XEN) X15: 0000000000000000 X16: 0000000000000000 X17: 0000000000000000 (XEN) X18: 0000000000000000 X19: 000000000030ac98 X20: 00000000002c9300 (XEN) X21: 000000000030ac98 X22: 0000000000309a60 X23: 000000000030ac98 (XEN) X24: 0000000000020303 X25: 0000000000000001 X26: 0000000000000000 (XEN) X27: 0000000000000000 X28: 0000000000000000 FP: 000080007fdffe70 (XEN) (XEN) VTCR_EL2: 80043594 (XEN) VTTBR_EL2: 0000000000000000 (XEN) (XEN) SCTLR_EL2: 30cd183d (XEN) HCR_EL2: 000000000038643f (XEN) TTBR0_EL2: 000000007fef4000 (XEN) (XEN) ESR_EL2: 00000000 (XEN) HPFAR_EL2: 0000000000000000 (XEN) FAR_EL2: 0000000000000000 (XEN) (XEN) Xen stack trace from sp=3D000080007fdffe70: (XEN) 000080007fdffe80 000000000024ff54 000000000030ac98 000000000000000= f (XEN) 0000000000304470 0000000000000001 0000000000400000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 0000000000000000 000000000000000= 0 (XEN) 0000000000000000 0000000000000000 (XEN) Xen call trace: (XEN) [<00000000002437a4>] idle_loop+0x12c/0x154 (PC) (XEN) [<00000000002437ac>] idle_loop+0x134/0x154 (LR) (XEN) [<000000000024ff54>] start_secondary+0x14c/0x15c (XEN) [<000000000000000f>] 000000000000000f (XEN) (XEN) 'q' pressed -> dumping domain info (now=3D0x8:BFE1C2E8) (XEN) General information for domain 0: (XEN) refcnt=3D3 dying=3D0 pause_count=3D0 (XEN) nr_pages=3D32768 xenheap_pages=3D5 shared_pages=3D0 paged_pages= =3D0 dirty_cpus=3D{} max_pages=3D4294967295 (XEN) handle=3D00000000-0000-0000-0000-000000000000 vm_assist=3D0000000= 0 (XEN) p2m mappings for domain 0 (vmid 1): (XEN) 1G mappings: 0 (shattered 0) (XEN) 2M mappings: 64 (shattered 0) (XEN) 4K mappings: 328 (XEN) Rangesets belonging to domain 0: (XEN) Interrupts { 344-345, 348, 350 } (XEN) I/O Memory { 80040-80041, 802e0-80300, 80310-80340, 8c030-8c040, = a0040-a0041, a00e0-a0110, a1000-a1020, a3030-a3040, b0000-b0010, b0040-b004= 1, b0080-b00a0, b00d0-b00f0, b1000-b1013, b7030-b7040, c0040-c0041, c6030-c= 6040, 22000000-22000001, 24000000-24000001 } (XEN) NODE affinity for domain 0: [0] (XEN) VCPU information and callbacks for domain 0: (XEN) VCPU0: CPU0 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D01 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D0 (XEN) GICH_LRs (vcpu 0) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU1: CPU1 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 1) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU2: CPU2 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 2) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU3: CPU3 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 3) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU4: CPU4 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 4) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU5: CPU5 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 5) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU6: CPU6 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 6) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) VCPU7: CPU7 [has=3DF] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 = dirty_cpus=3D{} (XEN) cpu_hard_affinity=3D{0-127} cpu_soft_affinity=3D{0-127} (XEN) pause_count=3D0 pause_flags=3D2 (XEN) GICH_LRs (vcpu 7) mask=3D0 (XEN) VCPU_LR[0]=3D0 (XEN) VCPU_LR[1]=3D0 (XEN) VCPU_LR[2]=3D0 (XEN) VCPU_LR[3]=3D0 (XEN) No periodic timer (XEN) Notifying guest 0:0 (virq 1, port 0) (XEN) Notifying guest 0:1 (virq 1, port 0) (XEN) Notifying guest 0:2 (virq 1, port 0) (XEN) Notifying guest 0:3 (virq 1, port 0) (XEN) Notifying guest 0:4 (virq 1, port 0) (XEN) Notifying guest 0:5 (virq 1, port 0) (XEN) Notifying guest 0:6 (virq 1, port 0) (XEN) Notifying guest 0:7 (virq 1, port 0) --_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

I am trying to enable Xen on our AARCh64 board, H= IP05 D02(http://hisilicon.github.io/2015/04/17/D02-hacking-manual)=

 

I have taken the latest Xen source code and build= it with the board dtb file.

 

The dts file was modified to include Xen and dom0= (3.19 based kernel) bootargs.

 

+*/

+        c= hosen {

+       &n= bsp;        #address-cells =3D <1>= ;

+       &n= bsp;        #size-cells =3D <1>;

+ 

+       &n= bsp;        xen,xen-bootargs =3D "d= om0_mem=3D128M console=3Ddtuart dtuart=3Dserial0";

+       &n= bsp;        xen,dom0-bootargs =3D "= console=3Dhvc0 earlyprintk root=3D/dev/sda2 rw loglevel=3D7";

+       &n= bsp;        module@0x7000000 {

+       &n= bsp;            = ;    compatible =3D "xen,linux-kernel", "xen,= multiboot-module";

+       &n= bsp;            = ;    reg =3D <0x7000000 0x300000>;

+       &n= bsp;        };

+        }= ;

+

 

I have to make the following changes to the Xen s= rc to get it booted on the board. The changes are basically to enable UART = and GIC. Our GIC is slightly different from ARM GICv3, but I have kept the = changes minimal such that it boots on the board(I am yet to figure out the exact differences with ARM GICv3 s= pec and our implementation and its impact on Xen).

 

diff --git a/xen/arch/arm/Rules.mk b/xen/arch/arm= /Rules.mk

index e27f573..3e3c4ac 100644

--- a/xen/arch/arm/Rules.mk

+++ b/xen/arch/arm/Rules.mk

@@ -49,6 +49,7 @@ EARLY_PRINTK_dra7 &nbs= p;         :=3D 8250,0x4806A000,2

 EARLY_PRINTK_fastmodel   &nb= sp;  :=3D pl011,0x1c090000,115200

 EARLY_PRINTK_exynos5250   &n= bsp; :=3D exynos4210,0x12c20000

 EARLY_PRINTK_hip04-d01   &nb= sp;  :=3D 8250,0xE4007000,2

+EARLY_PRINTK_hip05-d02   &nbs= p;  :=3D 8250,0x80300000,2

 EARLY_PRINTK_juno    &n= bsp;      :=3D pl011,0x7ff80000

 EARLY_PRINTK_lager    &= nbsp;     :=3D scif,0xe6e60000

 EARLY_PRINTK_midway    =      :=3D pl011,0xfff36000

diff --git a/xen/arch/arm/gic-v3.c b/xen/arch/arm= /gic-v3.c

index 30682cf..10028d2 100644

--- a/xen/arch/arm/gic-v3.c

+++ b/xen/arch/arm/gic-v3.c

@@ -54,7 +54,7 @@ static struct {<= /p>

     paddr_t dbase_size;=

     void __iomem *map_dbase;=   /* Mapped address of distributor registers */

     struct rdist_region *rdi= st_regions;

-    uint32_t  rdist_stride;<= o:p>

+    uint64_t  rdist_stri= de;

     unsigned int rdist_count= ; /* Number of rdist regions count */

     unsigned int nr_prioriti= es;

     spinlock_t lock;

@@ -635,7 +635,8 @@ static int __init gicv3_p= opulate_rdist(void)

         = void __iomem *ptr =3D gicv3.rdist_regions[i].map_base;

 

         = reg =3D readl_relaxed(ptr + GICR_PIDR2) & GICR_PIDR2_ARCH_REV_MASK;=

-        if ( = (reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3 )<= /o:p>

+        i= f ( ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_PIDR2_ARCH_GICV3 ) = &&

+       &n= bsp;    ((reg >> GICR_PIDR2_ARCH_REV_SHIFT) !=3D GICR_= PIDR2_ARCH_GICV4))

         = {

        &= nbsp;    dprintk(XENLOG_ERR,

        &= nbsp;            &qu= ot;GICv3: No redistributor present @%"PRIpaddr"\n",

@@ -1221,7 +1222,8 @@ static int __init gicv3= _init(void)

         = panic("GICv3: Failed to ioremap for GIC distributor\n");

 

     reg =3D readl_relaxed(GI= CD + GICD_PIDR2) & GICD_PIDR2_ARCH_REV_MASK;

-    if ( ((reg >> GICD_PIDR= 2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) )

+    if ( ((reg >> GICD_= PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV3) &&

+       &n= bsp; ((reg >> GICD_PIDR2_ARCH_REV_SHIFT) !=3D GICD_PIDR2_ARCH_GICV4) = )

        &= nbsp; panic("GICv3: no distributor detected\n");

 

     if ( !dt_property_read_u= 32(node, "#redistributor-regions",

@@ -1251,7 +1253,7 @@ static int __init gicv3= _init(void)

     /* The vGIC code require= s the region to be sorted */

     sort(rdist_regs, gicv3.r= dist_count, sizeof(*rdist_regs), cmp_rdist, NULL);

 

-    if ( !dt_property_read_u32(no= de, "redistributor-stride", &gicv3.rdist_stride) )=

+    if ( !dt_property_read_u6= 4(node, "redistributor-stride", &gicv3.rdist_stride) )

         = gicv3.rdist_stride =3D 0;

 

     gicv3.rdist_regions=3D r= dist_regs;

@@ -1277,7 +1279,7 @@ static int __init gicv3= _init(void)

        &= nbsp;   "      gic_dist_size=3D%&qu= ot;PRIpaddr"\n"

        &= nbsp;   "      gic_dist_mapaddr=3D%= p\n"

        &= nbsp;   "      gic_rdist_regions=3D= %d\n"

-        =    "      gic_rdist_stride=3D%x\n&q= uot;

+       &n= bsp;   "      gic_rdist_stride=3D%l= x\n"

        &= nbsp;   "      gic_rdist_base=3D%&q= uot;PRIpaddr"\n"

        &= nbsp;   "      gic_rdist_base_size= =3D%"PRIpaddr"\n"

        &= nbsp;   "      gic_rdist_base_mapad= dr=3D%p\n"

diff --git a/xen/include/asm-arm/domain.h b/xen/i= nclude/asm-arm/domain.h

index f1a087e..2df6f85 100644

--- a/xen/include/asm-arm/domain.h

+++ b/xen/include/asm-arm/domain.h

@@ -111,7 +111,7 @@ struct arch_domain

        &= nbsp;    unsigned int first_cpu;    &nbs= p;    /* First CPU handled */

         = } rdist_regions[MAX_RDIST_COUNT];

         = int nr_regions;          =            /* Number of r= dist regions */

-        uint3= 2_t rdist_stride;         &nbs= p;    /* Re-Distributor stride */

+        u= int64_t rdist_stride;         =      /* Re-Distributor stride */

 #endif

     } vgic;

 

diff --git a/xen/include/asm-arm/gic.h b/xen/incl= ude/asm-arm/gic.h

index 9e2acb7..e533583 100644

--- a/xen/include/asm-arm/gic.h

+++ b/xen/include/asm-arm/gic.h<= /o:p>

@@ -160,7 +160,8 @@

     DT_MATCH_COMPATIBLE(&quo= t;arm,cortex-a7-gic"),        =             &nb= sp;  \

     DT_MATCH_COMPATIBLE(&quo= t;arm,gic-400")

 

-#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(&quo= t;arm,gic-v3")

+//#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBL= E("arm,gic-v3")

+#define DT_MATCH_GIC_V3 DT_MATCH_COMPATIBLE(= "hisilicon,gic-v3")

 

 /*

  * GICv3 registers that needs to be saved/r= estored

diff --git a/xen/include/asm-arm/gic_v3_defs.h b/= xen/include/asm-arm/gic_v3_defs.h

index 556f114..ed360a1 100644

--- a/xen/include/asm-arm/gic_v3_defs.h

+++ b/xen/include/asm-arm/gic_v3_defs= .h

@@ -62,10 +62,12 @@

 #define GICD_PIDR2_ARCH_REV_MASK  = ;   (0xf0)

 #define GICD_PIDR2_ARCH_REV_SHIFT &nbs= p;  (0x4)

 #define GICD_PIDR2_ARCH_GICV3  &n= bsp;     (0x3)

+#define GICD_PIDR2_ARCH_GICV4  &nb= sp;     (0x4)

 

 #define GICR_PIDR2_ARCH_REV_MASK  = ;   GICD_PIDR2_ARCH_REV_MASK

 #define GICR_PIDR2_ARCH_REV_SHIFT &nbs= p;  GICD_PIDR2_ARCH_REV_SHIFT

 #define GICR_PIDR2_ARCH_GICV3  &n= bsp;     GICD_PIDR2_ARCH_GICV3

+#define GICR_PIDR2_ARCH_GICV4  &nb= sp;     GICD_PIDR2_ARCH_GICV4

 

 #define GICR_SYNCR_NOT_BUSY  &nbs= p;       1

 /*

 

 

The xen image and dom0 kernel image is written in= to nor flash and UEFI boots Xen instead of a normal linux kernel. The Xen t= hen, loads the dom0 image to memory and tries to boot it.

The problem is in getting the dom0 booted. I can'= t see any prints from dom0. Please find attached log for details.

 

As I said, our GIC is slightly different from ARM= GICv3, but I am not 100% sure the dom0 boot issue is related to GIC or not= . From what I could analyse, dom0 stops very early. The pc points to the __= error_p (arch/arm64/kernel/head.S) symbol as per System.map file. And it looks to be Invalid processor type r= eturn after lookup_processor_type

 

Could you please take a look at the attached logs= and please let me know if you find anything suspicious in what I am doing.=

 

Thanks,

Shameer

 

FDTConfigTable Address: 0x7FBD0000

[LPC] SATA ExitBootServicesEvent

[LPC] GMAC ExitBootServicesEvent

- UART enabled -

- CPU 00020000 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Zero BSS -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) Checking for initrd in /chosen

(XEN) RAM: 0000000000000000 - 000000007fffffff

(XEN)

(XEN) MODULE[0]: 000000000018ad80 - 000000000018d= 29a Device Tree

(XEN) MODULE[1]: 0000000007000000 - 0000000007300= 000 Kernel

(XEN)

(XEN) Command line: dom0_mem=3D128M console=3Ddtu= art dtuart=3Dserial0

(XEN) Placing Xen at 0x000000007fe00000-0x0000000= 080000000

(XEN) Update BOOTMOD_XEN from 0000000000080000-00= 0000000018ad81 =3D> 000000007fe00000-000000007ff0ad81

(XEN) Domain heap initialised

(XEN) Platform: Generic System

(XEN) Looking for dtuart at "serial0", = options ""

 Xen 4.6-unstable

(XEN) Xen version 4.6-unstable (root@) (aarch64-l= inux-gnu-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC 4.9-2014.= 09) 4.9.2 20140904 (prerelease)) debug=3Dy Thu Jul 16 14:31:47 BST 2015

(XEN) Latest ChangeSet: Fri Jun 26 18:24:22 2015 = +0100 git:c40317f-dirty

(XEN) Processor: 411fd071: "ARM Limited"= ;, variant: 0x1, part 0xd07, rev 0x1

(XEN) 64-bit Execution:

(XEN)   Processor Features: 00000000010= 02222 0000000000000000

(XEN)     Exception Levels: E= L3:64+32 EL2:64+32 EL1:64+32 EL0:64+32

(XEN)     Extensions: Floatin= gPoint AdvancedSIMD GICv3-SysReg

(XEN)   Debug Features: 000000001030510= 6 0000000000000000

(XEN)   Auxiliary Features: 00000000000= 00000 0000000000000000

(XEN)   Memory Model Features: 00000000= 00001124 0000000000000000

(XEN)   ISA Features:  00000000000= 11120 0000000000000000

(XEN) 32-bit Execution:

(XEN)   Processor Features: 00000131:10= 011011

(XEN)     Instruction Sets: A= Arch32 A32 Thumb Thumb-2 Jazelle

(XEN)     Extensions: Generic= Timer Security

(XEN)   Debug Features: 03010066

(XEN)   Auxiliary Features: 00000000

(XEN)   Memory Model Features: 10101105= 40000000 01260000 02102211

(XEN)  ISA Features: 02101110 13112111 21232= 042 01112131 00011142 00011121

NOTICE:  [psci_smc_handler]:[239L] PSCI_VERS= ION CALL

NOTICE:  [psci_version]:[76L] PSCI_MAJOR_VER= : 0: PSCI_MINOR_VER: 2

 

00258>04

(XEN) Using PSCI-0.2 for SMP bringup

(XEN) Generic Timer IRQ: phys=3D30 hyp=3D26 virt= =3D27 Freq: 50000 KHz

(XEN) GICv3 initialization:

(XEN)       gic_dis= t_addr=3D000000008d000000

(XEN)       gic_dis= t_size=3D0000000000010000

(XEN)       gic_dis= t_mapaddr=3D000000004001a000

(XEN)       gic_rdi= st_regions=3D1

(XEN)       gic_rdi= st_stride=3D30000

(XEN)       gic_rdi= st_base=3D000000008d100000

(XEN)       gic_rdi= st_base_size=3D0000000000300000

(XEN)       gic_rdi= st_base_mapaddr=3D000000004002b000

(XEN)       gic_mai= ntenance_irq=3D25

(XEN) GICv3: 1024 lines, (IID 0204043b).

(XEN) GICv3: CPU0: Found redistributor in region = 0 @000000004002b000

(XEN) Using scheduler: SMP Credit Scheduler (cred= it)

(XEN) Allocated console ring of 128 KiB.

(XEN) Bringing up CPU1

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 001 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19790

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1b9c0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19790

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020001 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU1: Found redistributor in region = 0 @000000004005b000

(XEN) CPU 1 booted.

(XEN) Bringing up CPU2

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 002 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc199a0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1ba40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc199a0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020002 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU2: Found redistributor in region = 0 @000000004008b000

(XEN) CPU 2 booted.

(XEN) Bringing up CPU3

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 003 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19bb0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x1

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bac0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19bb0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020003 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU3: Found redistributor in region = 0 @00000000400bb000

(XEN) CPU 3 booted.

(XEN) Bringing up CPU4

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 100 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19dc0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x1

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bb40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19dc0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020100 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU4: Found redistributor in region = 0 @00000000400eb000

(XEN) CPU 4 booted.

(XEN) Bringing up CPU5

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 101 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc19fd0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bbc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc19fd0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020101 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU5: Found redistributor in region = 0 @000000004011b000

(XEN) CPU 5 booted.

(XEN) Bringing up CPU6

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 102 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a1e0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bc40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a1e0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020102 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU6: Found redistributor in region = 0 @000000004014b000

(XEN) CPU 6 booted.

(XEN) Bringing up CPU7

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 103 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a3f0

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x3

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bcc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a3f0

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020103 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU7: Found redistributor in region = 0 @000000004017b000

(XEN) CPU 7 booted.

(XEN) Bringing up CPU8

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 200 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a600

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x3

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bd40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a600

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020200 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU8: Found redistributor in region = 0 @00000000401ab000

(XEN) CPU 8 booted.

(XEN) Bringing up CPU9

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 201 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1a810

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bdc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1a810

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020201 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU9: Found redistributor in region = 0 @00000000401db000

(XEN) CPU 9 booted.

(XEN) Bringing up CPU10

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 202 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1aa20

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1be40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1aa20

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020202 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU10: Found redistributor in region= 0 @000000004020b000

(XEN) CPU 10 booted.

(XEN) Bringing up CPU11

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 203 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1ac30

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0x7

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bec0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1ac30

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020203 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU11: Found redistributor in region= 0 @000000004023b000

(XEN) CPU 11 booted.

(XEN) Bringing up CPU12

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 300 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1ae40

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0x7

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bf40

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1ae40

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020300 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU12: Found redistributor in region= 0 @000000004026b000

(XEN) CPU 12 booted.

(XEN) Bringing up CPU13

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 301 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b050

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1bfc0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b050

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020301 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU13: Found redistributor in region= 0 @000000004029b000

(XEN) CPU 13 booted.

(XEN) Bringing up CPU14

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 302 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b260

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1c040

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b260

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020302 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU14: Found redistributor in region= 0 @00000000402cb000

(XEN) CPU 14 booted.

(XEN) Bringing up CPU15

NOTICE:  [psci_smc_handler]:[252L] PSCI_CPU_= ON_AARCH32 CALL

NOTICE:  [psci_smc_handler]:[253L] x1=3D0x20= 303 x2=3D0x7fe00184 x3=3D0x0

NOTICE:  [cm_init_context]:[238L] ctx add = =3D 7fc1b470

NOTICE:  [scpi_set_css_power_state]:[100L] d= omain_cluster=3D0xf

NOTICE:  [scpi_set_css_power_state]:[113L] d= omain_cluster=3D0xf

 

00258A>B04

NOTICE:  [psci_afflvl_power_on_finish]:[496L= ]

NOTICE:  [cm_prepare_el3_exit]:[254L] read_t= pidr_el3 =3D 7fc1c0c0

NOTICE:  [cm_prepare_el3_exit]:[298L] ctx ad= d =3D 7fc1b470

NOTICE:  [psci_afflvl_power_on_finish]:[557L= ]

 

7?>00184

- CPU 00020303 booting -

- Current EL 00000008 -

- Xen starting at EL2 -

- Setting up control registers -

- Turning on paging -

- Ready -

(XEN) GICv3: CPU15: Found redistributor in region= 0 @00000000402fb000

(XEN) CPU 15 booted.

(XEN) Brought up 16 CPUs

(XEN) P2M: 44-bit IPA with 44-bit PA

(XEN) P2M: 4 levels with order-0 root, VTCR 0x800= 43594

(XEN) I/O virtualisation disabled

(XEN) *** LOADING DOMAIN 0 ***

(XEN) Loading kernel from boot module @ 000000000= 7000000

(XEN) Allocating 1:1 mappings totalling 128MB for= dom0:

(XEN) BANK[0] 0x00000008000000-0x00000010000000 (= 128MB)

(XEN) Loading zImage from 0000000007000000 to 000= 0000008080000-0000000008380000

(XEN) Allocating PPI 16 for event channel interru= pt

(XEN) Loading dom0 DTB to 0x000000000fe00000-0x00= 0000000fe01ea5

(XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs=

(XEN) .done.

(XEN) Initial low memory virq threshold set at 0x= 4000 pages.

(XEN) Std. Loglevel: All

(XEN) Guest Loglevel: All

(XEN) *** Serial input -> DOM0 (type 'CTRL-a' = three times to switch input to Xen)

(XEN) Freed 264kB init memory.

(XEN) *** Serial input -> Xen (type 'CTRL-a' t= hree times to switch input to DOM0)

(XEN) 'd' pressed -> dumping registers

(XEN)

(XEN) *** Dumping CPU0 guest state (d0v0): ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    0

(XEN) PC:     000000000808276= 0

(XEN) LR:     000000000808101= c

(XEN) SP_EL0: 0000000000000000

(XEN) SP_EL1: 0000000000000000

(XEN) CPSR:   800001c5 MODE:64-bit EL1h= (Guest Kernel, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000004008000000  X2: ffffffc0000827a8

(XEN)      X3: 000000000= 0000000  X4: 0000000000000000  X5: 0000000000000000

(XEN)      X6: 000000000= 0000000  X7: 0000000000000000  X8: 0000000000000000

(XEN)      X9: 000000000= 0000000 X10: 0000000000000000 X11: 0000000000000000

(XEN)     X12: 00000000000000= 00 X13: 0000000000000016 X14: 0000000000000000

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 0000000000000000 X20: 0000000000000e11

(XEN)     X21: 000000000fe000= 00 X22: 00000000411fd071 X23: 0000000000000000

(XEN)     X24: 00000000080000= 00 X25: 0000000000000000 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000004008000000  FP: 0000000000000000

(XEN)

(XEN)    ELR_EL1: 0000000000000000=

(XEN)    ESR_EL1: 00000000

(XEN)    FAR_EL1: 0000000000000000=

(XEN)

(XEN)  SCTLR_EL1: 00c50838

(XEN)    TCR_EL1: 00000000

(XEN)  TTBR0_EL1: 0000000000000000

(XEN)  TTBR1_EL1: 0000000000000000

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 000100007fdd6000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000008038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Guest stack trace from sp=3D0:

(XEN)   Failed to convert stack to phys= ical address

(XEN)

(XEN) *** Dumping CPU1 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    1

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffdfe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000001  X2: 0000000000304450

(XEN)      X3: 000080007= ff12028  X4: 000080007fc08700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0d8d0  X7: 000080007ff0d8e8  X8: 000080007ff120b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffdfe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffdfe70:=

(XEN)    000080007ffdfe80 00000000= 0024ff54 000000000030ac98 0000000000000001

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000001>= ] 0000000000000001

(XEN)

(XEN) *** Dumping CPU2 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    2

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffcfe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000002  X2: 0000000000304450

(XEN)      X3: 000080007= ff10028  X4: 000080007fc06700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0dbc0  X7: 000080007ff0dbd8  X8: 000080007ff100b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000032

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffcfe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffcfe70:=

(XEN)    000080007ffcfe80 00000000= 0024ff54 000000000030ac98 0000000000000002

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000002>= ] 0000000000000002

(XEN)

(XEN) *** Dumping CPU3 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    3

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffc7e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000003  X2: 0000000000304450

(XEN)      X3: 000080007= ffd4028  X4: 000080007fcca700  X5: 0000000002faf080

(XEN)      X6: 000080007= ff0de20  X7: 000080007ff0de38  X8: 000080007ffd40b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000200

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000200= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffc7e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffc7e70:=

(XEN)    000080007ffc7e80 00000000= 0024ff54 000000000030ac98 0000000000000003

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000003>= ] 0000000000000003

(XEN)

(XEN) *** Dumping CPU4 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    4

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff7fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000004  X2: 0000000000304450

(XEN)      X3: 000080007= ffd2028  X4: 000080007fcc8700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd10a0  X7: 000080007ffd10b8  X8: 000080007ffd20b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000034

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff7fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff7fe70:=

(XEN)    000080007ff7fe80 00000000= 0024ff54 000000000030ac98 0000000000000004

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000004>= ] 0000000000000004

(XEN)

(XEN) *** Dumping CPU5 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    5

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff6fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000005  X2: 0000000000304450

(XEN)      X3: 000080007= ff76028  X4: 000080007fc6c700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1300  X7: 000080007ffd1318  X8: 000080007ff760b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000035

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff6fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff6fe70:=

(XEN)    000080007ff6fe80 00000000= 0024ff54 000000000030ac98 0000000000000005

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000005>= ] 0000000000000005

(XEN)

(XEN) *** Dumping CPU6 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    6

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff67e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000006  X2: 0000000000304450

(XEN)      X3: 000080007= ff72028  X4: 000080007fc68700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1560  X7: 000080007ffd1578  X8: 000080007ff720b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000036

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff67e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff67e70:=

(XEN)    000080007ff67e80 00000000= 0024ff54 000000000030ac98 0000000000000006

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000006>= ] 0000000000000006

(XEN)

(XEN) *** Dumping CPU7 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    7

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff57e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000007  X2: 0000000000304450

(XEN)      X3: 000080007= ff70028  X4: 000080007fc66700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd17c0  X7: 000080007ffd17d8  X8: 000080007ff700b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000037

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000201= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff57e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff57e70:=

(XEN)    000080007ff57e80 00000000= 0024ff54 000000000030ac98 0000000000000007

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000007>= ] 0000000000000007

(XEN)

(XEN) *** Dumping CPU8 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    8

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff4fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000008  X2: 0000000000304450

(XEN)      X3: 000080007= ff5c028  X4: 000080007fc52700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1a20  X7: 000080007ffd1a38  X8: 000080007ff5c0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000038

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff4fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff4fe70:=

(XEN)    000080007ff4fe80 00000000= 0024ff54 000000000030ac98 0000000000000008

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000008>= ] 0000000000000008

(XEN)

(XEN) *** Dumping CPU9 host state: ***=

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    9

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff47e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 0000000000000009  X2: 0000000000304450

(XEN)      X3: 000080007= ff5a028  X4: 000080007fc50700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1c80  X7: 000080007ffd1c98  X8: 000080007ff5a0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000039

(XEN)     X12: 00000000000000= 01 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff47e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff47e70:=

(XEN)    000080007ff47e80 00000000= 0024ff54 000000000030ac98 0000000000000009

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<0000000000000009>= ] 0000000000000009

(XEN)

(XEN) *** Dumping CPU10 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    10

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffb7e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000a  X2: 0000000000304450

(XEN)      X3: 000080007= ffbe028  X4: 000080007fcb4700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffd1ee0  X7: 000080007ffd1ef8  X8: 000080007ffbe0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffb7e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffb7e70:=

(XEN)    000080007ffb7e80 00000000= 0024ff54 000000000030ac98 000000000000000a

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000a>= ] 000000000000000a

(XEN)

(XEN) *** Dumping CPU11 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    11

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ffafe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000b  X2: 0000000000304450

(XEN)      X3: 000080007= ffba028  X4: 000080007fcb0700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd180  X7: 000080007ffbd198  X8: 000080007ffba0b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000202= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ffafe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ffafe70:=

(XEN)    000080007ffafe80 00000000= 0024ff54 000000000030ac98 000000000000000b

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000b>= ] 000000000000000b

(XEN)

(XEN) *** Dumping CPU12 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    12

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff9fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000c  X2: 0000000000304450

(XEN)      X3: 000080007= ffb8028  X4: 000080007fcae700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd3e0  X7: 000080007ffbd3f8  X8: 000080007ffb80b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 00 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff9fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff9fe70:=

(XEN)    000080007ff9fe80 00000000= 0024ff54 000000000030ac98 000000000000000c

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000c>= ] 000000000000000c

(XEN)

(XEN) *** Dumping CPU13 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    13

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff97e7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000d  X2: 0000000000304450

(XEN)      X3: 000080007= ffa4028  X4: 000080007fc9a700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd640  X7: 000080007ffbd658  X8: 000080007ffa40b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 01 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff97e70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff97e70:=

(XEN)    000080007ff97e80 00000000= 0024ff54 000000000030ac98 000000000000000d

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000d>= ] 000000000000000d

(XEN)

(XEN) *** Dumping CPU14 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    14

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007ff8fe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000e  X2: 0000000000304450

(XEN)      X3: 000080007= ffa2028  X4: 000080007fc98700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbd8a0  X7: 000080007ffbd8b8  X8: 000080007ffa20b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 02 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007ff8fe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007ff8fe70:=

(XEN)    000080007ff8fe80 00000000= 0024ff54 000000000030ac98 000000000000000e

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000e>= ] 000000000000000e

(XEN)

(XEN) *** Dumping CPU15 host state: ***

(XEN) ----[ Xen-4.6-unstable  arm64  de= bug=3Dy  Not tainted ]----

(XEN) CPU:    15

(XEN) PC:     00000000002437a= 4 idle_loop+0x12c/0x154

(XEN) LR:     00000000002437a= c

(XEN) SP:     000080007fdffe7= 0

(XEN) CPSR:   20000249 MODE:64-bit EL2h= (Hypervisor, handler)

(XEN)      X0: 000000000= 0000000  X1: 000000000000000f  X2: 0000000000304450

(XEN)      X3: 000080007= ff86028  X4: 000080007fc7c700  X5: 0000000002faf080

(XEN)      X6: 000080007= ffbdb00  X7: 000080007ffbdb18  X8: 000080007ff860b0

(XEN)      X9: 000000000= 0000200 X10: 0000000000000100 X11: 0000000000000031

(XEN)     X12: 00000000000000= 02 X13: 0000000000262e18 X14: 0000000000000020

(XEN)     X15: 00000000000000= 00 X16: 0000000000000000 X17: 0000000000000000

(XEN)     X18: 00000000000000= 00 X19: 000000000030ac98 X20: 00000000002c9300

(XEN)     X21: 000000000030ac= 98 X22: 0000000000309a60 X23: 000000000030ac98

(XEN)     X24: 00000000000203= 03 X25: 0000000000000001 X26: 0000000000000000

(XEN)     X27: 00000000000000= 00 X28: 0000000000000000  FP: 000080007fdffe70

(XEN)

(XEN)   VTCR_EL2: 80043594

(XEN)  VTTBR_EL2: 0000000000000000

(XEN)

(XEN)  SCTLR_EL2: 30cd183d

(XEN)    HCR_EL2: 000000000038643f=

(XEN)  TTBR0_EL2: 000000007fef4000

(XEN)

(XEN)    ESR_EL2: 00000000

(XEN)  HPFAR_EL2: 0000000000000000

(XEN)    FAR_EL2: 0000000000000000=

(XEN)

(XEN) Xen stack trace from sp=3D000080007fdffe70:=

(XEN)    000080007fdffe80 00000000= 0024ff54 000000000030ac98 000000000000000f

(XEN)    0000000000304470 00000000= 00000001 0000000000400000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000 0000000000000000 0000000000000000

(XEN)    0000000000000000 00000000= 00000000

(XEN) Xen call trace:

(XEN)    [<00000000002437a4>= ] idle_loop+0x12c/0x154 (PC)

(XEN)    [<00000000002437ac>= ] idle_loop+0x134/0x154 (LR)

(XEN)    [<000000000024ff54>= ] start_secondary+0x14c/0x15c

(XEN)    [<000000000000000f>= ] 000000000000000f

(XEN)

(XEN) 'q' pressed -> dumping domain info (now= =3D0x8:BFE1C2E8)

(XEN) General information for domain 0:

(XEN)     refcnt=3D3 dying=3D= 0 pause_count=3D0

(XEN)     nr_pages=3D32768 xe= nheap_pages=3D5 shared_pages=3D0 paged_pages=3D0 dirty_cpus=3D{} max_pages= =3D4294967295

(XEN)     handle=3D00000000-0= 000-0000-0000-000000000000 vm_assist=3D00000000

(XEN) p2m mappings for domain 0 (vmid 1):

(XEN)   1G mappings: 0 (shattered 0)

(XEN)   2M mappings: 64 (shattered 0)

(XEN)   4K mappings: 328

(XEN) Rangesets belonging to domain 0:=

(XEN)     Interrupts { 344-34= 5, 348, 350 }

(XEN)     I/O Memory { 80040-= 80041, 802e0-80300, 80310-80340, 8c030-8c040, a0040-a0041, a00e0-a0110, a10= 00-a1020, a3030-a3040, b0000-b0010, b0040-b0041, b0080-b00a0, b00d0-b00f0, = b1000-b1013, b7030-b7040, c0040-c0041, c6030-c6040, 22000000-22000001, 24000000-24000001 }

(XEN) NODE affinity for domain 0: [0]<= /p>

(XEN) VCPU information and callbacks for domain 0= :

(XEN)     VCPU0: CPU0 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D01 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D0

(XEN) GICH_LRs (vcpu 0) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU1: CPU1 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 1) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU2: CPU2 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 2) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU3: CPU3 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 3) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU4: CPU4 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 4) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU5: CPU5 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 5) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU6: CPU6 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 6) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN)     VCPU7: CPU7 [has=3D= F] poll=3D0 upcall_pend=3D00 upcall_mask=3D00 dirty_cpus=3D{}

(XEN)     cpu_hard_affinity= =3D{0-127} cpu_soft_affinity=3D{0-127}

(XEN)     pause_count=3D0 pau= se_flags=3D2

(XEN) GICH_LRs (vcpu 7) mask=3D0

(XEN)    VCPU_LR[0]=3D0=

(XEN)    VCPU_LR[1]=3D0=

(XEN)    VCPU_LR[2]=3D0=

(XEN)    VCPU_LR[3]=3D0=

(XEN)     No periodic timer

(XEN) Notifying guest 0:0 (virq 1, port 0)

(XEN) Notifying guest 0:1 (virq 1, port 0)

(XEN) Notifying guest 0:2 (virq 1, port 0)

(XEN) Notifying guest 0:3 (virq 1, port 0)

(XEN) Notifying guest 0:4 (virq 1, port 0)

(XEN) Notifying guest 0:5 (virq 1, port 0)

(XEN) Notifying guest 0:6 (virq 1, port 0)

(XEN) Notifying guest 0:7 (virq 1, port 0)

 

--_000_5FC3163CFD30C246ABAA99954A238FA82E15E4lhreml504mbs_-- --===============2095908660014434974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2095908660014434974==-- From xen-users-bounces@lists.xen.org Thu Jul 16 16:12:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 16:12:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFllO-0000kS-Hf; Thu, 16 Jul 2015 16:11:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFllN-0000k7-GH for xen-users@lists.xen.org; Thu, 16 Jul 2015 16:11:57 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 7F/D9-32733-CC7D7A55; Thu, 16 Jul 2015 16:11:56 +0000 X-Env-Sender: prvs=63240c440=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1437063114!32720242!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32224 invoked from network); 16 Jul 2015 16:11:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 16:11:56 -0000 X-IronPort-AV: E=Sophos;i="5.15,488,1432598400"; d="scan'208";a="284784669" Message-ID: <1437063111.32371.247.camel@citrix.com> From: Ian Campbell To: Shameerali Kolothum Thodi Date: Thu, 16 Jul 2015 17:11:51 +0100 In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote: Please can you post mails in plain text not HTML, thanks. Also, I think this is probably more of a xen-devel question that a xen-users one, since you are actually changing code... > + module@0x7000000 { > > + compatible = "xen,linux-kernel", "xen,multiboot-module"; > > + reg = <0x7000000 0x300000>; Is this the physical address of the Flash device where the kernel is burnt? > I have to make the following changes to the Xen src to get it booted > on the board. The changes are basically to enable UART and GIC. Our > GIC is slightly different from ARM GICv3, but I have kept the changes > minimal such that it boots on the board(I am yet to figure out the > exact differences with ARM GICv3 spec and our implementation and its > impact on Xen). [...] > The xen image and dom0 kernel image is written into nor flash and UEFI > boots Xen instead of a normal linux kernel. The Xen then, loads the > dom0 image to memory and tries to boot it. Normally for a UEFI system all these things would be expected to be found in the ESP along with a xen.cfg describing what to load as per http://xenbits.xen.org/docs/unstable/misc/efi.html However, updating the FDT to point to some artefacts in the physical address space ought to work, that's how we normally do things on u-boot systems albeit the things are in RAM not NOR flash. > The problem is in getting the dom0 booted. I can't see any prints from > dom0. Please find attached log for details. > > > > As I said, our GIC is slightly different from ARM GICv3, Is it actually a GICv4 as the code changes suggest? > but I am not 100% sure the dom0 boot issue is related to GIC or not. > From what I could analyse, dom0 stops very early. The pc points to the > __error_p (arch/arm64/kernel/head.S) symbol as per System.map file. > And it looks to be Invalid processor type return after > lookup_processor_type Did you enable the option for your processor type in your kernel .config? Also, do you have all the Xen options enabled? It could be a cache issue, i..e that code isn't seeing the correct processor type table, but we are pretty careful to clean+invalidate the kernel image as we load it into RAM. It's possible that NOR vs RAM is having an effect here, since we use a BUFFERABLE mapping for the source when copying the kernel. i.e. maybe we are not actually copying the full image correctly. If you can't arrange for the kernel to be in RAM you could try fiddling with copy_from_paddr to use a DEVICE mapping instead? With a debug build of Xen you could use the debug hvc's to add some tracing to your dom0 kernel, see xen/arch/arm/traps.c:do_debug_trap(), but in short hvc #0xff?? can be used to drop hints at various points in the boot. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 16 16:12:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 16 Jul 2015 16:12:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFllO-0000kS-Hf; Thu, 16 Jul 2015 16:11:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZFllN-0000k7-GH for xen-users@lists.xen.org; Thu, 16 Jul 2015 16:11:57 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id 7F/D9-32733-CC7D7A55; Thu, 16 Jul 2015 16:11:56 +0000 X-Env-Sender: prvs=63240c440=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-27.messagelabs.com!1437063114!32720242!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32224 invoked from network); 16 Jul 2015 16:11:56 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-9.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 16 Jul 2015 16:11:56 -0000 X-IronPort-AV: E=Sophos;i="5.15,488,1432598400"; d="scan'208";a="284784669" Message-ID: <1437063111.32371.247.camel@citrix.com> From: Ian Campbell To: Shameerali Kolothum Thodi Date: Thu, 16 Jul 2015 17:11:51 +0100 In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote: Please can you post mails in plain text not HTML, thanks. Also, I think this is probably more of a xen-devel question that a xen-users one, since you are actually changing code... > + module@0x7000000 { > > + compatible = "xen,linux-kernel", "xen,multiboot-module"; > > + reg = <0x7000000 0x300000>; Is this the physical address of the Flash device where the kernel is burnt? > I have to make the following changes to the Xen src to get it booted > on the board. The changes are basically to enable UART and GIC. Our > GIC is slightly different from ARM GICv3, but I have kept the changes > minimal such that it boots on the board(I am yet to figure out the > exact differences with ARM GICv3 spec and our implementation and its > impact on Xen). [...] > The xen image and dom0 kernel image is written into nor flash and UEFI > boots Xen instead of a normal linux kernel. The Xen then, loads the > dom0 image to memory and tries to boot it. Normally for a UEFI system all these things would be expected to be found in the ESP along with a xen.cfg describing what to load as per http://xenbits.xen.org/docs/unstable/misc/efi.html However, updating the FDT to point to some artefacts in the physical address space ought to work, that's how we normally do things on u-boot systems albeit the things are in RAM not NOR flash. > The problem is in getting the dom0 booted. I can't see any prints from > dom0. Please find attached log for details. > > > > As I said, our GIC is slightly different from ARM GICv3, Is it actually a GICv4 as the code changes suggest? > but I am not 100% sure the dom0 boot issue is related to GIC or not. > From what I could analyse, dom0 stops very early. The pc points to the > __error_p (arch/arm64/kernel/head.S) symbol as per System.map file. > And it looks to be Invalid processor type return after > lookup_processor_type Did you enable the option for your processor type in your kernel .config? Also, do you have all the Xen options enabled? It could be a cache issue, i..e that code isn't seeing the correct processor type table, but we are pretty careful to clean+invalidate the kernel image as we load it into RAM. It's possible that NOR vs RAM is having an effect here, since we use a BUFFERABLE mapping for the source when copying the kernel. i.e. maybe we are not actually copying the full image correctly. If you can't arrange for the kernel to be in RAM you could try fiddling with copy_from_paddr to use a DEVICE mapping instead? With a debug build of Xen you could use the debug hvc's to add some tracing to your dom0 kernel, see xen/arch/arm/traps.c:do_debug_trap(), but in short hvc #0xff?? can be used to drop hints at various points in the boot. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 09:40:17 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 09:40:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG26d-00078I-Ia; Fri, 17 Jul 2015 09:38:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG26c-000789-Q2 for xen-users@lists.xen.org; Fri, 17 Jul 2015 09:38:59 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 76/D4-06457-23DC8A55; Fri, 17 Jul 2015 09:38:58 +0000 X-Env-Sender: shameerali.kolothum.thodi@huawei.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437125937!25473476!1 X-Originating-IP: [194.213.3.17] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2438 invoked from network); 17 Jul 2015 09:38:57 -0000 Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 09:38:57 -0000 Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH37033; Fri, 17 Jul 2015 09:38:52 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 17 Jul 2015 10:38:43 +0100 From: Shameerali Kolothum Thodi To: Ian Campbell Thread-Topic: [Xen-users] Enabling Xen on HiSilicon HIP05 board Thread-Index: AdC/251i+NuBdUzGQjeNno2OKWRg/P///EGA//7PNpA= Date: Fri, 17 Jul 2015 09:38:43 +0000 Message-ID: <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> <1437063111.32371.247.camel@citrix.com> In-Reply-To: <1437063111.32371.247.camel@citrix.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.137.235] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org > -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users- > bounces@lists.xen.org] On Behalf Of Ian Campbell > Sent: 16 July 2015 17:12 > To: Shameerali Kolothum Thodi > Cc: Julien Grall; xen-users@lists.xen.org; Zoltan Kiss > Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board > > On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote: > > Please can you post mails in plain text not HTML, thanks. My apologies. (Though I remember selecting the right option, I have to be more careful!). > > Also, I think this is probably more of a xen-devel question that a xen- > users one, since you are actually changing code... > > > + module@0x7000000 { > > > > + compatible = "xen,linux-kernel", > > + "xen,multiboot-module"; > > > > + reg = <0x7000000 0x300000>; > > Is this the physical address of the Flash device where the kernel is > burnt? Yes. > > > I have to make the following changes to the Xen src to get it booted > > on the board. The changes are basically to enable UART and GIC. Our > > GIC is slightly different from ARM GICv3, but I have kept the changes > > minimal such that it boots on the board(I am yet to figure out the > > exact differences with ARM GICv3 spec and our implementation and its > > impact on Xen). > > [...] > > > The xen image and dom0 kernel image is written into nor flash and > UEFI > > boots Xen instead of a normal linux kernel. The Xen then, loads the > > dom0 image to memory and tries to boot it. > > Normally for a UEFI system all these things would be expected to be > found in the ESP along with a xen.cfg describing what to load as per > http://xenbits.xen.org/docs/unstable/misc/efi.html > > However, updating the FDT to point to some artefacts in the physical > address space ought to work, that's how we normally do things on u-boot > systems albeit the things are in RAM not NOR flash. > Ok. We used the same strategy for our hip04 board. I will consider this. > > The problem is in getting the dom0 booted. I can't see any prints > from > > dom0. Please find attached log for details. > > > > > > > > As I said, our GIC is slightly different from ARM GICv3, > > Is it actually a GICv4 as the code changes suggest? It is, as per the register return. I will confirm it with our SoC guys. > > > but I am not 100% sure the dom0 boot issue is related to GIC or not. > > From what I could analyse, dom0 stops very early. The pc points to > the > > __error_p (arch/arm64/kernel/head.S) symbol as per System.map file. > > And it looks to be Invalid processor type return after > > lookup_processor_type > > Did you enable the option for your processor type in your kernel > .config? > > Also, do you have all the Xen options enabled? Yes, I will double check though. > It could be a cache issue, i..e that code isn't seeing the correct > processor type table, but we are pretty careful to clean+invalidate the > kernel image as we load it into RAM. > > It's possible that NOR vs RAM is having an effect here, since we use a > BUFFERABLE mapping for the source when copying the kernel. i.e. maybe > we are not actually copying the full image correctly. > > If you can't arrange for the kernel to be in RAM you could try fiddling > with copy_from_paddr to use a DEVICE mapping instead? > > With a debug build of Xen you could use the debug hvc's to add some > tracing to your dom0 kernel, see xen/arch/arm/traps.c:do_debug_trap(), > but in short hvc #0xff?? can be used to drop hints at various points in > the boot. > > Ian. Many thanks for your suggestions. It indeed helped me to think in the right direction. The issue was, I set a wrong size in dts and Image was not fully copied. I was able to go forward with the right size in dts , but now hit by another one. I will use the do_debug_trap() method suggested by you to debug further. Also please find attached the latest crash dump I am seeing. Please let me know if this gives you any hints. (XEN) CPU 15 booted. (XEN) Brought up 16 CPUs (XEN) P2M: 44-bit IPA with 44-bit PA (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 0000000007000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) (XEN) Loading zImage from 0000000007000000 to 0000000008080000-0000000008980000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs (XEN) .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 264kB init memory. (XEN) d0v0: vGICD: RAZ on reserved register offset 0x00000c (XEN) d0v0: vGICR: write r2 offset 0x000180 (XEN) not found<3>traps.c:2417:d0v0 HSR=0x93820046 pc=0xffffffc000322bfc gva=0xffffff8000090180 gpa=0x0000008d110180 (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 guest state (d0v0): *** (XEN) ----[ Xen-4.6-unstable arm64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) PC: ffffffc0002ff830 (XEN) LR: ffffffc0002ff868 (XEN) SP_EL0: 0000000000000000 (XEN) SP_EL1: ffffffc00087fa80 (XEN) CPSR: 80000145 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000199 X1: 000000000000000c X2: 000000007ddbf62d (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000006 (XEN) X6: ffffffc0008eaa74 X7: 696b206f74206465 X8: 0000000000000064 (XEN) X9: 0000000000000000 X10: ffffffc0008ea000 X11: ffffffc00089a000 (XEN) X12: 0101010101010101 X13: 0000000000000000 X14: 0ffffffffffffffd (XEN) X15: 0000000000000007 X16: 0000000000000001 X17: 000000000000000e (XEN) X18: 0000000000000007 X19: 0000000000000031 X20: 00000000004da5bc (XEN) X21: 00000000004da620 X22: ffffffc0008e7000 X23: 0000000000000000 (XEN) X24: ffffffc00088f4b0 X25: 0000000000000000 X26: 0000000000000000 (XEN) X27: ffffffc000901c88 X28: ffffffc001801700 FP: ffffffc00087fa80 (XEN) (XEN) ELR_EL1: ffffffc000322bfc (XEN) ESR_EL1: 96000000 (XEN) FAR_EL1: ffffff8000090180 (XEN) (XEN) SCTLR_EL1: 04c5d91d (XEN) TCR_EL1: 34b5193519 (XEN) TTBR0_EL1: 000000000ffff000 (XEN) TTBR1_EL1: 000000000891e000 (XEN) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 09:40:17 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 09:40:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG26d-00078I-Ia; Fri, 17 Jul 2015 09:38:59 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG26c-000789-Q2 for xen-users@lists.xen.org; Fri, 17 Jul 2015 09:38:59 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 76/D4-06457-23DC8A55; Fri, 17 Jul 2015 09:38:58 +0000 X-Env-Sender: shameerali.kolothum.thodi@huawei.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437125937!25473476!1 X-Originating-IP: [194.213.3.17] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk0LjIxMy4zLjE3ID0+IDk5NzAw\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2438 invoked from network); 17 Jul 2015 09:38:57 -0000 Received: from lhrrgout.huawei.com (HELO lhrrgout.huawei.com) (194.213.3.17) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 09:38:57 -0000 Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BVH37033; Fri, 17 Jul 2015 09:38:52 +0000 (GMT) Received: from LHREML504-MBS.china.huawei.com ([10.125.30.107]) by lhreml401-hub.china.huawei.com ([10.201.5.240]) with mapi id 14.03.0158.001; Fri, 17 Jul 2015 10:38:43 +0100 From: Shameerali Kolothum Thodi To: Ian Campbell Thread-Topic: [Xen-users] Enabling Xen on HiSilicon HIP05 board Thread-Index: AdC/251i+NuBdUzGQjeNno2OKWRg/P///EGA//7PNpA= Date: Fri, 17 Jul 2015 09:38:43 +0000 Message-ID: <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> <1437063111.32371.247.camel@citrix.com> In-Reply-To: <1437063111.32371.247.camel@citrix.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.202.137.235] MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org > -----Original Message----- > From: xen-users-bounces@lists.xen.org [mailto:xen-users- > bounces@lists.xen.org] On Behalf Of Ian Campbell > Sent: 16 July 2015 17:12 > To: Shameerali Kolothum Thodi > Cc: Julien Grall; xen-users@lists.xen.org; Zoltan Kiss > Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board > > On Thu, 2015-07-16 at 15:25 +0000, Shameerali Kolothum Thodi wrote: > > Please can you post mails in plain text not HTML, thanks. My apologies. (Though I remember selecting the right option, I have to be more careful!). > > Also, I think this is probably more of a xen-devel question that a xen- > users one, since you are actually changing code... > > > + module@0x7000000 { > > > > + compatible = "xen,linux-kernel", > > + "xen,multiboot-module"; > > > > + reg = <0x7000000 0x300000>; > > Is this the physical address of the Flash device where the kernel is > burnt? Yes. > > > I have to make the following changes to the Xen src to get it booted > > on the board. The changes are basically to enable UART and GIC. Our > > GIC is slightly different from ARM GICv3, but I have kept the changes > > minimal such that it boots on the board(I am yet to figure out the > > exact differences with ARM GICv3 spec and our implementation and its > > impact on Xen). > > [...] > > > The xen image and dom0 kernel image is written into nor flash and > UEFI > > boots Xen instead of a normal linux kernel. The Xen then, loads the > > dom0 image to memory and tries to boot it. > > Normally for a UEFI system all these things would be expected to be > found in the ESP along with a xen.cfg describing what to load as per > http://xenbits.xen.org/docs/unstable/misc/efi.html > > However, updating the FDT to point to some artefacts in the physical > address space ought to work, that's how we normally do things on u-boot > systems albeit the things are in RAM not NOR flash. > Ok. We used the same strategy for our hip04 board. I will consider this. > > The problem is in getting the dom0 booted. I can't see any prints > from > > dom0. Please find attached log for details. > > > > > > > > As I said, our GIC is slightly different from ARM GICv3, > > Is it actually a GICv4 as the code changes suggest? It is, as per the register return. I will confirm it with our SoC guys. > > > but I am not 100% sure the dom0 boot issue is related to GIC or not. > > From what I could analyse, dom0 stops very early. The pc points to > the > > __error_p (arch/arm64/kernel/head.S) symbol as per System.map file. > > And it looks to be Invalid processor type return after > > lookup_processor_type > > Did you enable the option for your processor type in your kernel > .config? > > Also, do you have all the Xen options enabled? Yes, I will double check though. > It could be a cache issue, i..e that code isn't seeing the correct > processor type table, but we are pretty careful to clean+invalidate the > kernel image as we load it into RAM. > > It's possible that NOR vs RAM is having an effect here, since we use a > BUFFERABLE mapping for the source when copying the kernel. i.e. maybe > we are not actually copying the full image correctly. > > If you can't arrange for the kernel to be in RAM you could try fiddling > with copy_from_paddr to use a DEVICE mapping instead? > > With a debug build of Xen you could use the debug hvc's to add some > tracing to your dom0 kernel, see xen/arch/arm/traps.c:do_debug_trap(), > but in short hvc #0xff?? can be used to drop hints at various points in > the boot. > > Ian. Many thanks for your suggestions. It indeed helped me to think in the right direction. The issue was, I set a wrong size in dts and Image was not fully copied. I was able to go forward with the right size in dts , but now hit by another one. I will use the do_debug_trap() method suggested by you to debug further. Also please find attached the latest crash dump I am seeing. Please let me know if this gives you any hints. (XEN) CPU 15 booted. (XEN) Brought up 16 CPUs (XEN) P2M: 44-bit IPA with 44-bit PA (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 0000000007000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) (XEN) Loading zImage from 0000000007000000 to 0000000008080000-0000000008980000 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs (XEN) .done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 264kB init memory. (XEN) d0v0: vGICD: RAZ on reserved register offset 0x00000c (XEN) d0v0: vGICR: write r2 offset 0x000180 (XEN) not found<3>traps.c:2417:d0v0 HSR=0x93820046 pc=0xffffffc000322bfc gva=0xffffff8000090180 gpa=0x0000008d110180 (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) (XEN) 'd' pressed -> dumping registers (XEN) (XEN) *** Dumping CPU0 guest state (d0v0): *** (XEN) ----[ Xen-4.6-unstable arm64 debug=y Not tainted ]---- (XEN) CPU: 0 (XEN) PC: ffffffc0002ff830 (XEN) LR: ffffffc0002ff868 (XEN) SP_EL0: 0000000000000000 (XEN) SP_EL1: ffffffc00087fa80 (XEN) CPSR: 80000145 MODE:64-bit EL1h (Guest Kernel, handler) (XEN) X0: 0000000000000199 X1: 000000000000000c X2: 000000007ddbf62d (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000006 (XEN) X6: ffffffc0008eaa74 X7: 696b206f74206465 X8: 0000000000000064 (XEN) X9: 0000000000000000 X10: ffffffc0008ea000 X11: ffffffc00089a000 (XEN) X12: 0101010101010101 X13: 0000000000000000 X14: 0ffffffffffffffd (XEN) X15: 0000000000000007 X16: 0000000000000001 X17: 000000000000000e (XEN) X18: 0000000000000007 X19: 0000000000000031 X20: 00000000004da5bc (XEN) X21: 00000000004da620 X22: ffffffc0008e7000 X23: 0000000000000000 (XEN) X24: ffffffc00088f4b0 X25: 0000000000000000 X26: 0000000000000000 (XEN) X27: ffffffc000901c88 X28: ffffffc001801700 FP: ffffffc00087fa80 (XEN) (XEN) ELR_EL1: ffffffc000322bfc (XEN) ESR_EL1: 96000000 (XEN) FAR_EL1: ffffff8000090180 (XEN) (XEN) SCTLR_EL1: 04c5d91d (XEN) TCR_EL1: 34b5193519 (XEN) TTBR0_EL1: 000000000ffff000 (XEN) TTBR1_EL1: 000000000891e000 (XEN) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 12:58:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 12:58:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG5D2-0002xe-Lw; Fri, 17 Jul 2015 12:57:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG5D1-0002xT-Dn for xen-users@lists.xen.org; Fri, 17 Jul 2015 12:57:47 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 61/73-11060-ACBF8A55; Fri, 17 Jul 2015 12:57:46 +0000 X-Env-Sender: prvs=633027daa=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1437137864!26793823!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2679 invoked from network); 17 Jul 2015 12:57:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 12:57:45 -0000 X-IronPort-AV: E=Sophos;i="5.15,496,1432598400"; d="scan'208";a="285090929" Message-ID: <1437137028.32371.329.camel@citrix.com> From: Ian Campbell To: Shameerali Kolothum Thodi Date: Fri, 17 Jul 2015 13:43:48 +0100 In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> <1437063111.32371.247.camel@citrix.com> <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 09:38 +0000, Shameerali Kolothum Thodi wrote: > Also please find attached the latest crash dump I am seeing. Please let me know if this gives you any hints. It's not one I've seen before I'm afraid. > (XEN) CPU 15 booted. > (XEN) Brought up 16 CPUs > (XEN) P2M: 44-bit IPA with 44-bit PA > (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 > (XEN) I/O virtualisation disabled > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 0000000007000000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) > (XEN) Loading zImage from 0000000007000000 to 0000000008080000-0000000008980000 > (XEN) Allocating PPI 16 for event channel interrupt > (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 > (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs > (XEN) .done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) > (XEN) Freed 264kB init memory. > (XEN) d0v0: vGICD: RAZ on reserved register offset 0x00000c > (XEN) d0v0: vGICR: write r2 offset 0x000180 > (XEN) not found These two seem to come from xen/arch/arm/vgic-v3.c Neither GICD+0xc nor GICR+0x180 seem to be registers defined in my version of the spec. This all might plausibly be related to the use of a v4 rather than v3 gic? > <3> These are because the formatting of the previous message is a bit mad. > traps.c:2417:d0v0 HSR=0x93820046 pc=0xffffffc000322bfc gva=0xffffff8000090180 gpa=0x0000008d110180 This trap will correspond to the unhandled write to vGICR+0x180, being injected back to the guest as a trap since we didn't know what else to do with it. > (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) > (XEN) 'd' pressed -> dumping registers > (XEN) > (XEN) *** Dumping CPU0 guest state (d0v0): *** > (XEN) ----[ Xen-4.6-unstable arm64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) PC: ffffffc0002ff830 > (XEN) LR: ffffffc0002ff868 > (XEN) SP_EL0: 0000000000000000 > (XEN) SP_EL1: ffffffc00087fa80 > (XEN) CPSR: 80000145 MODE:64-bit EL1h (Guest Kernel, handler) > (XEN) X0: 0000000000000199 X1: 000000000000000c X2: 000000007ddbf62d > (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000006 > (XEN) X6: ffffffc0008eaa74 X7: 696b206f74206465 X8: 0000000000000064 > (XEN) X9: 0000000000000000 X10: ffffffc0008ea000 X11: ffffffc00089a000 > (XEN) X12: 0101010101010101 X13: 0000000000000000 X14: 0ffffffffffffffd > (XEN) X15: 0000000000000007 X16: 0000000000000001 X17: 000000000000000e > (XEN) X18: 0000000000000007 X19: 0000000000000031 X20: 00000000004da5bc > (XEN) X21: 00000000004da620 X22: ffffffc0008e7000 X23: 0000000000000000 > (XEN) X24: ffffffc00088f4b0 X25: 0000000000000000 X26: 0000000000000000 > (XEN) X27: ffffffc000901c88 X28: ffffffc001801700 FP: ffffffc00087fa80 > (XEN) > (XEN) ELR_EL1: ffffffc000322bfc > (XEN) ESR_EL1: 96000000 > (XEN) FAR_EL1: ffffff8000090180 > (XEN) > (XEN) SCTLR_EL1: 04c5d91d > (XEN) TCR_EL1: 34b5193519 > (XEN) TTBR0_EL1: 000000000ffff000 > (XEN) TTBR1_EL1: 000000000891e000 > (XEN) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 12:58:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 12:58:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG5D2-0002xe-Lw; Fri, 17 Jul 2015 12:57:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZG5D1-0002xT-Dn for xen-users@lists.xen.org; Fri, 17 Jul 2015 12:57:47 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 61/73-11060-ACBF8A55; Fri, 17 Jul 2015 12:57:46 +0000 X-Env-Sender: prvs=633027daa=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1437137864!26793823!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2679 invoked from network); 17 Jul 2015 12:57:45 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 12:57:45 -0000 X-IronPort-AV: E=Sophos;i="5.15,496,1432598400"; d="scan'208";a="285090929" Message-ID: <1437137028.32371.329.camel@citrix.com> From: Ian Campbell To: Shameerali Kolothum Thodi Date: Fri, 17 Jul 2015 13:43:48 +0100 In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> References: <5FC3163CFD30C246ABAA99954A238FA82E15E4@lhreml504-mbs> <1437063111.32371.247.camel@citrix.com> <5FC3163CFD30C246ABAA99954A238FA82E1BE6@lhreml504-mbs> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Julien Grall , "xen-users@lists.xen.org" , Zoltan Kiss Subject: Re: [Xen-users] Enabling Xen on HiSilicon HIP05 board X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 09:38 +0000, Shameerali Kolothum Thodi wrote: > Also please find attached the latest crash dump I am seeing. Please let me know if this gives you any hints. It's not one I've seen before I'm afraid. > (XEN) CPU 15 booted. > (XEN) Brought up 16 CPUs > (XEN) P2M: 44-bit IPA with 44-bit PA > (XEN) P2M: 4 levels with order-0 root, VTCR 0x80043594 > (XEN) I/O virtualisation disabled > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 0000000007000000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x00000008000000-0x00000010000000 (128MB) > (XEN) Loading zImage from 0000000007000000 to 0000000008080000-0000000008980000 > (XEN) Allocating PPI 16 for event channel interrupt > (XEN) Loading dom0 DTB to 0x000000000fe00000-0x000000000fe01ea5 > (XEN) Scrubbing Free RAM on 1 nodes using 16 CPUs > (XEN) .done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) > (XEN) Freed 264kB init memory. > (XEN) d0v0: vGICD: RAZ on reserved register offset 0x00000c > (XEN) d0v0: vGICR: write r2 offset 0x000180 > (XEN) not found These two seem to come from xen/arch/arm/vgic-v3.c Neither GICD+0xc nor GICR+0x180 seem to be registers defined in my version of the spec. This all might plausibly be related to the use of a v4 rather than v3 gic? > <3> These are because the formatting of the previous message is a bit mad. > traps.c:2417:d0v0 HSR=0x93820046 pc=0xffffffc000322bfc gva=0xffffff8000090180 gpa=0x0000008d110180 This trap will correspond to the unhandled write to vGICR+0x180, being injected back to the guest as a trap since we didn't know what else to do with it. > (XEN) *** Serial input -> Xen (type 'CTRL-a' three times to switch input to DOM0) > (XEN) 'd' pressed -> dumping registers > (XEN) > (XEN) *** Dumping CPU0 guest state (d0v0): *** > (XEN) ----[ Xen-4.6-unstable arm64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) PC: ffffffc0002ff830 > (XEN) LR: ffffffc0002ff868 > (XEN) SP_EL0: 0000000000000000 > (XEN) SP_EL1: ffffffc00087fa80 > (XEN) CPSR: 80000145 MODE:64-bit EL1h (Guest Kernel, handler) > (XEN) X0: 0000000000000199 X1: 000000000000000c X2: 000000007ddbf62d > (XEN) X3: 0000000000000000 X4: 0000000000000000 X5: 0000000000000006 > (XEN) X6: ffffffc0008eaa74 X7: 696b206f74206465 X8: 0000000000000064 > (XEN) X9: 0000000000000000 X10: ffffffc0008ea000 X11: ffffffc00089a000 > (XEN) X12: 0101010101010101 X13: 0000000000000000 X14: 0ffffffffffffffd > (XEN) X15: 0000000000000007 X16: 0000000000000001 X17: 000000000000000e > (XEN) X18: 0000000000000007 X19: 0000000000000031 X20: 00000000004da5bc > (XEN) X21: 00000000004da620 X22: ffffffc0008e7000 X23: 0000000000000000 > (XEN) X24: ffffffc00088f4b0 X25: 0000000000000000 X26: 0000000000000000 > (XEN) X27: ffffffc000901c88 X28: ffffffc001801700 FP: ffffffc00087fa80 > (XEN) > (XEN) ELR_EL1: ffffffc000322bfc > (XEN) ESR_EL1: 96000000 > (XEN) FAR_EL1: ffffff8000090180 > (XEN) > (XEN) SCTLR_EL1: 04c5d91d > (XEN) TCR_EL1: 34b5193519 > (XEN) TTBR0_EL1: 000000000ffff000 > (XEN) TTBR1_EL1: 000000000891e000 > (XEN) _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 21:00:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 21:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGCjG-0000t4-J4; Fri, 17 Jul 2015 20:59:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGCjE-0000sv-QB for xen-users@lists.xen.org; Fri, 17 Jul 2015 20:59:33 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 8A/06-30151-4BC69A55; Fri, 17 Jul 2015 20:59:32 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1437166769!33117875!1 X-Originating-IP: [209.85.217.182] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28334 invoked from network); 17 Jul 2015 20:59:29 -0000 Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com) (209.85.217.182) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 20:59:29 -0000 Received: by lbbyj8 with SMTP id yj8so67563883lbb.0 for ; Fri, 17 Jul 2015 13:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z6Kan+jS/4hV8zVpiDg3MZ7ZZrc1RufGgmb4s4OhtQE=; b=rLn7N3apeYMZbV+2cvGlIxNB5l2iFTRIk8h8J/7XyTW8QQflrpT6gGG3FY+uqL8ij5 hMpJ+mP5TDJiOxdUIzjwC31JPc96RUkI4yRSBFzttt4vEqh9a2dViLuGlwLlqFgaU4fv 3dfXUXTW3JDlWOw41T01qfGI3sDEuzys6VrWVSAMJtFI9HD/CtFXcvrweOzdfhsMcuDF jJA7dVdCuuSQBOx1Ucfl9yTKsCr0sAEK6ya86oc3bPappJXU0PobOsMGFoWEt5UwoC7I Hkepk6a+nOkMmOMMUDAa/SXO7M/g4Z6CCL+9UHIKRP8WBw9OazXukiN+FXcGK1AvQSCk vPjA== X-Received: by 10.112.171.68 with SMTP id as4mr16200055lbc.64.1437166768984; Fri, 17 Jul 2015 13:59:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Fri, 17 Jul 2015 13:59:09 -0700 (PDT) In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Fri, 17 Jul 2015 16:59:09 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I've made some progress by rolling back to an earlier firmware and kernel version. It looks like I'm now able to fully boot Xen along with all 6 cores and Dom0 starts booting. Now, on waiting for the root device to become available, USB enumeration fails. Since Juno relies on USB for the root disk, this prevents booting. I've confirmed that the same kernel boots fine outside of Xen. The boot messages in question are, with the full boot log below: [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb [ 1.659215] usb 1-1: device descriptor read/64, error -32 [ 1.889213] usb 1-1: device descriptor read/64, error -32 [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb [ 2.239213] usb 1-1: device descriptor read/64, error -32 [ 2.469249] usb 1-1: device descriptor read/64, error -32 [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb [ 3.119197] usb 1-1: device not accepting address 4, error -32 [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb [ 3.659181] usb 1-1: device not accepting address 5, error -32 [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 So I have a couple of questions. Has anyone run into this USB issue before? If not, can someone point me to the firmware/kernel versions that were known to successfully boot Xen on the Juno board? ARM V2M-Juno Boot loader v1.0.0 HBI0262 build 1156 ARM V2M_Juno Firmware v1.2.7 Build Date: Oct 3 2014 Time : 17:23:54 Date : 17:07:2015 Cmd> Powering up system... Switching on ATXPSU... PMIC RAM configuration (pms_v103.bin)... MBtemp : 37 degC Configuring motherboard (rev B, var B)... IOFPGA image \MB\HBI0262B\io_b115.bit IOFPGA config: PASSED OSC CLK config: PASSED Configuring SCC registers... Writing SCC 0x00000054 with 0x0007FFFE Writing SCC 0x0000005C with 0x00FE001E Writing SCC 0x00000100 with 0x003F1000 Writing SCC 0x00000104 with 0x0001F300 Writing SCC 0x00000108 with 0x00371000 Writing SCC 0x0000010C with 0x0001B300 Writing SCC 0x00000118 with 0x003F1000 Writing SCC 0x0000011C with 0x0001F100 Writing SCC 0x000000F8 with 0x0BEC0000 Writing SCC 0x0000000C with 0x000000C2 Writing SCC 0x00000010 with 0x000000C2 Peripheral ID0:0x000000AD Peripheral ID1:0x000000B0 Peripheral ID2:0x0000000B Peripheral ID3:0x00000000 Peripheral ID4:0x0000000D Peripheral ID5:0x000000F0 Peripheral ID6:0x00000005 Peripheral ID7:0x000000B1 Programming NOR Flash PCIE clock configured... Testing motherboard interfaces (FPGA build 115)... SRAM 32MB test: PASSED LAN9118 test: PASSED KMI1/2 test: PASSED MMC test: PASSED PB/LEDs test: PASSED FPGA UART test: PASSED PCIe init test: PASSED MAC addrs test: PASSED Setting HDMI0 mode for SVGA. Setting HDMI1 mode for SVGA. SoC SMB clock enabled. Testing SMB clock... SMB clock running Releasing system resets... UART0 set to SoC UART0 UART1 set to SoC UART1 NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.0(release):14b6608 NOTICE: BL1: Built : 14:15:51, Sep 1 2014 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.0(release):14b6608 NOTICE: BL2: Built : 14:15:51, Sep 1 2014 NOTICE: BL1: Booting BL3-1 NOTICE: BL3-1: v1.0(release):14b6608 NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014 UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014) 3h3h3h3h3h3hThe default boot selection will start in 10 seconds^H^H^H^H^H^H^H^H^H^H^H 9 seconds [1] Linux from NOR Flash [2] Debian ARMv8 [3] KVM [4] Xen from NOR Flash [5] Shell [6] Boot Manager Start: 5 UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (ARM Juno EFI Oct 23 2014 14:42:29, 0x00000000) Mapping table FS2: Alias(s):F10:;BLK1: VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) FS0: Alias(s):F3: MemoryMapped(0xB,0xE0000000,0xE00EFFFF) FS1: Alias(s):F4: MemoryMapped(0xB,0xFEBEE000,0xFEDDC0BF) BLK0: Alias(s): VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) Press ESC in 5 seconds to skip startup.nsh or any other key to continue.Press ESC in 4 seconds to skip startup.nsh or any other key to continue.Press ESC in 3 seconds to skip startup.nsh or any other key to continue.Press ESC in 2 seconds to skip startup.nsh or any other key to continue.Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> fs2: FS2:\> xen -cfg=cfg 3hXen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader juno.dtb: 0x00000009fac99000-0x00000009fac9bfc9 Image: 0x00000009fa27b000-0x00000009fac938a8 - UART enabled - - CPU 00000100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000dfffffff (XEN) RAM: 00000000e00f0000 - 00000000febd1fff (XEN) RAM: 00000000febd9000 - 00000000feffffff (XEN) RAM: 0000000880000000 - 00000009fa27afff (XEN) RAM: 00000009fac99000 - 00000009fac9afff (XEN) RAM: 00000009fae8c000 - 00000009faf6efff (XEN) RAM: 00000009fafaa000 - 00000009fec2cfff (XEN) RAM: 00000009fec2d000 - 00000009ff1bbfff (XEN) RAM: 00000009ff1bc000 - 00000009ff1c1fff (XEN) RAM: 00000009ff1c2000 - 00000009ffb73fff (XEN) RAM: 00000009ffb74000 - 00000009ffb77fff (XEN) RAM: 00000009ffb78000 - 00000009ffdddfff (XEN) RAM: 00000009ffdde000 - 00000009ffe75fff (XEN) RAM: 00000009ffe76000 - 00000009fff6dfff (XEN) RAM: 00000009fffff000 - 00000009ffffffff (XEN) (XEN) MODULE[0]: 00000009fac94000 - 00000009fac99000 Device Tree (XEN) MODULE[1]: 00000009fa27b000 - 00000009fac938a8 Kernel console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 (XEN) (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 (XEN) Update BOOTMOD_XEN from 00000009fac9e000-00000009fada8d81 => 00000000dfe00000-00000000dff0ad81 (XEN) PFN compression on bits 21...22 (XEN) Domain heap initialised (XEN) Looking for UART console serial0 Xen 4.5-unstable (XEN) Xen version 4.5-unstable (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 21:18:51 UTC 2015 (XEN) Latest ChangeSet: Mon Oct 20 20:55:25 2014 -0700 git:91086d0 (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: VERSATILE EXPRESS (XEN) Using PSCI-0.1 for SMP bringup (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 - CPU 00000101 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 00000102 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 00000103 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 3 booted. (XEN) Bringing up CPU4 - CPU 00000000 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 4 booted. (XEN) Bringing up CPU5 - CPU 00000001 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 5 booted. (XEN) Brought up 6 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa27b000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa27b000 to 00000000d0080000-00000000d0a988a8 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e02954 (XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs (XEN) ...........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 288kB init memory. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.15.0-rc8JP+ (root@arm64) (gcc version 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Thu Jul 16 16:54:26 UTC 2015 [ 0.000000] CPU: AArch64 Processor [410fd030] revision 0 [ 0.000000] cma: CMA: reserved 32 MiB at d5c00000 [ 0.000000] psci: probing function IDs from device-tree [ 0.000000] PERCPU: Embedded 12 pages/cpu @ffffffc007fa2000 s19200 r8192 d21760 u49152 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [ 0.000000] Kernel command line: console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 [ 0.000000] PID hash table entries: 512 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.000000] Memory: 70524K/131072K available (6641K kernel code, 582K rwdata, 2588K rodata, 518K init, 460K bss, 60548K reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB) [ 0.000000] vmemmap : 0xffffffbc03400000 - 0xffffffbc03600000 ( 2 MB) [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB) [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc008000000 ( 128 MB) [ 0.000000] .init : 0xffffffc000985000 - 0xffffffc000a06b00 ( 519 kB) [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc0009847a4 ( 9234 kB) [ 0.000000] .data : 0xffffffc000a07000 - 0xffffffc000a988a8 ( 583 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=6. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6 [ 0.000000] NR_IRQS:64 nr_irqs:64 0 [ 0.000000] Architected cp15 and mmio timer(s) running at 50.00MHz (virt/phys). [ 0.000005] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 2748779069440ns [ 0.000227] Console: colour dummy device 80x25 [ 0.001265] allocated 4194304 bytes of page_cgroup [ 0.001273] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.001287] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=500000) [ 0.001300] pid_max: default: 32768 minimum: 301 [ 0.001423] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.001435] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.002055] Initializing cgroup subsys debug [ 0.002070] Initializing cgroup subsys memory [ 0.002090] Initializing cgroup subsys devices [ 0.002100] Initializing cgroup subsys freezer [ 0.002109] Initializing cgroup subsys blkio [ 0.002118] Initializing cgroup subsys perf_event [ 0.002149] ftrace: allocating 23435 entries in 92 pages [ 0.053959] /cpus/cpu@0: Missing clock-frequency property [ 0.053995] /cpus/cpu@1: Missing clock-frequency property [ 0.054024] /cpus/cpu@2: Missing clock-frequency property [ 0.054055] /cpus/cpu@3: Missing clock-frequency property [ 0.054089] /cpus/cpu@4: Missing clock-frequency property [ 0.054126] /cpus/cpu@5: Missing clock-frequency property [ 0.054152] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 1 counters available [ 0.054262] Xen 4.5 support found, events_irq=31 gnttab_frame=0x00000000b0000000 [ 0.054387] xen:grant_table: Grant tables using version 1 layout [ 0.054430] Grant table initialized [ 0.054474] xen:events: Using FIFO-based ABI [ 0.054496] Xen: initializing cpu0 [ 0.114225] CPU1: Booted secondary processor [ 0.114282] Xen: initializing cpu1 [ 0.134271] CPU2: Booted secondary processor [ 0.134320] Xen: initializing cpu2 [ 0.154303] CPU3: Booted secondary processor [ 0.154351] Xen: initializing cpu3 [ 0.174372] CPU4: Booted secondary processor [ 0.174429] Xen: initializing cpu4 [ 0.194398] CPU5: Booted secondary processor [ 0.194446] Xen: initializing cpu5 [ 0.194634] Brought up 6 CPUs [ 0.194684] SMP: Total of 6 processors activated. [ 0.195818] devtmpfs: initialized [ 0.213972] sched: registering cpufreq notifiers for scale-invariant loads [ 0.215643] atomic64 test passed [ 0.216195] regulator-dummy: no parameters [ 0.221431] NET: Registered protocol family 16 [ 0.222781] vdso: 2 pages (1 code, 1 data) at base ffffffc000a0d000 [ 0.222862] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. [ 0.224599] software IO TLB [mem 0xd3c00000-0xd4000000] (4MB) mapped at [ffffffc003c00000-ffffffc003ffffff] [ 0.226178] DMA: preallocated 256 KiB pool for atomic allocations [ 0.227769] software IO TLB [mem 0xd3800000-0xd3c00000] (4MB) mapped at [ffffffc003800000-ffffffc003bfffff] [ 0.227843] Serial: AMBA PL011 UART driver [ 0.252564] xen:balloon: Initialising balloon driver [ 0.252950] xen_balloon: Initialising balloon driver [ 0.253666] 3V3: 3300 mV [ 0.254396] SCSI subsystem initialized [ 0.255136] usbcore: registered new interface driver usbfs [ 0.255236] usbcore: registered new interface driver hub [ 0.255429] usbcore: registered new device driver usb [ 0.258155] Advanced Linux Sound Architecture Driver Initialized. [ 0.259140] Switched to clocksource arch_sys_counter [ 0.326068] NET: Registered protocol family 2 [ 0.326688] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [ 0.326729] TCP bind hash table entries: 1024 (order: 2, 16384 bytes) [ 0.326768] TCP: Hash tables configured (established 1024 bind 1024) [ 0.326839] TCP: reno registered [ 0.326854] UDP hash table entries: 256 (order: 1, 8192 bytes) [ 0.326886] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) [ 0.327134] NET: Registered protocol family 1 [ 0.327663] RPC: Registered named UNIX socket transport module. [ 0.327673] RPC: Registered udp transport module. [ 0.327681] RPC: Registered tcp transport module. [ 0.327689] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.328296] kvm [1]: HYP mode not available [ 0.330205] futex hash table entries: 2048 (order: 5, 131072 bytes) [ 0.331333] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.353140] NFS: Registering the id_resolver key type [ 0.353184] Key type id_resolver registered [ 0.353196] Key type id_legacy registered [ 0.353221] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 0.353543] fuse init (API version 7.23) [ 0.354641] msgmni has been set to 201 [ 0.356566] io scheduler noop registered [ 0.356876] io scheduler cfq registered (default) [ 0.359006] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330 [ 0.359025] dma-pl330 7ff00000.dma: DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8 [ 0.360142] xen:xen_evtchn: Event-channel device installed [ 1.002919] console [hvc0] enabled [ 1.006436] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.015155] [drm] Initialized drm 1.1.0 20060810 [ 1.032004] brd: module loaded [ 1.041132] loop: module loaded [ 1.046906] libphy: smsc911x-mdio: probed [ 1.129307] smsc911x 18000000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.etherne:01, irq=-1) [ 1.140762] smsc911x 18000000.ethernet eth0: MAC Address: 00:02:f7:00:59:cd [ 1.147699] xen_netfront: Initialising Xen virtual ethernet driver [ 1.153991] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.160562] ehci-h20ahb: H20AHB-EHCI Host Controller driver [ 1.166347] ehci-h20ahb 7ffc0000.ehci: EHCI Host Controller [ 1.171886] ehci-h20ahb 7ffc0000.ehci: new USB bus registered, assigned bus number 1 [ 1.179917] ehci-h20ahb 7ffc0000.ehci: irq 149, io mem 0x7ffc0000 [ 1.185935] ehci-h20ahb 7ffc0000.ehci: enabled 64bit DMA [ 1.209177] ehci-h20ahb 7ffc0000.ehci: USB 2.0 started, EHCI 1.00 [ 1.216518] hub 1-0:1.0: USB hub found [ 1.220247] hub 1-0:1.0: 1 port detected [ 1.224761] ULPI transceiver vendor/product ID 0x0424/0x0009 [ 1.230360] Found SMSC USB334x ULPI transceiver. [ 1.235041] ULPI integrity check: passed. [ 1.239369] usbcore: registered new interface driver usb-storage [ 1.245623] mousedev: PS/2 mouse device common for all mice [ 1.252106] rtc-pl031 1c170000.rtc: rtc core: registered pl031 as rtc0 [ 1.258629] i2c /dev entries driver [ 1.263461] usbcore: registered new interface driver usbhid [ 1.268954] usbhid: USB HID core driver [ 1.277165] ion_chunk_heap_create: base 3535798272 size 4194304 align 16384 [ 1.285299] ashmem: initialized [ 1.288713] logger: created 256K log 'log_main' [ 1.293548] logger: created 256K log 'log_events' [ 1.298515] logger: created 256K log 'log_radio' [ 1.303445] logger: created 256K log 'log_system' [ 1.308667] Channel(mhu_ctlr:cpu_to_scp_low) not found! [ 1.313854] scpi_clocks clocks.2: failed to register clock 'vbig' [ 1.320050] platform clocks.2: Driver scpi_clocks requests probe deferral [ 1.327117] mhu_ctlr_drv 2b1f0000.mhu: registered mailbox controller mhu_ctlr [ 1.337090] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.344453] ERROR: could not get clock /i2s@7ff90000:i2sclk(0) [ 1.350253] platform 7ff90000.i2s: Driver designware-i2s requests probe deferral [ 1.357954] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.363833] arp_tables: (C) 2002 David S. Miller [ 1.368503] TCP: cubic registered [ 1.372857] NET: Registered protocol family 10 [ 1.378750] mip6: Mobile IPv6 [ 1.381690] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 1.387754] sit: IPv6 over IPv4 tunneling driver [ 1.393221] NET: Registered protocol family 17 [ 1.397704] Key type dns_resolver registered [ 1.489370] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.496743] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.504023] rtc-pl031 1c170000.rtc: setting system clock to 2015-07-17 17:24:37 UTC (1437153877) [ 1.514005] ALSA device list: [ 1.516898] No soundcards found. [ 1.520950] Waiting for root device /dev/sda3... [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb [ 1.659215] usb 1-1: device descriptor read/64, error -32 [ 1.889213] usb 1-1: device descriptor read/64, error -32 [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb [ 2.239213] usb 1-1: device descriptor read/64, error -32 [ 2.469249] usb 1-1: device descriptor read/64, error -32 [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb [ 3.119197] usb 1-1: device not accepting address 4, error -32 [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb [ 3.659181] usb 1-1: device not accepting address 5, error -32 [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 On Wed, Jul 15, 2015 at 4:41 PM, John Paul Walters wrote: > I've included the output of building xen with debug=y and > CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional > CPUs aren't coming up, but I noticed an error message early in the Xen > output: > > (XEN) Error: PSCI version 0x10000 is not supported. > > Then the dom0 kernel appears to crash inside of some PSCI initialization: > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: [] psci_init+0x2c/0x40 > (XEN) DOM0: [] setup_arch+0x420/0x5ac > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > Any suggestions would be welcome. > > thanks, > JP > > FS2:\> xen -cfg=cfg > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader > junoX: 0x00000009faf87000-0x00000009faf89b89 > ImageX: 0x00000009fa3be000-0x00000009fabf7000 > - UART enabled - > - CPU 00000100 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 0000000080000000 - 00000000dfffffff > (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff > (XEN) RAM: 00000000feba0000 - 00000000febabfff > (XEN) RAM: 00000000febac000 - 00000000feffffff > (XEN) RAM: 0000000880000000 - 00000009fa3bdfff > (XEN) RAM: 00000009fade9000 - 00000009faecffff > (XEN) RAM: 00000009faf80000 - 00000009faf82fff > (XEN) RAM: 00000009faf87000 - 00000009faf8afff > (XEN) RAM: 00000009faf8c000 - 00000009febe3fff > (XEN) RAM: 00000009febe4000 - 00000009ff142fff > (XEN) RAM: 00000009ff143000 - 00000009ff144fff > (XEN) RAM: 00000009ff145000 - 00000009ff16dfff > (XEN) RAM: 00000009ff16e000 - 00000009ff170fff > (XEN) RAM: 00000009ff171000 - 00000009ffdbffff > (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff > (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff > (XEN) RAM: 00000009fff90000 - 00000009fff9ffff > (XEN) RAM: 00000009ffff0000 - 00000009ffffefff > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > (XEN) > (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree > (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > (XEN) > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => > 00000000dfe00000-00000000dff0ad81 > (XEN) PFN compression on bits 21...22 > (XEN) Domain heap initialised > (XEN) Looking for UART console serial0 > Xen 4.5.1 > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Platform: VERSATILE EXPRESS > (XEN) Error: PSCI version 0x10000 is not supported. > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 64 KiB. > (XEN) Bringing up CPU1 > (XEN) Failed to bring up CPU1 > (XEN) Failed to bring up CPU 1 (error -1) > (XEN) Bringing up CPU2 > (XEN) Failed to bring up CPU2 > (XEN) Failed to bring up CPU 2 (error -1) > (XEN) Bringing up CPU3 > (XEN) Failed to bring up CPU3 > (XEN) Failed to bring up CPU 3 (error -1) > (XEN) Bringing up CPU4 > (XEN) Failed to bring up CPU4 > (XEN) Failed to bring up CPU 4 (error -1) > (XEN) Bringing up CPU5 > (XEN) Failed to bring up CPU5 > (XEN) Failed to bring up CPU 5 (error -1) > (XEN) Brought up 1 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa3be000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > (XEN) ................................................................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 284kB init memory. > (XEN) DOM0: Booting Linux on physical CPU 0x0 > (XEN) DOM0: Initializing cgroup subsys cpu > (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 > (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 > (XEN) DOM0: > (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 > (XEN) DOM0: Detected VIPT I-cache on CPU0 > (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, > 827319, 824069 > (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') > (XEN) DOM0: bootconsole [uart0] enabled > (XEN) DOM0: efi: Getting EFI parameters from FDT: > (XEN) DOM0: efi: UEFI not found. > (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 > (XEN) DOM0: psci: probing for conduit method from DT. > (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > (XEN) DOM0: Modules linked in: > (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 > (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) > (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: > ffffffc000860000 > (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 > (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 > (XEN) DOM0: sp : ffffffc000863ee0 > (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 > (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 > (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 > (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 > (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 > (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 > (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 > (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff > (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 > (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 > (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f > (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 > (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 > (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 > (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 > (XEN) DOM0: > (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) > (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) > (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 > 00000000 008bc000 ffffffc0 > (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 > ffffffc0 00817874 ffffffc0 > (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 > ffffffc0 00815670 ffffffc0 > (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 > ffffffc0 00866000 ffffffc0 > (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 > 00000000 d08f0000 00000000 > (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 > 00000000 64667467 ff616b73 > (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 > 00000000 00000e11 00000000 > (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 > 00000000 d0000000 00000000 > (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 > 00000000 00000000 00000000 > (XEN) DOM0: Call trace: > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: [] psci_init+0x2c/0x40 > (XEN) DOM0: [] setup_arch+0x420/0x5ac > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- > (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the > idle task! > > On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters > wrote: >> Hi Ian, >> >>> >>> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra >>> info. It would also be useful to see your file "cfg", in particular the >>> various command lines which it will contain. >>> >> I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but >> to answer your other questions, my cfg file: >> >> [global] >> default=default >> >> [default] >> options=console=dtuart dtuart=serial0 conswitch=x >> kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait >> root=/dev/sda3 >> dtb=junoX >> >> I copied that from the link I referenced earlier, I believe. The only >> differences are that I differentiated my default kernel and dtb from >> the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My >> root device is indeed /dev/sda3. >> >> >> >>> I take it your dom0 kernel binary boot successfully with all CPUs >>> natively? >> >> Yes, my dom0 kernel boots all CPUs successfully. I didn't really >> exercise them, but I can see all six of them. >> >>> >>>> >>>> thanks, >>>> JP >>>> >> >> >> >> >> >>>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >>>> [1] Linux from NOR Flash >>>> [2] Debian ARMv8 >>>> [3] KVM >>>> [4] Xen from NOR Flash >>>> [5] Shell >>>> [6] Boot Manager >>>> Start: 5 >>>> UEFI Interactive Shell v2.1 >>>> EDK II >>>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >>>> Mapping table >>>> FS2: Alias(s):F10:;BLK1: >>>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >>>> FS0: Alias(s):F3: >>>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >>>> FS1: Alias(s):F4: >>>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >>>> BLK0: Alias(s): >>>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >>>> Shell> fs2: >>>> FS2:\> xen -cfg=cfg >>>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >>>> junoX: 0x00000009faf87000-0x00000009faf89b89 >>>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >>>> Xen 4.5.1 >>>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >>>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >>>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >>>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >>>> (XEN) 64-bit Execution: >>>> (XEN) Processor Features: 0000000000002222 0000000000000000 >>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>>> (XEN) Extensions: FloatingPoint AdvancedSIMD >>>> (XEN) Debug Features: 0000000010305106 0000000000000000 >>>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >>>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >>>> (XEN) ISA Features: 0000000000011120 0000000000000000 >>>> (XEN) 32-bit Execution: >>>> (XEN) Processor Features: 00000131:00011011 >>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>>> (XEN) Extensions: GenericTimer Security >>>> (XEN) Debug Features: 03010066 >>>> (XEN) Auxiliary Features: 00000000 >>>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >>>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >>>> (XEN) Error: PSCI version 0x10000 is not supported. >>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >>>> (XEN) Using generic timer at 50000 KHz >>>> (XEN) GICv2 initialization: >>>> (XEN) gic_dist_addr=000000002c010000 >>>> (XEN) gic_cpu_addr=000000002c02f000 >>>> (XEN) gic_hyp_addr=000000002c04f000 >>>> (XEN) gic_vcpu_addr=000000002c06f000 >>>> (XEN) gic_maintenance_irq=25 >>>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >>>> (XEN) Using scheduler: SMP Credit Scheduler (credit) >>>> (XEN) I/O virtualisation disabled >>>> (XEN) Allocated console ring of 16 KiB. >>>> (XEN) Bringing up CPU1 >>>> (XEN) Failed to bring up CPU1 >>>> (XEN) Failed to bring up CPU 1 (error -1) >>>> (XEN) Bringing up CPU2 >>>> (XEN) Failed to bring up CPU2 >>>> (XEN) Failed to bring up CPU 2 (error -1) >>>> (XEN) Bringing up CPU3 >>>> (XEN) Failed to bring up CPU3 >>>> (XEN) Failed to bring up CPU 3 (error -1) >>>> (XEN) Bringing up CPU4 >>>> (XEN) Failed to bring up CPU4 >>>> (XEN) Failed to bring up CPU 4 (error -1) >>>> (XEN) Bringing up CPU5 >>>> (XEN) Failed to bring up CPU5 >>>> (XEN) Failed to bring up CPU 5 (error -1) >>>> (XEN) Brought up 1 CPUs >>>> (XEN) P2M: 40-bit IPA with 40-bit PA >>>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >>>> (XEN) *** LOADING DOMAIN 0 *** >>>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >>>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >>>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >>>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >>>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >>>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >>>> (XEN) ................................................................done. >>>> (XEN) Initial low memory virq threshold set at 0x4000 pages. >>>> (XEN) Std. Loglevel: Errors and warnings >>>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >>>> input to Xen) >>>> (XEN) Freed 280kB init memory. >>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >>>> input to DOM0) >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xen.org >>>> http://lists.xen.org/xen-users >>> >>> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 21:00:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 21:00:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGCjG-0000t4-J4; Fri, 17 Jul 2015 20:59:34 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGCjE-0000sv-QB for xen-users@lists.xen.org; Fri, 17 Jul 2015 20:59:33 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 8A/06-30151-4BC69A55; Fri, 17 Jul 2015 20:59:32 +0000 X-Env-Sender: jpnwalters@gmail.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1437166769!33117875!1 X-Originating-IP: [209.85.217.182] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28334 invoked from network); 17 Jul 2015 20:59:29 -0000 Received: from mail-lb0-f182.google.com (HELO mail-lb0-f182.google.com) (209.85.217.182) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 17 Jul 2015 20:59:29 -0000 Received: by lbbyj8 with SMTP id yj8so67563883lbb.0 for ; Fri, 17 Jul 2015 13:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Z6Kan+jS/4hV8zVpiDg3MZ7ZZrc1RufGgmb4s4OhtQE=; b=rLn7N3apeYMZbV+2cvGlIxNB5l2iFTRIk8h8J/7XyTW8QQflrpT6gGG3FY+uqL8ij5 hMpJ+mP5TDJiOxdUIzjwC31JPc96RUkI4yRSBFzttt4vEqh9a2dViLuGlwLlqFgaU4fv 3dfXUXTW3JDlWOw41T01qfGI3sDEuzys6VrWVSAMJtFI9HD/CtFXcvrweOzdfhsMcuDF jJA7dVdCuuSQBOx1Ucfl9yTKsCr0sAEK6ya86oc3bPappJXU0PobOsMGFoWEt5UwoC7I Hkepk6a+nOkMmOMMUDAa/SXO7M/g4Z6CCL+9UHIKRP8WBw9OazXukiN+FXcGK1AvQSCk vPjA== X-Received: by 10.112.171.68 with SMTP id as4mr16200055lbc.64.1437166768984; Fri, 17 Jul 2015 13:59:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.214.131 with HTTP; Fri, 17 Jul 2015 13:59:09 -0700 (PDT) In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> From: John Paul Walters Date: Fri, 17 Jul 2015 16:59:09 -0400 Message-ID: To: Ian Campbell Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I've made some progress by rolling back to an earlier firmware and kernel version. It looks like I'm now able to fully boot Xen along with all 6 cores and Dom0 starts booting. Now, on waiting for the root device to become available, USB enumeration fails. Since Juno relies on USB for the root disk, this prevents booting. I've confirmed that the same kernel boots fine outside of Xen. The boot messages in question are, with the full boot log below: [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb [ 1.659215] usb 1-1: device descriptor read/64, error -32 [ 1.889213] usb 1-1: device descriptor read/64, error -32 [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb [ 2.239213] usb 1-1: device descriptor read/64, error -32 [ 2.469249] usb 1-1: device descriptor read/64, error -32 [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb [ 3.119197] usb 1-1: device not accepting address 4, error -32 [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb [ 3.659181] usb 1-1: device not accepting address 5, error -32 [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 So I have a couple of questions. Has anyone run into this USB issue before? If not, can someone point me to the firmware/kernel versions that were known to successfully boot Xen on the Juno board? ARM V2M-Juno Boot loader v1.0.0 HBI0262 build 1156 ARM V2M_Juno Firmware v1.2.7 Build Date: Oct 3 2014 Time : 17:23:54 Date : 17:07:2015 Cmd> Powering up system... Switching on ATXPSU... PMIC RAM configuration (pms_v103.bin)... MBtemp : 37 degC Configuring motherboard (rev B, var B)... IOFPGA image \MB\HBI0262B\io_b115.bit IOFPGA config: PASSED OSC CLK config: PASSED Configuring SCC registers... Writing SCC 0x00000054 with 0x0007FFFE Writing SCC 0x0000005C with 0x00FE001E Writing SCC 0x00000100 with 0x003F1000 Writing SCC 0x00000104 with 0x0001F300 Writing SCC 0x00000108 with 0x00371000 Writing SCC 0x0000010C with 0x0001B300 Writing SCC 0x00000118 with 0x003F1000 Writing SCC 0x0000011C with 0x0001F100 Writing SCC 0x000000F8 with 0x0BEC0000 Writing SCC 0x0000000C with 0x000000C2 Writing SCC 0x00000010 with 0x000000C2 Peripheral ID0:0x000000AD Peripheral ID1:0x000000B0 Peripheral ID2:0x0000000B Peripheral ID3:0x00000000 Peripheral ID4:0x0000000D Peripheral ID5:0x000000F0 Peripheral ID6:0x00000005 Peripheral ID7:0x000000B1 Programming NOR Flash PCIE clock configured... Testing motherboard interfaces (FPGA build 115)... SRAM 32MB test: PASSED LAN9118 test: PASSED KMI1/2 test: PASSED MMC test: PASSED PB/LEDs test: PASSED FPGA UART test: PASSED PCIe init test: PASSED MAC addrs test: PASSED Setting HDMI0 mode for SVGA. Setting HDMI1 mode for SVGA. SoC SMB clock enabled. Testing SMB clock... SMB clock running Releasing system resets... UART0 set to SoC UART0 UART1 set to SoC UART1 NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.0(release):14b6608 NOTICE: BL1: Built : 14:15:51, Sep 1 2014 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.0(release):14b6608 NOTICE: BL2: Built : 14:15:51, Sep 1 2014 NOTICE: BL1: Booting BL3-1 NOTICE: BL3-1: v1.0(release):14b6608 NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014 UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014) 3h3h3h3h3h3hThe default boot selection will start in 10 seconds^H^H^H^H^H^H^H^H^H^H^H 9 seconds [1] Linux from NOR Flash [2] Debian ARMv8 [3] KVM [4] Xen from NOR Flash [5] Shell [6] Boot Manager Start: 5 UEFI Interactive Shell v2.1 EDK II UEFI v2.40 (ARM Juno EFI Oct 23 2014 14:42:29, 0x00000000) Mapping table FS2: Alias(s):F10:;BLK1: VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) FS0: Alias(s):F3: MemoryMapped(0xB,0xE0000000,0xE00EFFFF) FS1: Alias(s):F4: MemoryMapped(0xB,0xFEBEE000,0xFEDDC0BF) BLK0: Alias(s): VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) Press ESC in 5 seconds to skip startup.nsh or any other key to continue.Press ESC in 4 seconds to skip startup.nsh or any other key to continue.Press ESC in 3 seconds to skip startup.nsh or any other key to continue.Press ESC in 2 seconds to skip startup.nsh or any other key to continue.Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell> fs2: FS2:\> xen -cfg=cfg 3hXen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader juno.dtb: 0x00000009fac99000-0x00000009fac9bfc9 Image: 0x00000009fa27b000-0x00000009fac938a8 - UART enabled - - CPU 00000100 booting - - Current EL 00000008 - - Xen starting at EL2 - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000dfffffff (XEN) RAM: 00000000e00f0000 - 00000000febd1fff (XEN) RAM: 00000000febd9000 - 00000000feffffff (XEN) RAM: 0000000880000000 - 00000009fa27afff (XEN) RAM: 00000009fac99000 - 00000009fac9afff (XEN) RAM: 00000009fae8c000 - 00000009faf6efff (XEN) RAM: 00000009fafaa000 - 00000009fec2cfff (XEN) RAM: 00000009fec2d000 - 00000009ff1bbfff (XEN) RAM: 00000009ff1bc000 - 00000009ff1c1fff (XEN) RAM: 00000009ff1c2000 - 00000009ffb73fff (XEN) RAM: 00000009ffb74000 - 00000009ffb77fff (XEN) RAM: 00000009ffb78000 - 00000009ffdddfff (XEN) RAM: 00000009ffdde000 - 00000009ffe75fff (XEN) RAM: 00000009ffe76000 - 00000009fff6dfff (XEN) RAM: 00000009fffff000 - 00000009ffffffff (XEN) (XEN) MODULE[0]: 00000009fac94000 - 00000009fac99000 Device Tree (XEN) MODULE[1]: 00000009fa27b000 - 00000009fac938a8 Kernel console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 (XEN) (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 (XEN) Update BOOTMOD_XEN from 00000009fac9e000-00000009fada8d81 => 00000000dfe00000-00000000dff0ad81 (XEN) PFN compression on bits 21...22 (XEN) Domain heap initialised (XEN) Looking for UART console serial0 Xen 4.5-unstable (XEN) Xen version 4.5-unstable (root@cambridge.arm.com) (gcc (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 21:18:51 UTC 2015 (XEN) Latest ChangeSet: Mon Oct 20 20:55:25 2014 -0700 git:91086d0 (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 (XEN) 64-bit Execution: (XEN) Processor Features: 0000000000002222 0000000000000000 (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 (XEN) Extensions: FloatingPoint AdvancedSIMD (XEN) Debug Features: 0000000010305106 0000000000000000 (XEN) Auxiliary Features: 0000000000000000 0000000000000000 (XEN) Memory Model Features: 0000000000001122 0000000000000000 (XEN) ISA Features: 0000000000011120 0000000000000000 (XEN) 32-bit Execution: (XEN) Processor Features: 00000131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 03010066 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 (XEN) Platform: VERSATILE EXPRESS (XEN) Using PSCI-0.1 for SMP bringup (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 (XEN) Using generic timer at 50000 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=000000002c010000 (XEN) gic_cpu_addr=000000002c02f000 (XEN) gic_hyp_addr=000000002c04f000 (XEN) gic_vcpu_addr=000000002c06f000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) I/O virtualisation disabled (XEN) Allocated console ring of 64 KiB. (XEN) Bringing up CPU1 - CPU 00000101 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 1 booted. (XEN) Bringing up CPU2 - CPU 00000102 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 2 booted. (XEN) Bringing up CPU3 - CPU 00000103 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 3 booted. (XEN) Bringing up CPU4 - CPU 00000000 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 4 booted. (XEN) Bringing up CPU5 - CPU 00000001 booting - - Current EL 00000008 - - Xen starting at EL2 - - Setting up control registers - - Turning on paging - - Ready - (XEN) CPU 5 booted. (XEN) Brought up 6 CPUs (XEN) P2M: 40-bit IPA with 40-bit PA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000009fa27b000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) (XEN) Loading zImage from 00000009fa27b000 to 00000000d0080000-00000000d0a988a8 (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e02954 (XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs (XEN) ...........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch input to Xen) (XEN) Freed 288kB init memory. [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 3.15.0-rc8JP+ (root@arm64) (gcc version 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Thu Jul 16 16:54:26 UTC 2015 [ 0.000000] CPU: AArch64 Processor [410fd030] revision 0 [ 0.000000] cma: CMA: reserved 32 MiB at d5c00000 [ 0.000000] psci: probing function IDs from device-tree [ 0.000000] PERCPU: Embedded 12 pages/cpu @ffffffc007fa2000 s19200 r8192 d21760 u49152 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32256 [ 0.000000] Kernel command line: console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 [ 0.000000] PID hash table entries: 512 (order: 0, 4096 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) [ 0.000000] Memory: 70524K/131072K available (6641K kernel code, 582K rwdata, 2588K rodata, 518K init, 460K bss, 60548K reserved) [ 0.000000] Virtual kernel memory layout: [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 (245759 MB) [ 0.000000] vmemmap : 0xffffffbc03400000 - 0xffffffbc03600000 ( 2 MB) [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64 MB) [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc008000000 ( 128 MB) [ 0.000000] .init : 0xffffffc000985000 - 0xffffffc000a06b00 ( 519 kB) [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc0009847a4 ( 9234 kB) [ 0.000000] .data : 0xffffffc000a07000 - 0xffffffc000a988a8 ( 583 kB) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 [ 0.000000] Preemptible hierarchical RCU implementation. [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=6. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6 [ 0.000000] NR_IRQS:64 nr_irqs:64 0 [ 0.000000] Architected cp15 and mmio timer(s) running at 50.00MHz (virt/phys). [ 0.000005] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps every 2748779069440ns [ 0.000227] Console: colour dummy device 80x25 [ 0.001265] allocated 4194304 bytes of page_cgroup [ 0.001273] please try 'cgroup_disable=memory' option if you don't want memory cgroups [ 0.001287] Calibrating delay loop (skipped), value calculated using timer frequency.. 100.00 BogoMIPS (lpj=500000) [ 0.001300] pid_max: default: 32768 minimum: 301 [ 0.001423] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.001435] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) [ 0.002055] Initializing cgroup subsys debug [ 0.002070] Initializing cgroup subsys memory [ 0.002090] Initializing cgroup subsys devices [ 0.002100] Initializing cgroup subsys freezer [ 0.002109] Initializing cgroup subsys blkio [ 0.002118] Initializing cgroup subsys perf_event [ 0.002149] ftrace: allocating 23435 entries in 92 pages [ 0.053959] /cpus/cpu@0: Missing clock-frequency property [ 0.053995] /cpus/cpu@1: Missing clock-frequency property [ 0.054024] /cpus/cpu@2: Missing clock-frequency property [ 0.054055] /cpus/cpu@3: Missing clock-frequency property [ 0.054089] /cpus/cpu@4: Missing clock-frequency property [ 0.054126] /cpus/cpu@5: Missing clock-frequency property [ 0.054152] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 1 counters available [ 0.054262] Xen 4.5 support found, events_irq=31 gnttab_frame=0x00000000b0000000 [ 0.054387] xen:grant_table: Grant tables using version 1 layout [ 0.054430] Grant table initialized [ 0.054474] xen:events: Using FIFO-based ABI [ 0.054496] Xen: initializing cpu0 [ 0.114225] CPU1: Booted secondary processor [ 0.114282] Xen: initializing cpu1 [ 0.134271] CPU2: Booted secondary processor [ 0.134320] Xen: initializing cpu2 [ 0.154303] CPU3: Booted secondary processor [ 0.154351] Xen: initializing cpu3 [ 0.174372] CPU4: Booted secondary processor [ 0.174429] Xen: initializing cpu4 [ 0.194398] CPU5: Booted secondary processor [ 0.194446] Xen: initializing cpu5 [ 0.194634] Brought up 6 CPUs [ 0.194684] SMP: Total of 6 processors activated. [ 0.195818] devtmpfs: initialized [ 0.213972] sched: registering cpufreq notifiers for scale-invariant loads [ 0.215643] atomic64 test passed [ 0.216195] regulator-dummy: no parameters [ 0.221431] NET: Registered protocol family 16 [ 0.222781] vdso: 2 pages (1 code, 1 data) at base ffffffc000a0d000 [ 0.222862] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. [ 0.224599] software IO TLB [mem 0xd3c00000-0xd4000000] (4MB) mapped at [ffffffc003c00000-ffffffc003ffffff] [ 0.226178] DMA: preallocated 256 KiB pool for atomic allocations [ 0.227769] software IO TLB [mem 0xd3800000-0xd3c00000] (4MB) mapped at [ffffffc003800000-ffffffc003bfffff] [ 0.227843] Serial: AMBA PL011 UART driver [ 0.252564] xen:balloon: Initialising balloon driver [ 0.252950] xen_balloon: Initialising balloon driver [ 0.253666] 3V3: 3300 mV [ 0.254396] SCSI subsystem initialized [ 0.255136] usbcore: registered new interface driver usbfs [ 0.255236] usbcore: registered new interface driver hub [ 0.255429] usbcore: registered new device driver usb [ 0.258155] Advanced Linux Sound Architecture Driver Initialized. [ 0.259140] Switched to clocksource arch_sys_counter [ 0.326068] NET: Registered protocol family 2 [ 0.326688] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [ 0.326729] TCP bind hash table entries: 1024 (order: 2, 16384 bytes) [ 0.326768] TCP: Hash tables configured (established 1024 bind 1024) [ 0.326839] TCP: reno registered [ 0.326854] UDP hash table entries: 256 (order: 1, 8192 bytes) [ 0.326886] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) [ 0.327134] NET: Registered protocol family 1 [ 0.327663] RPC: Registered named UNIX socket transport module. [ 0.327673] RPC: Registered udp transport module. [ 0.327681] RPC: Registered tcp transport module. [ 0.327689] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.328296] kvm [1]: HYP mode not available [ 0.330205] futex hash table entries: 2048 (order: 5, 131072 bytes) [ 0.331333] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 0.353140] NFS: Registering the id_resolver key type [ 0.353184] Key type id_resolver registered [ 0.353196] Key type id_legacy registered [ 0.353221] nfs4filelayout_init: NFSv4 File Layout Driver Registering... [ 0.353543] fuse init (API version 7.23) [ 0.354641] msgmni has been set to 201 [ 0.356566] io scheduler noop registered [ 0.356876] io scheduler cfq registered (default) [ 0.359006] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330 [ 0.359025] dma-pl330 7ff00000.dma: DBUFF-1024x16bytes Num_Chans-8 Num_Peri-8 Num_Events-8 [ 0.360142] xen:xen_evtchn: Event-channel device installed [ 1.002919] console [hvc0] enabled [ 1.006436] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled [ 1.015155] [drm] Initialized drm 1.1.0 20060810 [ 1.032004] brd: module loaded [ 1.041132] loop: module loaded [ 1.046906] libphy: smsc911x-mdio: probed [ 1.129307] smsc911x 18000000.ethernet eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=18000000.etherne:01, irq=-1) [ 1.140762] smsc911x 18000000.ethernet eth0: MAC Address: 00:02:f7:00:59:cd [ 1.147699] xen_netfront: Initialising Xen virtual ethernet driver [ 1.153991] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 1.160562] ehci-h20ahb: H20AHB-EHCI Host Controller driver [ 1.166347] ehci-h20ahb 7ffc0000.ehci: EHCI Host Controller [ 1.171886] ehci-h20ahb 7ffc0000.ehci: new USB bus registered, assigned bus number 1 [ 1.179917] ehci-h20ahb 7ffc0000.ehci: irq 149, io mem 0x7ffc0000 [ 1.185935] ehci-h20ahb 7ffc0000.ehci: enabled 64bit DMA [ 1.209177] ehci-h20ahb 7ffc0000.ehci: USB 2.0 started, EHCI 1.00 [ 1.216518] hub 1-0:1.0: USB hub found [ 1.220247] hub 1-0:1.0: 1 port detected [ 1.224761] ULPI transceiver vendor/product ID 0x0424/0x0009 [ 1.230360] Found SMSC USB334x ULPI transceiver. [ 1.235041] ULPI integrity check: passed. [ 1.239369] usbcore: registered new interface driver usb-storage [ 1.245623] mousedev: PS/2 mouse device common for all mice [ 1.252106] rtc-pl031 1c170000.rtc: rtc core: registered pl031 as rtc0 [ 1.258629] i2c /dev entries driver [ 1.263461] usbcore: registered new interface driver usbhid [ 1.268954] usbhid: USB HID core driver [ 1.277165] ion_chunk_heap_create: base 3535798272 size 4194304 align 16384 [ 1.285299] ashmem: initialized [ 1.288713] logger: created 256K log 'log_main' [ 1.293548] logger: created 256K log 'log_events' [ 1.298515] logger: created 256K log 'log_radio' [ 1.303445] logger: created 256K log 'log_system' [ 1.308667] Channel(mhu_ctlr:cpu_to_scp_low) not found! [ 1.313854] scpi_clocks clocks.2: failed to register clock 'vbig' [ 1.320050] platform clocks.2: Driver scpi_clocks requests probe deferral [ 1.327117] mhu_ctlr_drv 2b1f0000.mhu: registered mailbox controller mhu_ctlr [ 1.337090] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.344453] ERROR: could not get clock /i2s@7ff90000:i2sclk(0) [ 1.350253] platform 7ff90000.i2s: Driver designware-i2s requests probe deferral [ 1.357954] ip_tables: (C) 2000-2006 Netfilter Core Team [ 1.363833] arp_tables: (C) 2002 David S. Miller [ 1.368503] TCP: cubic registered [ 1.372857] NET: Registered protocol family 10 [ 1.378750] mip6: Mobile IPv6 [ 1.381690] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 1.387754] sit: IPv6 over IPv4 tunneling driver [ 1.393221] NET: Registered protocol family 17 [ 1.397704] Key type dns_resolver registered [ 1.489370] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.496743] platform sound.14: Driver asoc-simple-card requests probe deferral [ 1.504023] rtc-pl031 1c170000.rtc: setting system clock to 2015-07-17 17:24:37 UTC (1437153877) [ 1.514005] ALSA device list: [ 1.516898] No soundcards found. [ 1.520950] Waiting for root device /dev/sda3... [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb [ 1.659215] usb 1-1: device descriptor read/64, error -32 [ 1.889213] usb 1-1: device descriptor read/64, error -32 [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb [ 2.239213] usb 1-1: device descriptor read/64, error -32 [ 2.469249] usb 1-1: device descriptor read/64, error -32 [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb [ 3.119197] usb 1-1: device not accepting address 4, error -32 [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb [ 3.659181] usb 1-1: device not accepting address 5, error -32 [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 On Wed, Jul 15, 2015 at 4:41 PM, John Paul Walters wrote: > I've included the output of building xen with debug=y and > CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional > CPUs aren't coming up, but I noticed an error message early in the Xen > output: > > (XEN) Error: PSCI version 0x10000 is not supported. > > Then the dom0 kernel appears to crash inside of some PSCI initialization: > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: [] psci_init+0x2c/0x40 > (XEN) DOM0: [] setup_arch+0x420/0x5ac > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > Any suggestions would be welcome. > > thanks, > JP > > FS2:\> xen -cfg=cfg > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader > junoX: 0x00000009faf87000-0x00000009faf89b89 > ImageX: 0x00000009fa3be000-0x00000009fabf7000 > - UART enabled - > - CPU 00000100 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 0000000080000000 - 00000000dfffffff > (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff > (XEN) RAM: 00000000feba0000 - 00000000febabfff > (XEN) RAM: 00000000febac000 - 00000000feffffff > (XEN) RAM: 0000000880000000 - 00000009fa3bdfff > (XEN) RAM: 00000009fade9000 - 00000009faecffff > (XEN) RAM: 00000009faf80000 - 00000009faf82fff > (XEN) RAM: 00000009faf87000 - 00000009faf8afff > (XEN) RAM: 00000009faf8c000 - 00000009febe3fff > (XEN) RAM: 00000009febe4000 - 00000009ff142fff > (XEN) RAM: 00000009ff143000 - 00000009ff144fff > (XEN) RAM: 00000009ff145000 - 00000009ff16dfff > (XEN) RAM: 00000009ff16e000 - 00000009ff170fff > (XEN) RAM: 00000009ff171000 - 00000009ffdbffff > (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff > (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff > (XEN) RAM: 00000009fff90000 - 00000009fff9ffff > (XEN) RAM: 00000009ffff0000 - 00000009ffffefff > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > (XEN) > (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree > (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > (XEN) > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => > 00000000dfe00000-00000000dff0ad81 > (XEN) PFN compression on bits 21...22 > (XEN) Domain heap initialised > (XEN) Looking for UART console serial0 > Xen 4.5.1 > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Platform: VERSATILE EXPRESS > (XEN) Error: PSCI version 0x10000 is not supported. > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 64 KiB. > (XEN) Bringing up CPU1 > (XEN) Failed to bring up CPU1 > (XEN) Failed to bring up CPU 1 (error -1) > (XEN) Bringing up CPU2 > (XEN) Failed to bring up CPU2 > (XEN) Failed to bring up CPU 2 (error -1) > (XEN) Bringing up CPU3 > (XEN) Failed to bring up CPU3 > (XEN) Failed to bring up CPU 3 (error -1) > (XEN) Bringing up CPU4 > (XEN) Failed to bring up CPU4 > (XEN) Failed to bring up CPU 4 (error -1) > (XEN) Bringing up CPU5 > (XEN) Failed to bring up CPU5 > (XEN) Failed to bring up CPU 5 (error -1) > (XEN) Brought up 1 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa3be000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > (XEN) ................................................................done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 284kB init memory. > (XEN) DOM0: Booting Linux on physical CPU 0x0 > (XEN) DOM0: Initializing cgroup subsys cpu > (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 > (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 > (XEN) DOM0: > (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 > (XEN) DOM0: Detected VIPT I-cache on CPU0 > (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, > 827319, 824069 > (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') > (XEN) DOM0: bootconsole [uart0] enabled > (XEN) DOM0: efi: Getting EFI parameters from FDT: > (XEN) DOM0: efi: UEFI not found. > (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 > (XEN) DOM0: psci: probing for conduit method from DT. > (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > (XEN) DOM0: Modules linked in: > (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 > (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) > (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: > ffffffc000860000 > (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 > (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 > (XEN) DOM0: sp : ffffffc000863ee0 > (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 > (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 > (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 > (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 > (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 > (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 > (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 > (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff > (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 > (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 > (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f > (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 > (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 > (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 > (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 > (XEN) DOM0: > (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) > (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) > (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 > 00000000 008bc000 ffffffc0 > (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 > ffffffc0 00817874 ffffffc0 > (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 > ffffffc0 00815670 ffffffc0 > (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 > ffffffc0 00866000 ffffffc0 > (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 > 00000000 d08f0000 00000000 > (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 > 00000000 64667467 ff616b73 > (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 > 00000000 00000e11 00000000 > (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 > 00000000 d0000000 00000000 > (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 > 00000000 00000000 00000000 > (XEN) DOM0: Call trace: > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > (XEN) DOM0: [] psci_init+0x2c/0x40 > (XEN) DOM0: [] setup_arch+0x420/0x5ac > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- > (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the > idle task! > > On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters > wrote: >> Hi Ian, >> >>> >>> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra >>> info. It would also be useful to see your file "cfg", in particular the >>> various command lines which it will contain. >>> >> I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but >> to answer your other questions, my cfg file: >> >> [global] >> default=default >> >> [default] >> options=console=dtuart dtuart=serial0 conswitch=x >> kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait >> root=/dev/sda3 >> dtb=junoX >> >> I copied that from the link I referenced earlier, I believe. The only >> differences are that I differentiated my default kernel and dtb from >> the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My >> root device is indeed /dev/sda3. >> >> >> >>> I take it your dom0 kernel binary boot successfully with all CPUs >>> natively? >> >> Yes, my dom0 kernel boots all CPUs successfully. I didn't really >> exercise them, but I can see all six of them. >> >>> >>>> >>>> thanks, >>>> JP >>>> >> >> >> >> >> >>>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) >>>> [1] Linux from NOR Flash >>>> [2] Debian ARMv8 >>>> [3] KVM >>>> [4] Xen from NOR Flash >>>> [5] Shell >>>> [6] Boot Manager >>>> Start: 5 >>>> UEFI Interactive Shell v2.1 >>>> EDK II >>>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) >>>> Mapping table >>>> FS2: Alias(s):F10:;BLK1: >>>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) >>>> FS0: Alias(s):F3: >>>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) >>>> FS1: Alias(s):F4: >>>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) >>>> BLK0: Alias(s): >>>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) >>>> Shell> fs2: >>>> FS2:\> xen -cfg=cfg >>>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader >>>> junoX: 0x00000009faf87000-0x00000009faf89b89 >>>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 >>>> Xen 4.5.1 >>>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro >>>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 >>>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 >>>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 >>>> (XEN) 64-bit Execution: >>>> (XEN) Processor Features: 0000000000002222 0000000000000000 >>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 >>>> (XEN) Extensions: FloatingPoint AdvancedSIMD >>>> (XEN) Debug Features: 0000000010305106 0000000000000000 >>>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 >>>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 >>>> (XEN) ISA Features: 0000000000011120 0000000000000000 >>>> (XEN) 32-bit Execution: >>>> (XEN) Processor Features: 00000131:00011011 >>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle >>>> (XEN) Extensions: GenericTimer Security >>>> (XEN) Debug Features: 03010066 >>>> (XEN) Auxiliary Features: 00000000 >>>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 >>>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 >>>> (XEN) Error: PSCI version 0x10000 is not supported. >>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 >>>> (XEN) Using generic timer at 50000 KHz >>>> (XEN) GICv2 initialization: >>>> (XEN) gic_dist_addr=000000002c010000 >>>> (XEN) gic_cpu_addr=000000002c02f000 >>>> (XEN) gic_hyp_addr=000000002c04f000 >>>> (XEN) gic_vcpu_addr=000000002c06f000 >>>> (XEN) gic_maintenance_irq=25 >>>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). >>>> (XEN) Using scheduler: SMP Credit Scheduler (credit) >>>> (XEN) I/O virtualisation disabled >>>> (XEN) Allocated console ring of 16 KiB. >>>> (XEN) Bringing up CPU1 >>>> (XEN) Failed to bring up CPU1 >>>> (XEN) Failed to bring up CPU 1 (error -1) >>>> (XEN) Bringing up CPU2 >>>> (XEN) Failed to bring up CPU2 >>>> (XEN) Failed to bring up CPU 2 (error -1) >>>> (XEN) Bringing up CPU3 >>>> (XEN) Failed to bring up CPU3 >>>> (XEN) Failed to bring up CPU 3 (error -1) >>>> (XEN) Bringing up CPU4 >>>> (XEN) Failed to bring up CPU4 >>>> (XEN) Failed to bring up CPU 4 (error -1) >>>> (XEN) Bringing up CPU5 >>>> (XEN) Failed to bring up CPU5 >>>> (XEN) Failed to bring up CPU 5 (error -1) >>>> (XEN) Brought up 1 CPUs >>>> (XEN) P2M: 40-bit IPA with 40-bit PA >>>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 >>>> (XEN) *** LOADING DOMAIN 0 *** >>>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 >>>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: >>>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) >>>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 >>>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f >>>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs >>>> (XEN) ................................................................done. >>>> (XEN) Initial low memory virq threshold set at 0x4000 pages. >>>> (XEN) Std. Loglevel: Errors and warnings >>>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch >>>> input to Xen) >>>> (XEN) Freed 280kB init memory. >>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch >>>> input to DOM0) >>>> >>>> _______________________________________________ >>>> Xen-users mailing list >>>> Xen-users@lists.xen.org >>>> http://lists.xen.org/xen-users >>> >>> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 21:45:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 21:45:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGDQS-00045N-VN; Fri, 17 Jul 2015 21:44:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGDQR-00045I-7N for xen-users@lists.xen.org; Fri, 17 Jul 2015 21:44:11 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 89/5F-21300-A2779A55; Fri, 17 Jul 2015 21:44:10 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1437169449!31848483!1 X-Originating-IP: [216.31.210.63] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19468 invoked from network); 17 Jul 2015 21:44:09 -0000 Received: from mail-gw2-out.broadcom.com (HELO mail-gw2-out.broadcom.com) (216.31.210.63) by server-4.tower-27.messagelabs.com with SMTP; 17 Jul 2015 21:44:09 -0000 X-IronPort-AV: E=Sophos;i="5.15,497,1432623600"; d="scan'208";a="70123368" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Jul 2015 15:01:50 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 17 Jul 2015 14:44:06 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Fri, 17 Jul 2015 14:44:06 -0700 From: "Chris (Christopher) Brand" To: "xen-users@lists.xen.org" Thread-Topic: ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQ== Date: Fri, 17 Jul 2015 21:44:06 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Subject: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, I'm trying to reduce the memory footprint of Xen on my 2GB platform, and one place that seems like a good target is the xenheap, which defaults to 64MB, very little of which I've seen used so far. I found the command line xenheap_megabytes command-line option, and setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, which mentions that back in the days of Xen 3.3, xenheap defaulted to 16MB, which indicates that I'm not trying something totally ridiculous. Thanks, Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 21:45:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 21:45:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGDQS-00045N-VN; Fri, 17 Jul 2015 21:44:12 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGDQR-00045I-7N for xen-users@lists.xen.org; Fri, 17 Jul 2015 21:44:11 +0000 Received: from [193.109.254.147] by server-14.bemta-14.messagelabs.com id 89/5F-21300-A2779A55; Fri, 17 Jul 2015 21:44:10 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1437169449!31848483!1 X-Originating-IP: [216.31.210.63] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19468 invoked from network); 17 Jul 2015 21:44:09 -0000 Received: from mail-gw2-out.broadcom.com (HELO mail-gw2-out.broadcom.com) (216.31.210.63) by server-4.tower-27.messagelabs.com with SMTP; 17 Jul 2015 21:44:09 -0000 X-IronPort-AV: E=Sophos;i="5.15,497,1432623600"; d="scan'208";a="70123368" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw2-out.broadcom.com with ESMTP; 17 Jul 2015 15:01:50 -0700 Received: from SJEXCHCAS04.corp.ad.broadcom.com (10.16.203.10) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 17 Jul 2015 14:44:06 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS04.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Fri, 17 Jul 2015 14:44:06 -0700 From: "Chris (Christopher) Brand" To: "xen-users@lists.xen.org" Thread-Topic: ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQ== Date: Fri, 17 Jul 2015 21:44:06 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Subject: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi, I'm trying to reduce the memory footprint of Xen on my 2GB platform, and one place that seems like a good target is the xenheap, which defaults to 64MB, very little of which I've seen used so far. I found the command line xenheap_megabytes command-line option, and setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, which mentions that back in the days of Xen 3.3, xenheap defaulted to 16MB, which indicates that I'm not trying something totally ridiculous. Thanks, Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 22:57:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 22:57:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGEYa-00007A-F8; Fri, 17 Jul 2015 22:56:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGEYZ-00006y-FJ for xen-users@lists.xen.org; Fri, 17 Jul 2015 22:56:39 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id A0/8B-24055-62889A55; Fri, 17 Jul 2015 22:56:38 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-2.tower-206.messagelabs.com!1437173797!21964205!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26748 invoked from network); 17 Jul 2015 22:56:38 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-2.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 17 Jul 2015 22:56:38 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGEYX-0002HV-Af for xen-users@lists.xen.org; Sat, 18 Jul 2015 00:56:37 +0200 Date: Sat, 18 Jul 2015 00:56:37 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I have recently upgraded the xen system with the debian distro on my xen machine. So, in wheezy it has xen-4.1, and xm, and linux-3.2, now the versions are xen-4.4 with xl toolstack, and the linux kernel is 3.16. On wheezy I used a modified version of the network-bridge script, but after the upgrade I omit this procedure and modified /etc/network/interfaces: auto xenbr0 iface xenbr0 inet static address 122.66.33.251 netmask 255.255.255.0 gateway 122.66.33.254 bridge_ports eth0 auto xenbr1 iface xenbr1 inet static address 192.168.3.9 netmask 255.255.255.0 bridge_ports eth1 Thus, when I boot the xen machine, everything seems fine: # brctl show xenbr0 8000.0025908190d8 no eth0 xenbr1 8000.0025908190d9 no eth1 I can ping other hosts on both interfaces (bridges). however, when I create (start) the new domU with lines in xl_domU.cfg vif = [ 'mac=00:40:f6:54:79:0f, bridge=xenbr0', 'mac=00:16:3e:00:02:01, bridge=xenbr1' ] and "brctl show"s xenbr0 8000.0025908190d8 no eth0 vif5.0 xenbr1 8000.0025908190d9 no eth1 vif5.1 then eth0 @domU (aka vif5.0 @dom0) works but eth1 @domU (aka vif5.1 @dom0) does not... :-( I have also noticed in kern.log some lines like vif vif-5-0 vif5.0: Guest Rx ready IPv6: ADDRCONF(NETDEV_CHANGE): vif5.0: link becomes ready xenbr0: port 2(vif5.0) entered forwarding state but any similar for vif-5-1 ... What can be the problem? -- Zsolt PS: maybe I will try the old method with network-bridge script.. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 17 22:57:53 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 17 Jul 2015 22:57:53 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGEYa-00007A-F8; Fri, 17 Jul 2015 22:56:40 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGEYZ-00006y-FJ for xen-users@lists.xen.org; Fri, 17 Jul 2015 22:56:39 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id A0/8B-24055-62889A55; Fri, 17 Jul 2015 22:56:38 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-2.tower-206.messagelabs.com!1437173797!21964205!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26748 invoked from network); 17 Jul 2015 22:56:38 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-2.tower-206.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 17 Jul 2015 22:56:38 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGEYX-0002HV-Af for xen-users@lists.xen.org; Sat, 18 Jul 2015 00:56:37 +0200 Date: Sat, 18 Jul 2015 00:56:37 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org Message-ID: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I have recently upgraded the xen system with the debian distro on my xen machine. So, in wheezy it has xen-4.1, and xm, and linux-3.2, now the versions are xen-4.4 with xl toolstack, and the linux kernel is 3.16. On wheezy I used a modified version of the network-bridge script, but after the upgrade I omit this procedure and modified /etc/network/interfaces: auto xenbr0 iface xenbr0 inet static address 122.66.33.251 netmask 255.255.255.0 gateway 122.66.33.254 bridge_ports eth0 auto xenbr1 iface xenbr1 inet static address 192.168.3.9 netmask 255.255.255.0 bridge_ports eth1 Thus, when I boot the xen machine, everything seems fine: # brctl show xenbr0 8000.0025908190d8 no eth0 xenbr1 8000.0025908190d9 no eth1 I can ping other hosts on both interfaces (bridges). however, when I create (start) the new domU with lines in xl_domU.cfg vif = [ 'mac=00:40:f6:54:79:0f, bridge=xenbr0', 'mac=00:16:3e:00:02:01, bridge=xenbr1' ] and "brctl show"s xenbr0 8000.0025908190d8 no eth0 vif5.0 xenbr1 8000.0025908190d9 no eth1 vif5.1 then eth0 @domU (aka vif5.0 @dom0) works but eth1 @domU (aka vif5.1 @dom0) does not... :-( I have also noticed in kern.log some lines like vif vif-5-0 vif5.0: Guest Rx ready IPv6: ADDRCONF(NETDEV_CHANGE): vif5.0: link becomes ready xenbr0: port 2(vif5.0) entered forwarding state but any similar for vif-5-1 ... What can be the problem? -- Zsolt PS: maybe I will try the old method with network-bridge script.. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 07:34:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 07:34:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGMcg-0000hJ-CI; Sat, 18 Jul 2015 07:33:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGMce-0000hE-Ui for xen-users@lists.xen.org; Sat, 18 Jul 2015 07:33:25 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 53/F3-31650-4410AA55; Sat, 18 Jul 2015 07:33:24 +0000 X-Env-Sender: prvs=63428e0ac=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1437204802!33174206!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25722 invoked from network); 18 Jul 2015 07:33:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2015 07:33:23 -0000 X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="scan'208";a="285349999" Message-ID: <1437204798.7019.165.camel@citrix.com> From: Ian Campbell To: SZABO Zsolt Date: Sat, 18 Jul 2015 08:33:18 +0100 In-Reply-To: References: Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: [...] > What can be the problem? Nothing in the configuration you describe stands out to me as being wrong. Do you have eth1 configured within the guest? What does the in-guest config and state look like? Did you upgrade the guest too or just dom0? Some versions of xl were fussy about spaces within the vif descriptions (like the one before the "bridge=" in yours). Since your eth0 works I doubt this is the issue you are seeing, but I suppose it is worth removing them just in case. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 07:34:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 07:34:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGMcg-0000hJ-CI; Sat, 18 Jul 2015 07:33:26 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGMce-0000hE-Ui for xen-users@lists.xen.org; Sat, 18 Jul 2015 07:33:25 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 53/F3-31650-4410AA55; Sat, 18 Jul 2015 07:33:24 +0000 X-Env-Sender: prvs=63428e0ac=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1437204802!33174206!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25722 invoked from network); 18 Jul 2015 07:33:23 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2015 07:33:23 -0000 X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="scan'208";a="285349999" Message-ID: <1437204798.7019.165.camel@citrix.com> From: Ian Campbell To: SZABO Zsolt Date: Sat, 18 Jul 2015 08:33:18 +0100 In-Reply-To: References: Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: [...] > What can be the problem? Nothing in the configuration you describe stands out to me as being wrong. Do you have eth1 configured within the guest? What does the in-guest config and state look like? Did you upgrade the guest too or just dom0? Some versions of xl were fussy about spaces within the vif descriptions (like the one before the "bridge=" in yours). Since your eth0 works I doubt this is the issue you are seeing, but I suppose it is worth removing them just in case. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 09:08:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 09:08:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGO5Q-0004Vl-Vl; Sat, 18 Jul 2015 09:07:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGO5O-0004Vg-Qk for xen-users@lists.xen.org; Sat, 18 Jul 2015 09:07:10 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 9A/71-03035-E371AA55; Sat, 18 Jul 2015 09:07:10 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-7.tower-31.messagelabs.com!1437210428!27010823!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23159 invoked from network); 18 Jul 2015 09:07:08 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-7.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 09:07:08 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGO5M-0006qx-2r for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:07:08 +0200 Date: Sat, 18 Jul 2015 11:07:08 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: <1437204798.7019.165.camel@citrix.com> Message-ID: References: <1437204798.7019.165.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, Ian Campbell wrote: > On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: > [...] >> What can be the problem? > > Nothing in the configuration you describe stands out to me as being > wrong. > > Do you have eth1 configured within the guest? What does the in-guest > config and state look like? Originally, both eth0 and eth1 in domU was configured by dhcp but now it only works for eth0, thus, I configure eth1 static: auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet static address 192.168.3.2 network 255.255.255.0 broadcast 192.168.3.255 I have also checked dmesg in the guest: # dmesg |grep -i net [ 0.033297] Initializing cgroup subsys net_cls [ 0.033330] Initializing cgroup subsys net_prio [ 0.118117] NET: Registered protocol family 16 [ 0.208776] NET: Registered protocol family 2 [ 0.212141] NET: Registered protocol family 1 [ 0.301223] audit: initializing netlink subsys (disabled) [ 1.376536] NET: Registered protocol family 10 [ 1.377181] NET: Registered protocol family 17 [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver [ 1.601085] xen_netfront: can't alloc rx grant refs [ 1.601105] net eth1: only created 16 queues [ 9.095908] FS-Cache: Netfs 'nfs' registered for caching > Did you upgrade the guest too or just dom0? I have also upgraded the guest to jessie... > Some versions of xl were fussy about spaces within the vif descriptions > (like the one before the "bridge=" in yours). Since your eth0 works I > doubt this is the issue you are seeing, but I suppose it is worth > removing them just in case. I have tried, nothing improved. :-( [...] Ok, I have another linux domU but with wheezy. Originally, only eth0 was configured, but now I have also tried to add eth1 similarly as to the jessie domU and it works... The dmesg of this domU is shorter: # dmesg |grep net [ 0.004000] Initializing cgroup subsys net_cls [ 0.004000] Initializing cgroup subsys net_prio [ 0.134434] microcode: Microcode Update Driver: v2.00 , Peter Oruba [ 0.134838] audit: initializing netlink subsys (disabled) [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver Maybe the jessie upgrade missed some feature of the later upgraded dom0? Or it is about some kind of other conflict...? TIA, -- Zs _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 09:08:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 09:08:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGO5Q-0004Vl-Vl; Sat, 18 Jul 2015 09:07:12 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGO5O-0004Vg-Qk for xen-users@lists.xen.org; Sat, 18 Jul 2015 09:07:10 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id 9A/71-03035-E371AA55; Sat, 18 Jul 2015 09:07:10 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-7.tower-31.messagelabs.com!1437210428!27010823!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23159 invoked from network); 18 Jul 2015 09:07:08 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-7.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 09:07:08 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGO5M-0006qx-2r for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:07:08 +0200 Date: Sat, 18 Jul 2015 11:07:08 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: <1437204798.7019.165.camel@citrix.com> Message-ID: References: <1437204798.7019.165.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, Ian Campbell wrote: > On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: > [...] >> What can be the problem? > > Nothing in the configuration you describe stands out to me as being > wrong. > > Do you have eth1 configured within the guest? What does the in-guest > config and state look like? Originally, both eth0 and eth1 in domU was configured by dhcp but now it only works for eth0, thus, I configure eth1 static: auto eth0 iface eth0 inet dhcp auto eth1 iface eth1 inet static address 192.168.3.2 network 255.255.255.0 broadcast 192.168.3.255 I have also checked dmesg in the guest: # dmesg |grep -i net [ 0.033297] Initializing cgroup subsys net_cls [ 0.033330] Initializing cgroup subsys net_prio [ 0.118117] NET: Registered protocol family 16 [ 0.208776] NET: Registered protocol family 2 [ 0.212141] NET: Registered protocol family 1 [ 0.301223] audit: initializing netlink subsys (disabled) [ 1.376536] NET: Registered protocol family 10 [ 1.377181] NET: Registered protocol family 17 [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver [ 1.601085] xen_netfront: can't alloc rx grant refs [ 1.601105] net eth1: only created 16 queues [ 9.095908] FS-Cache: Netfs 'nfs' registered for caching > Did you upgrade the guest too or just dom0? I have also upgraded the guest to jessie... > Some versions of xl were fussy about spaces within the vif descriptions > (like the one before the "bridge=" in yours). Since your eth0 works I > doubt this is the issue you are seeing, but I suppose it is worth > removing them just in case. I have tried, nothing improved. :-( [...] Ok, I have another linux domU but with wheezy. Originally, only eth0 was configured, but now I have also tried to add eth1 similarly as to the jessie domU and it works... The dmesg of this domU is shorter: # dmesg |grep net [ 0.004000] Initializing cgroup subsys net_cls [ 0.004000] Initializing cgroup subsys net_prio [ 0.134434] microcode: Microcode Update Driver: v2.00 , Peter Oruba [ 0.134838] audit: initializing netlink subsys (disabled) [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver Maybe the jessie upgrade missed some feature of the later upgraded dom0? Or it is about some kind of other conflict...? TIA, -- Zs _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 09:37:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 09:37:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGOYR-0005Rq-Le; Sat, 18 Jul 2015 09:37:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGOYQ-0005Rl-Fx for xen-users@lists.xen.org; Sat, 18 Jul 2015 09:37:10 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id FB/B2-18947-54E1AA55; Sat, 18 Jul 2015 09:37:09 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-7.tower-27.messagelabs.com!1437212226!33150115!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8070 invoked from network); 18 Jul 2015 09:37:06 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 09:37:06 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGOYM-0007eI-4w for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:37:06 +0200 Date: Sat, 18 Jul 2015 11:37:06 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: Message-ID: References: <1437204798.7019.165.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, SZABO Zsolt wrote: >> Did you upgrade the guest too or just dom0? > > I have also upgraded the guest to jessie... Maybe I forgot something about the "history": 0. I had xen-4.1 on wheezy (dom0), and a squeeze domU 1. I upgraded domU to wheezy and later to jessie (the domU is the server of an LTSP clients on the local LTSP network i.e. eth1, and it worked; from outside I can access the domU through eth0 and it worked, too; however, the kernel was 3.2) 2. then I decided to upgrade the wheezy dom0 to jessie too and then upload the 3.16 kernel modules to the domU(s) (and modified the xl.pvexample script accordingly): name = "linserver" kernel = "/boot/vmlinuz-3.16.0-4-amd64" ramdisk = "/boot/initrd.img-3.16.0-4-amd64" extra = "root=/dev/xvda2 ro" memory = 20480 vcpus = 16 vif = [ 'mac=00:40:f6:54:79:0f,bridge=xenbr0', 'mac=00:16:3e:00:02:01,bridge=xenbr1' ] disk = [ '/dev/xcp/linsrv_7,raw,xvda2,rw', '/dev/swp/linsrv_swap,raw,xvda1,rw', '/dev/xcp/linsrv_tmp,raw,xvda3,rw', '/dev/xcp/linsrv_opt,raw,xvdb1,rw', '/dev/xcp/linsrv_home,raw,xvdb2,rw', ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' The mentioned other wheezy domU (acting as license server, see below) runs also with kernel 3.16 (from the /boot of dom0) > Ok, I have another linux domU but with wheezy. Originally, only eth0 was > configured, but now I have also tried to add eth1 similarly as to > the jessie domU and it works... > > The dmesg of this domU is shorter: > # dmesg |grep net > [ 0.004000] Initializing cgroup subsys net_cls > [ 0.004000] Initializing cgroup subsys net_prio > [ 0.134434] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 0.134838] audit: initializing netlink subsys (disabled) > [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver > > Maybe the jessie upgrade missed some feature of the later upgraded dom0? > Or it is about some kind of other conflict...? -- Zs _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 09:37:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 09:37:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGOYR-0005Rq-Le; Sat, 18 Jul 2015 09:37:11 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGOYQ-0005Rl-Fx for xen-users@lists.xen.org; Sat, 18 Jul 2015 09:37:10 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id FB/B2-18947-54E1AA55; Sat, 18 Jul 2015 09:37:09 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-7.tower-27.messagelabs.com!1437212226!33150115!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8070 invoked from network); 18 Jul 2015 09:37:06 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-7.tower-27.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 09:37:06 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGOYM-0007eI-4w for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:37:06 +0200 Date: Sat, 18 Jul 2015 11:37:06 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: Message-ID: References: <1437204798.7019.165.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, SZABO Zsolt wrote: >> Did you upgrade the guest too or just dom0? > > I have also upgraded the guest to jessie... Maybe I forgot something about the "history": 0. I had xen-4.1 on wheezy (dom0), and a squeeze domU 1. I upgraded domU to wheezy and later to jessie (the domU is the server of an LTSP clients on the local LTSP network i.e. eth1, and it worked; from outside I can access the domU through eth0 and it worked, too; however, the kernel was 3.2) 2. then I decided to upgrade the wheezy dom0 to jessie too and then upload the 3.16 kernel modules to the domU(s) (and modified the xl.pvexample script accordingly): name = "linserver" kernel = "/boot/vmlinuz-3.16.0-4-amd64" ramdisk = "/boot/initrd.img-3.16.0-4-amd64" extra = "root=/dev/xvda2 ro" memory = 20480 vcpus = 16 vif = [ 'mac=00:40:f6:54:79:0f,bridge=xenbr0', 'mac=00:16:3e:00:02:01,bridge=xenbr1' ] disk = [ '/dev/xcp/linsrv_7,raw,xvda2,rw', '/dev/swp/linsrv_swap,raw,xvda1,rw', '/dev/xcp/linsrv_tmp,raw,xvda3,rw', '/dev/xcp/linsrv_opt,raw,xvdb1,rw', '/dev/xcp/linsrv_home,raw,xvdb2,rw', ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' The mentioned other wheezy domU (acting as license server, see below) runs also with kernel 3.16 (from the /boot of dom0) > Ok, I have another linux domU but with wheezy. Originally, only eth0 was > configured, but now I have also tried to add eth1 similarly as to > the jessie domU and it works... > > The dmesg of this domU is shorter: > # dmesg |grep net > [ 0.004000] Initializing cgroup subsys net_cls > [ 0.004000] Initializing cgroup subsys net_prio > [ 0.134434] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 0.134838] audit: initializing netlink subsys (disabled) > [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver > > Maybe the jessie upgrade missed some feature of the later upgraded dom0? > Or it is about some kind of other conflict...? -- Zs _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 11:02:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 11:02:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGPsW-0007x7-Am; Sat, 18 Jul 2015 11:02:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGPsU-0007x2-BP for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:01:58 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 11/45-04112-5223AA55; Sat, 18 Jul 2015 11:01:57 +0000 X-Env-Sender: prvs=63428e0ac=Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1437217315!19147846!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23503 invoked from network); 18 Jul 2015 11:01:56 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2015 11:01:56 -0000 X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="scan'208";a="282238622" Message-ID: <1437217307.7019.169.camel@citrix.com> From: Ian Campbell To: SZABO Zsolt Date: Sat, 18 Jul 2015 12:01:47 +0100 In-Reply-To: References: <1437204798.7019.165.camel@citrix.com> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-18 at 11:07 +0200, SZABO Zsolt wrote: > On Sat, 18 Jul 2015, Ian Campbell wrote: > > > On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: > > [...] > >> What can be the problem? > > > > Nothing in the configuration you describe stands out to me as being > > wrong. > > > > Do you have eth1 configured within the guest? What does the in-guest > > config and state look like? > > Originally, both eth0 and eth1 in domU was configured by dhcp > but now it only works for eth0, thus, I configure eth1 static: > > auto eth0 > iface eth0 inet dhcp > > auto eth1 > iface eth1 inet static > address 192.168.3.2 > network 255.255.255.0 > broadcast 192.168.3.255 > > I have also checked dmesg in the guest: > # dmesg |grep -i net > [ 0.033297] Initializing cgroup subsys net_cls > [ 0.033330] Initializing cgroup subsys net_prio > [ 0.118117] NET: Registered protocol family 16 > [ 0.208776] NET: Registered protocol family 2 > [ 0.212141] NET: Registered protocol family 1 > [ 0.301223] audit: initializing netlink subsys (disabled) > [ 1.376536] NET: Registered protocol family 10 > [ 1.377181] NET: Registered protocol family 17 > [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver > [ 1.601085] xen_netfront: can't alloc rx grant refs This is strange, and I would bet related to your problem. > [ 1.601105] net eth1: only created 16 queues and this is maybe related too. I'm afraid I've run out of time to investigate for the weekend, but I'll see what I can figure out next week. In the meantime off the top of my head in addition to googling those messages it might be worth investigating options for extending the number of grant entries which a guest is allowed to use and perhaps whether multiqueue networking can be disabled (therefore reducing the need for grant entries). > [ 9.095908] FS-Cache: Netfs 'nfs' registered for caching > > > > Did you upgrade the guest too or just dom0? > > I have also upgraded the guest to jessie... > > > Some versions of xl were fussy about spaces within the vif descriptions > > (like the one before the "bridge=" in yours). Since your eth0 works I > > doubt this is the issue you are seeing, but I suppose it is worth > > removing them just in case. > > I have tried, nothing improved. :-( > [...] > > Ok, I have another linux domU but with wheezy. Originally, only eth0 was > configured, but now I have also tried to add eth1 similarly as to > the jessie domU and it works... Good to know. > The dmesg of this domU is shorter: > # dmesg |grep net > [ 0.004000] Initializing cgroup subsys net_cls > [ 0.004000] Initializing cgroup subsys net_prio > [ 0.134434] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 0.134838] audit: initializing netlink subsys (disabled) > [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver > > Maybe the jessie upgrade missed some feature of the later upgraded dom0? > Or it is about some kind of other conflict...? I think a new feature of the Jessie kernel(s) is running up against some resource limit when two NICs are used. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 11:02:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 11:02:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGPsW-0007x7-Am; Sat, 18 Jul 2015 11:02:00 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGPsU-0007x2-BP for xen-users@lists.xen.org; Sat, 18 Jul 2015 11:01:58 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 11/45-04112-5223AA55; Sat, 18 Jul 2015 11:01:57 +0000 X-Env-Sender: prvs=63428e0ac=Ian.Campbell@citrix.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1437217315!19147846!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23503 invoked from network); 18 Jul 2015 11:01:56 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 18 Jul 2015 11:01:56 -0000 X-IronPort-AV: E=Sophos;i="5.15,499,1432598400"; d="scan'208";a="282238622" Message-ID: <1437217307.7019.169.camel@citrix.com> From: Ian Campbell To: SZABO Zsolt Date: Sat, 18 Jul 2015 12:01:47 +0100 In-Reply-To: References: <1437204798.7019.165.camel@citrix.com> Organization: Citrix X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-18 at 11:07 +0200, SZABO Zsolt wrote: > On Sat, 18 Jul 2015, Ian Campbell wrote: > > > On Sat, 2015-07-18 at 00:56 +0200, SZABO Zsolt wrote: > > [...] > >> What can be the problem? > > > > Nothing in the configuration you describe stands out to me as being > > wrong. > > > > Do you have eth1 configured within the guest? What does the in-guest > > config and state look like? > > Originally, both eth0 and eth1 in domU was configured by dhcp > but now it only works for eth0, thus, I configure eth1 static: > > auto eth0 > iface eth0 inet dhcp > > auto eth1 > iface eth1 inet static > address 192.168.3.2 > network 255.255.255.0 > broadcast 192.168.3.255 > > I have also checked dmesg in the guest: > # dmesg |grep -i net > [ 0.033297] Initializing cgroup subsys net_cls > [ 0.033330] Initializing cgroup subsys net_prio > [ 0.118117] NET: Registered protocol family 16 > [ 0.208776] NET: Registered protocol family 2 > [ 0.212141] NET: Registered protocol family 1 > [ 0.301223] audit: initializing netlink subsys (disabled) > [ 1.376536] NET: Registered protocol family 10 > [ 1.377181] NET: Registered protocol family 17 > [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver > [ 1.601085] xen_netfront: can't alloc rx grant refs This is strange, and I would bet related to your problem. > [ 1.601105] net eth1: only created 16 queues and this is maybe related too. I'm afraid I've run out of time to investigate for the weekend, but I'll see what I can figure out next week. In the meantime off the top of my head in addition to googling those messages it might be worth investigating options for extending the number of grant entries which a guest is allowed to use and perhaps whether multiqueue networking can be disabled (therefore reducing the need for grant entries). > [ 9.095908] FS-Cache: Netfs 'nfs' registered for caching > > > > Did you upgrade the guest too or just dom0? > > I have also upgraded the guest to jessie... > > > Some versions of xl were fussy about spaces within the vif descriptions > > (like the one before the "bridge=" in yours). Since your eth0 works I > > doubt this is the issue you are seeing, but I suppose it is worth > > removing them just in case. > > I have tried, nothing improved. :-( > [...] > > Ok, I have another linux domU but with wheezy. Originally, only eth0 was > configured, but now I have also tried to add eth1 similarly as to > the jessie domU and it works... Good to know. > The dmesg of this domU is shorter: > # dmesg |grep net > [ 0.004000] Initializing cgroup subsys net_cls > [ 0.004000] Initializing cgroup subsys net_prio > [ 0.134434] microcode: Microcode Update Driver: v2.00 > , Peter Oruba > [ 0.134838] audit: initializing netlink subsys (disabled) > [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver > > Maybe the jessie upgrade missed some feature of the later upgraded dom0? > Or it is about some kind of other conflict...? I think a new feature of the Jessie kernel(s) is running up against some resource limit when two NICs are used. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 17:01:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 17:01:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGVTT-0008H4-1X; Sat, 18 Jul 2015 17:00:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGVTR-0008Gz-6Z for xen-users@lists.xen.org; Sat, 18 Jul 2015 17:00:29 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id E9/9E-03035-C268AA55; Sat, 18 Jul 2015 17:00:28 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-12.tower-31.messagelabs.com!1437238827!27004860!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5026 invoked from network); 18 Jul 2015 17:00:27 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 17:00:27 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGVTO-0006vf-UY for xen-users@lists.xen.org; Sat, 18 Jul 2015 19:00:27 +0200 Date: Sat, 18 Jul 2015 19:00:26 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: <1437217307.7019.169.camel@citrix.com> Message-ID: References: <1437204798.7019.165.camel@citrix.com> <1437217307.7019.169.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, Ian Campbell wrote: > On Sat, 2015-07-18 at 11:07 +0200, SZABO Zsolt wrote: >> [...] >> I have also checked dmesg in the guest: >> # dmesg |grep -i net >> [ 0.033297] Initializing cgroup subsys net_cls >> [ 0.033330] Initializing cgroup subsys net_prio >> [ 0.118117] NET: Registered protocol family 16 >> [ 0.208776] NET: Registered protocol family 2 >> [ 0.212141] NET: Registered protocol family 1 >> [ 0.301223] audit: initializing netlink subsys (disabled) >> [ 1.376536] NET: Registered protocol family 10 >> [ 1.377181] NET: Registered protocol family 17 >> [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver >> [ 1.601085] xen_netfront: can't alloc rx grant refs > > This is strange, and I would bet related to your problem. > >> [ 1.601105] net eth1: only created 16 queues > > and this is maybe related too. > > I'm afraid I've run out of time to investigate for the weekend, but I'll > see what I can figure out next week. > > In the meantime off the top of my head in addition to googling those > messages it might be worth investigating options for extending the > number of grant entries which a guest is allowed to use and perhaps > whether multiqueue networking can be disabled (therefore reducing the > need for grant entries). Hmm.. I have no idea how to do that... :-) >> Ok, I have another linux domU but with wheezy. Originally, only eth0 was >> configured, but now I have also tried to add eth1 similarly as to >> the jessie domU and it works... >> The dmesg of this domU is shorter: >> # dmesg |grep net >> [ 0.004000] Initializing cgroup subsys net_cls >> [ 0.004000] Initializing cgroup subsys net_prio >> [ 0.134838] audit: initializing netlink subsys (disabled) >> [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver >> >> Maybe the jessie upgrade missed some feature of the later upgraded dom0? >> Or it is about some kind of other conflict...? > > I think a new feature of the Jessie kernel(s) is running up against some > resource limit when two NICs are used. And one more report, with some summary[1-3]: [1]Finally I have also tried to start the jessie domU with kernel 3.2.0: $ uname -a Linux linserver 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux (still from wheezy) ... and it WORKS! # dmesg |grep -i 'net\|eth' [ 0.040200] Initializing cgroup subsys net_cls [ 0.089581] NET: Registered protocol family 16 [ 0.202444] NET: Registered protocol family 2 [ 0.215637] NET: Registered protocol family 1 [ 0.287638] audit: initializing netlink socket (disabled) [ 1.366956] NET: Registered protocol family 10 [ 1.367898] NET: Registered protocol family 17 [ 1.368263] Initializing network drop monitor service [ 1.435843] Initialising Xen virtual ethernet driver. [ 18.854461] FS-Cache: Netfs 'nfs' registered for caching [ 25.868039] eth0: no IPv6 routers present [ 27.740048] eth1: no IPv6 routers present [2]So, the TWO vif in a wheezy domU with linux-3.16.0 work too; # uname -a Linux wheezy 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux (the part of dmesg related to net|eth can be seen above) [3]But the 2nd vif in a jessie domU with linux-3.16.0 does NOT, and it is possibly related to the dmesg lines * xen_netfront: can't alloc rx grant refs * net eth1: only created 16 queues Now, I run the jessie+3.2.0 domU and I will see how stable it is... -- Zsolt _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 18 17:01:46 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 18 Jul 2015 17:01:46 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGVTT-0008H4-1X; Sat, 18 Jul 2015 17:00:31 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZGVTR-0008Gz-6Z for xen-users@lists.xen.org; Sat, 18 Jul 2015 17:00:29 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id E9/9E-03035-C268AA55; Sat, 18 Jul 2015 17:00:28 +0000 X-Env-Sender: szazs@mm.bme.hu X-Msg-Ref: server-12.tower-31.messagelabs.com!1437238827!27004860!1 X-Originating-IP: [152.66.33.80] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5026 invoked from network); 18 Jul 2015 17:00:27 -0000 Received: from galilei.mm.bme.hu (HELO galilei.mm.bme.hu) (152.66.33.80) by server-12.tower-31.messagelabs.com with DHE-RSA-AES128-SHA encrypted SMTP; 18 Jul 2015 17:00:27 -0000 Received: from szazs (helo=localhost) by galilei.mm.bme.hu with local-esmtp (Exim 4.80) (envelope-from ) id 1ZGVTO-0006vf-UY for xen-users@lists.xen.org; Sat, 18 Jul 2015 19:00:27 +0200 Date: Sat, 18 Jul 2015 19:00:26 +0200 (CEST) From: SZABO Zsolt To: xen-users@lists.xen.org In-Reply-To: <1437217307.7019.169.camel@citrix.com> Message-ID: References: <1437204798.7019.165.camel@citrix.com> <1437217307.7019.169.camel@citrix.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Subject: Re: [Xen-users] domU with two eth but only one is active X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 18 Jul 2015, Ian Campbell wrote: > On Sat, 2015-07-18 at 11:07 +0200, SZABO Zsolt wrote: >> [...] >> I have also checked dmesg in the guest: >> # dmesg |grep -i net >> [ 0.033297] Initializing cgroup subsys net_cls >> [ 0.033330] Initializing cgroup subsys net_prio >> [ 0.118117] NET: Registered protocol family 16 >> [ 0.208776] NET: Registered protocol family 2 >> [ 0.212141] NET: Registered protocol family 1 >> [ 0.301223] audit: initializing netlink subsys (disabled) >> [ 1.376536] NET: Registered protocol family 10 >> [ 1.377181] NET: Registered protocol family 17 >> [ 1.472973] xen_netfront: Initialising Xen virtual ethernet driver >> [ 1.601085] xen_netfront: can't alloc rx grant refs > > This is strange, and I would bet related to your problem. > >> [ 1.601105] net eth1: only created 16 queues > > and this is maybe related too. > > I'm afraid I've run out of time to investigate for the weekend, but I'll > see what I can figure out next week. > > In the meantime off the top of my head in addition to googling those > messages it might be worth investigating options for extending the > number of grant entries which a guest is allowed to use and perhaps > whether multiqueue networking can be disabled (therefore reducing the > need for grant entries). Hmm.. I have no idea how to do that... :-) >> Ok, I have another linux domU but with wheezy. Originally, only eth0 was >> configured, but now I have also tried to add eth1 similarly as to >> the jessie domU and it works... >> The dmesg of this domU is shorter: >> # dmesg |grep net >> [ 0.004000] Initializing cgroup subsys net_cls >> [ 0.004000] Initializing cgroup subsys net_prio >> [ 0.134838] audit: initializing netlink subsys (disabled) >> [ 1.340978] xen_netfront: Initialising Xen virtual ethernet driver >> >> Maybe the jessie upgrade missed some feature of the later upgraded dom0? >> Or it is about some kind of other conflict...? > > I think a new feature of the Jessie kernel(s) is running up against some > resource limit when two NICs are used. And one more report, with some summary[1-3]: [1]Finally I have also tried to start the jessie domU with kernel 3.2.0: $ uname -a Linux linserver 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u2 x86_64 GNU/Linux (still from wheezy) ... and it WORKS! # dmesg |grep -i 'net\|eth' [ 0.040200] Initializing cgroup subsys net_cls [ 0.089581] NET: Registered protocol family 16 [ 0.202444] NET: Registered protocol family 2 [ 0.215637] NET: Registered protocol family 1 [ 0.287638] audit: initializing netlink socket (disabled) [ 1.366956] NET: Registered protocol family 10 [ 1.367898] NET: Registered protocol family 17 [ 1.368263] Initializing network drop monitor service [ 1.435843] Initialising Xen virtual ethernet driver. [ 18.854461] FS-Cache: Netfs 'nfs' registered for caching [ 25.868039] eth0: no IPv6 routers present [ 27.740048] eth1: no IPv6 routers present [2]So, the TWO vif in a wheezy domU with linux-3.16.0 work too; # uname -a Linux wheezy 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24) x86_64 GNU/Linux (the part of dmesg related to net|eth can be seen above) [3]But the 2nd vif in a jessie domU with linux-3.16.0 does NOT, and it is possibly related to the dmesg lines * xen_netfront: can't alloc rx grant refs * net eth1: only created 16 queues Now, I run the jessie+3.2.0 domU and I will see how stable it is... -- Zsolt _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 11:23:38 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 11:23:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH99K-0000Dc-Nc; Mon, 20 Jul 2015 11:22:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH99J-0000DX-LA for xen-users@lists.xen.org; Mon, 20 Jul 2015 11:22:21 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id FB/67-19948-DE9DCA55; Mon, 20 Jul 2015 11:22:21 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1437391339!18952768!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2478 invoked from network); 20 Jul 2015 11:22:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 11:22:20 -0000 X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="285653514" Message-ID: <1437391204.7427.7.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Mon, 20 Jul 2015 12:20:04 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 21:44 +0000, Chris (Christopher) Brand wrote: > Hi, > > I'm trying to reduce the memory footprint of Xen on my 2GB platform, > and one place that seems like a good target is the xenheap, which > defaults to 64MB, very little of which I've seen used so far. I found > the command line xenheap_megabytes command-line option, and > setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. > I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, > which mentions that back in the days of Xen 3.3, xenheap defaulted > to 16MB, which indicates that I'm not trying something totally > ridiculous. That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 11:23:38 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 11:23:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH99K-0000Dc-Nc; Mon, 20 Jul 2015 11:22:22 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH99J-0000DX-LA for xen-users@lists.xen.org; Mon, 20 Jul 2015 11:22:21 +0000 Received: from [85.158.139.211] by server-3.bemta-5.messagelabs.com id FB/67-19948-DE9DCA55; Mon, 20 Jul 2015 11:22:21 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1437391339!18952768!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2478 invoked from network); 20 Jul 2015 11:22:20 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-15.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 11:22:20 -0000 X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="285653514" Message-ID: <1437391204.7427.7.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Mon, 20 Jul 2015 12:20:04 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 21:44 +0000, Chris (Christopher) Brand wrote: > Hi, > > I'm trying to reduce the memory footprint of Xen on my 2GB platform, > and one place that seems like a good target is the xenheap, which > defaults to 64MB, very little of which I've seen used so far. I found > the command line xenheap_megabytes command-line option, and > setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. > I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, > which mentions that back in the days of Xen 3.3, xenheap defaulted > to 16MB, which indicates that I'm not trying something totally > ridiculous. That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 11:55:11 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 11:55:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH9e7-00029L-7V; Mon, 20 Jul 2015 11:54:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH9e5-00029B-RP for xen-users@lists.xen.org; Mon, 20 Jul 2015 11:54:09 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 91/1C-01068-161ECA55; Mon, 20 Jul 2015 11:54:09 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1437393246!27463139!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30214 invoked from network); 20 Jul 2015 11:54:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 11:54:08 -0000 X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="282512950" Message-ID: <1437393238.12274.5.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Mon, 20 Jul 2015 12:53:58 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 21:44 +0000, Chris (Christopher) Brand wrote: > Hi, > > I'm trying to reduce the memory footprint of Xen on my 2GB platform, > and one place that seems like a good target is the xenheap, which > defaults to 64MB, very little of which I've seen used so far. I found > the command line xenheap_megabytes command-line option, and > setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. > I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, > which mentions that back in the days of Xen 3.3, xenheap defaulted > to 16MB, which indicates that I'm not trying something totally > ridiculous. That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 11:55:11 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 11:55:11 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH9e7-00029L-7V; Mon, 20 Jul 2015 11:54:11 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZH9e5-00029B-RP for xen-users@lists.xen.org; Mon, 20 Jul 2015 11:54:09 +0000 Received: from [85.158.137.68] by server-16.bemta-3.messagelabs.com id 91/1C-01068-161ECA55; Mon, 20 Jul 2015 11:54:09 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-11.tower-31.messagelabs.com!1437393246!27463139!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30214 invoked from network); 20 Jul 2015 11:54:08 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-11.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 11:54:08 -0000 X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="282512950" Message-ID: <1437393238.12274.5.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Mon, 20 Jul 2015 12:53:58 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-17 at 21:44 +0000, Chris (Christopher) Brand wrote: > Hi, > > I'm trying to reduce the memory footprint of Xen on my 2GB platform, > and one place that seems like a good target is the xenheap, which > defaults to 64MB, very little of which I've seen used so far. I found > the command line xenheap_megabytes command-line option, and > setting that to 32 helps, but if I set it to less than 32, Xen doesn't boot. > I found http://www.poppelgaard.com/adjusting-dom0-and-xenheap-settings-in-xenserver, > which mentions that back in the days of Xen 3.3, xenheap defaulted > to 16MB, which indicates that I'm not trying something totally > ridiculous. That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 14:24:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 14:24:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHByF-0004xa-N2; Mon, 20 Jul 2015 14:23:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHByE-0004x4-Ba for xen-users@lists.xen.org; Mon, 20 Jul 2015 14:23:06 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 25/2B-06190-9440DA55; Mon, 20 Jul 2015 14:23:05 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1437402182!22343758!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32247 invoked from network); 20 Jul 2015 14:23:04 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 14:23:04 -0000 X-IronPort-AV: E=Sophos;i="5.15,508,1432598400"; d="scan'208";a="282563279" Message-ID: <1437402151.17368.34.camel@citrix.com> From: Ian Campbell To: John Paul Walters Date: Mon, 20 Jul 2015 15:22:31 +0100 In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi John, Ah, this rings a bell actually, I think this may have been the place I got to last year before I gave up as the firmware was too buggy (PXE broken, frequent decent into Synchronous Abort exception storms) to allow for sensible development. I started looking for some up to date firmware last week in response to your asking about Juno and had great difficulty finding modern bits which even booted UEFI, let alone Xen. I've been pointed to some bits which should work but still no PXE. I've mailed the Juno support folks at ARM to see what they advise. In the meantime I'll try and find some time to dig in without PXE and hope the other issues are improved enough that I don't just get fed up again. I'm sorry the news isn't better. Ian. On Fri, 2015-07-17 at 16:59 -0400, John Paul Walters wrote: > I've made some progress by rolling back to an earlier firmware and > kernel version. It looks like I'm now able to fully boot Xen along > with all 6 cores and Dom0 starts booting. Now, on waiting for the > root device to become available, USB enumeration fails. Since Juno > relies on USB for the root disk, this prevents booting. I've > confirmed that the same kernel boots fine outside of Xen. The boot > messages in question are, with the full boot log below: > > [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb > [ 1.659215] usb 1-1: device descriptor read/64, error -32 > [ 1.889213] usb 1-1: device descriptor read/64, error -32 > [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb > [ 2.239213] usb 1-1: device descriptor read/64, error -32 > [ 2.469249] usb 1-1: device descriptor read/64, error -32 > [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb > [ 3.119197] usb 1-1: device not accepting address 4, error -32 > [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb > [ 3.659181] usb 1-1: device not accepting address 5, error -32 > [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 > > So I have a couple of questions. Has anyone run into this USB issue > before? If not, can someone point me to the firmware/kernel versions > that were known to successfully boot Xen on the Juno board? > > > ARM V2M-Juno Boot loader v1.0.0 > HBI0262 build 1156 > > ARM V2M_Juno Firmware v1.2.7 > Build Date: Oct 3 2014 > > Time : 17:23:54 > Date : 17:07:2015 > > Cmd> > Powering up system... > > Switching on ATXPSU... > PMIC RAM configuration (pms_v103.bin)... > MBtemp : 37 degC > > Configuring motherboard (rev B, var B)... > IOFPGA image \MB\HBI0262B\io_b115.bit > IOFPGA config: PASSED > OSC CLK config: PASSED > > Configuring SCC registers... > Writing SCC 0x00000054 with 0x0007FFFE > Writing SCC 0x0000005C with 0x00FE001E > Writing SCC 0x00000100 with 0x003F1000 > Writing SCC 0x00000104 with 0x0001F300 > Writing SCC 0x00000108 with 0x00371000 > Writing SCC 0x0000010C with 0x0001B300 > Writing SCC 0x00000118 with 0x003F1000 > Writing SCC 0x0000011C with 0x0001F100 > Writing SCC 0x000000F8 with 0x0BEC0000 > Writing SCC 0x0000000C with 0x000000C2 > Writing SCC 0x00000010 with 0x000000C2 > > Peripheral ID0:0x000000AD > Peripheral ID1:0x000000B0 > Peripheral ID2:0x0000000B > Peripheral ID3:0x00000000 > Peripheral ID4:0x0000000D > Peripheral ID5:0x000000F0 > Peripheral ID6:0x00000005 > Peripheral ID7:0x000000B1 > > Programming NOR Flash > PCIE clock configured... > > Testing motherboard interfaces (FPGA build 115)... > SRAM 32MB test: PASSED > LAN9118 test: PASSED > KMI1/2 test: PASSED > MMC test: PASSED > PB/LEDs test: PASSED > FPGA UART test: PASSED > PCIe init test: PASSED > MAC addrs test: PASSED > > Setting HDMI0 mode for SVGA. > Setting HDMI1 mode for SVGA. > > SoC SMB clock enabled. > > Testing SMB clock... > SMB clock running > Releasing system resets... > > UART0 set to SoC UART0 > UART1 set to SoC UART1 > > NOTICE: Booting Trusted Firmware > NOTICE: BL1: v1.0(release):14b6608 > NOTICE: BL1: Built : 14:15:51, Sep 1 2014 > NOTICE: BL1: Booting BL2 > NOTICE: BL2: v1.0(release):14b6608 > NOTICE: BL2: Built : 14:15:51, Sep 1 2014 > NOTICE: BL1: Booting BL3-1 > NOTICE: BL3-1: v1.0(release):14b6608 > NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014 > UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014) > 3h3h3h3h3h3hThe default boot selection will start in 10 > seconds^H^H^H^H^H^H^H^H^H^H^H 9 seconds > [1] Linux from NOR Flash > [2] Debian ARMv8 > [3] KVM > [4] Xen from NOR Flash > [5] Shell > [6] Boot Manager > Start: 5 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.40 (ARM Juno EFI Oct 23 2014 14:42:29, 0x00000000) > Mapping table > FS2: Alias(s):F10:;BLK1: > VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > FS0: Alias(s):F3: > MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > FS1: Alias(s):F4: > MemoryMapped(0xB,0xFEBEE000,0xFEDDC0BF) > BLK0: Alias(s): > VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > Press ESC in 5 seconds to skip startup.nsh or any other key to > continue.Press ESC in 4 seconds to skip startup.nsh or any other key > to continue.Press ESC in 3 seconds to skip startup.nsh or any other > key to continue.Press ESC in 2 seconds to skip startup.nsh or any > other key to continue.Press ESC in 1 seconds to skip startup.nsh or > any other key to continue. > Shell> fs2: > FS2:\> xen -cfg=cfg > 3hXen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader > juno.dtb: 0x00000009fac99000-0x00000009fac9bfc9 > Image: 0x00000009fa27b000-0x00000009fac938a8 > - UART enabled - > - CPU 00000100 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 0000000080000000 - 00000000dfffffff > (XEN) RAM: 00000000e00f0000 - 00000000febd1fff > (XEN) RAM: 00000000febd9000 - 00000000feffffff > (XEN) RAM: 0000000880000000 - 00000009fa27afff > (XEN) RAM: 00000009fac99000 - 00000009fac9afff > (XEN) RAM: 00000009fae8c000 - 00000009faf6efff > (XEN) RAM: 00000009fafaa000 - 00000009fec2cfff > (XEN) RAM: 00000009fec2d000 - 00000009ff1bbfff > (XEN) RAM: 00000009ff1bc000 - 00000009ff1c1fff > (XEN) RAM: 00000009ff1c2000 - 00000009ffb73fff > (XEN) RAM: 00000009ffb74000 - 00000009ffb77fff > (XEN) RAM: 00000009ffb78000 - 00000009ffdddfff > (XEN) RAM: 00000009ffdde000 - 00000009ffe75fff > (XEN) RAM: 00000009ffe76000 - 00000009fff6dfff > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > (XEN) > (XEN) MODULE[0]: 00000009fac94000 - 00000009fac99000 Device Tree > (XEN) MODULE[1]: 00000009fa27b000 - 00000009fac938a8 Kernel > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > (XEN) > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > (XEN) Update BOOTMOD_XEN from 00000009fac9e000-00000009fada8d81 => > 00000000dfe00000-00000000dff0ad81 > (XEN) PFN compression on bits 21...22 > (XEN) Domain heap initialised > (XEN) Looking for UART console serial0 > Xen 4.5-unstable > (XEN) Xen version 4.5-unstable (root@cambridge.arm.com) (gcc > (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 21:18:51 UTC 2015 > (XEN) Latest ChangeSet: Mon Oct 20 20:55:25 2014 -0700 git:91086d0 > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Platform: VERSATILE EXPRESS > (XEN) Using PSCI-0.1 for SMP bringup > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 64 KiB. > (XEN) Bringing up CPU1 > - CPU 00000101 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 1 booted. > (XEN) Bringing up CPU2 > - CPU 00000102 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 2 booted. > (XEN) Bringing up CPU3 > - CPU 00000103 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 3 booted. > (XEN) Bringing up CPU4 > - CPU 00000000 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 4 booted. > (XEN) Bringing up CPU5 > - CPU 00000001 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 5 booted. > (XEN) Brought up 6 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa27b000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa27b000 to 00000000d0080000-00000000d0a988a8 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e02954 > (XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs > (XEN) ...........done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 288kB init memory. > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Initializing cgroup subsys cpuacct > [ 0.000000] Linux version 3.15.0-rc8JP+ (root@arm64) (gcc version > 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Thu Jul 16 16:54:26 > UTC 2015 > [ 0.000000] CPU: AArch64 Processor [410fd030] revision 0 > [ 0.000000] cma: CMA: reserved 32 MiB at d5c00000 > [ 0.000000] psci: probing function IDs from device-tree > [ 0.000000] PERCPU: Embedded 12 pages/cpu @ffffffc007fa2000 s19200 > r8192 d21760 u49152 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. > Total pages: 32256 > [ 0.000000] Kernel command line: console=hvc0 > earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > [ 0.000000] PID hash table entries: 512 (order: 0, 4096 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > [ 0.000000] Memory: 70524K/131072K available (6641K kernel code, > 582K rwdata, 2588K rodata, 518K init, 460K bss, 60548K reserved) > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 > (245759 MB) > [ 0.000000] vmemmap : 0xffffffbc03400000 - 0xffffffbc03600000 > ( 2 MB) > [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 > ( 64 MB) > [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc008000000 > ( 128 MB) > [ 0.000000] .init : 0xffffffc000985000 - 0xffffffc000a06b00 > ( 519 kB) > [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc0009847a4 > ( 9234 kB) > [ 0.000000] .data : 0xffffffc000a07000 - 0xffffffc000a988a8 > ( 583 kB) > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 > [ 0.000000] Preemptible hierarchical RCU implementation. > [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=6. > [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6 > [ 0.000000] NR_IRQS:64 nr_irqs:64 0 > [ 0.000000] Architected cp15 and mmio timer(s) running at 50.00MHz > (virt/phys). > [ 0.000005] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps > every 2748779069440ns > [ 0.000227] Console: colour dummy device 80x25 > [ 0.001265] allocated 4194304 bytes of page_cgroup > [ 0.001273] please try 'cgroup_disable=memory' option if you don't > want memory cgroups > [ 0.001287] Calibrating delay loop (skipped), value calculated > using timer frequency.. 100.00 BogoMIPS (lpj=500000) > [ 0.001300] pid_max: default: 32768 minimum: 301 > [ 0.001423] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > [ 0.001435] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) > [ 0.002055] Initializing cgroup subsys debug > [ 0.002070] Initializing cgroup subsys memory > [ 0.002090] Initializing cgroup subsys devices > [ 0.002100] Initializing cgroup subsys freezer > [ 0.002109] Initializing cgroup subsys blkio > [ 0.002118] Initializing cgroup subsys perf_event > [ 0.002149] ftrace: allocating 23435 entries in 92 pages > [ 0.053959] /cpus/cpu@0: Missing clock-frequency property > [ 0.053995] /cpus/cpu@1: Missing clock-frequency property > [ 0.054024] /cpus/cpu@2: Missing clock-frequency property > [ 0.054055] /cpus/cpu@3: Missing clock-frequency property > [ 0.054089] /cpus/cpu@4: Missing clock-frequency property > [ 0.054126] /cpus/cpu@5: Missing clock-frequency property > [ 0.054152] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, > 1 counters available > [ 0.054262] Xen 4.5 support found, events_irq=31 > gnttab_frame=0x00000000b0000000 > [ 0.054387] xen:grant_table: Grant tables using version 1 layout > [ 0.054430] Grant table initialized > [ 0.054474] xen:events: Using FIFO-based ABI > [ 0.054496] Xen: initializing cpu0 > [ 0.114225] CPU1: Booted secondary processor > [ 0.114282] Xen: initializing cpu1 > [ 0.134271] CPU2: Booted secondary processor > [ 0.134320] Xen: initializing cpu2 > [ 0.154303] CPU3: Booted secondary processor > [ 0.154351] Xen: initializing cpu3 > [ 0.174372] CPU4: Booted secondary processor > [ 0.174429] Xen: initializing cpu4 > [ 0.194398] CPU5: Booted secondary processor > [ 0.194446] Xen: initializing cpu5 > [ 0.194634] Brought up 6 CPUs > [ 0.194684] SMP: Total of 6 processors activated. > [ 0.195818] devtmpfs: initialized > [ 0.213972] sched: registering cpufreq notifiers for scale-invariant loads > [ 0.215643] atomic64 test passed > [ 0.216195] regulator-dummy: no parameters > [ 0.221431] NET: Registered protocol family 16 > [ 0.222781] vdso: 2 pages (1 code, 1 data) at base ffffffc000a0d000 > [ 0.222862] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. > [ 0.224599] software IO TLB [mem 0xd3c00000-0xd4000000] (4MB) > mapped at [ffffffc003c00000-ffffffc003ffffff] > [ 0.226178] DMA: preallocated 256 KiB pool for atomic allocations > [ 0.227769] software IO TLB [mem 0xd3800000-0xd3c00000] (4MB) > mapped at [ffffffc003800000-ffffffc003bfffff] > [ 0.227843] Serial: AMBA PL011 UART driver > [ 0.252564] xen:balloon: Initialising balloon driver > [ 0.252950] xen_balloon: Initialising balloon driver > [ 0.253666] 3V3: 3300 mV > [ 0.254396] SCSI subsystem initialized > [ 0.255136] usbcore: registered new interface driver usbfs > [ 0.255236] usbcore: registered new interface driver hub > [ 0.255429] usbcore: registered new device driver usb > [ 0.258155] Advanced Linux Sound Architecture Driver Initialized. > [ 0.259140] Switched to clocksource arch_sys_counter > [ 0.326068] NET: Registered protocol family 2 > [ 0.326688] TCP established hash table entries: 1024 (order: 1, 8192 bytes) > [ 0.326729] TCP bind hash table entries: 1024 (order: 2, 16384 bytes) > [ 0.326768] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.326839] TCP: reno registered > [ 0.326854] UDP hash table entries: 256 (order: 1, 8192 bytes) > [ 0.326886] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) > [ 0.327134] NET: Registered protocol family 1 > [ 0.327663] RPC: Registered named UNIX socket transport module. > [ 0.327673] RPC: Registered udp transport module. > [ 0.327681] RPC: Registered tcp transport module. > [ 0.327689] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 0.328296] kvm [1]: HYP mode not available > [ 0.330205] futex hash table entries: 2048 (order: 5, 131072 bytes) > [ 0.331333] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 0.353140] NFS: Registering the id_resolver key type > [ 0.353184] Key type id_resolver registered > [ 0.353196] Key type id_legacy registered > [ 0.353221] nfs4filelayout_init: NFSv4 File Layout Driver Registering... > [ 0.353543] fuse init (API version 7.23) > [ 0.354641] msgmni has been set to 201 > [ 0.356566] io scheduler noop registered > [ 0.356876] io scheduler cfq registered (default) > [ 0.359006] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330 > [ 0.359025] dma-pl330 7ff00000.dma: DBUFF-1024x16bytes Num_Chans-8 > Num_Peri-8 Num_Events-8 > [ 0.360142] xen:xen_evtchn: Event-channel device installed > [ 1.002919] console [hvc0] enabled > [ 1.006436] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > [ 1.015155] [drm] Initialized drm 1.1.0 20060810 > [ 1.032004] brd: module loaded > [ 1.041132] loop: module loaded > [ 1.046906] libphy: smsc911x-mdio: probed > [ 1.129307] smsc911x 18000000.ethernet eth0: attached PHY driver > [Generic PHY] (mii_bus:phy_addr=18000000.etherne:01, irq=-1) > [ 1.140762] smsc911x 18000000.ethernet eth0: MAC Address: 00:02:f7:00:59:cd > [ 1.147699] xen_netfront: Initialising Xen virtual ethernet driver > [ 1.153991] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 1.160562] ehci-h20ahb: H20AHB-EHCI Host Controller driver > [ 1.166347] ehci-h20ahb 7ffc0000.ehci: EHCI Host Controller > [ 1.171886] ehci-h20ahb 7ffc0000.ehci: new USB bus registered, > assigned bus number 1 > [ 1.179917] ehci-h20ahb 7ffc0000.ehci: irq 149, io mem 0x7ffc0000 > [ 1.185935] ehci-h20ahb 7ffc0000.ehci: enabled 64bit DMA > [ 1.209177] ehci-h20ahb 7ffc0000.ehci: USB 2.0 started, EHCI 1.00 > [ 1.216518] hub 1-0:1.0: USB hub found > [ 1.220247] hub 1-0:1.0: 1 port detected > [ 1.224761] ULPI transceiver vendor/product ID 0x0424/0x0009 > [ 1.230360] Found SMSC USB334x ULPI transceiver. > [ 1.235041] ULPI integrity check: passed. > [ 1.239369] usbcore: registered new interface driver usb-storage > [ 1.245623] mousedev: PS/2 mouse device common for all mice > [ 1.252106] rtc-pl031 1c170000.rtc: rtc core: registered pl031 as rtc0 > [ 1.258629] i2c /dev entries driver > [ 1.263461] usbcore: registered new interface driver usbhid > [ 1.268954] usbhid: USB HID core driver > [ 1.277165] ion_chunk_heap_create: base 3535798272 size 4194304 align 16384 > [ 1.285299] ashmem: initialized > [ 1.288713] logger: created 256K log 'log_main' > [ 1.293548] logger: created 256K log 'log_events' > [ 1.298515] logger: created 256K log 'log_radio' > [ 1.303445] logger: created 256K log 'log_system' > [ 1.308667] Channel(mhu_ctlr:cpu_to_scp_low) not found! > [ 1.313854] scpi_clocks clocks.2: failed to register clock 'vbig' > [ 1.320050] platform clocks.2: Driver scpi_clocks requests probe deferral > [ 1.327117] mhu_ctlr_drv 2b1f0000.mhu: registered mailbox controller mhu_ctlr > [ 1.337090] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.344453] ERROR: could not get clock /i2s@7ff90000:i2sclk(0) > [ 1.350253] platform 7ff90000.i2s: Driver designware-i2s requests > probe deferral > [ 1.357954] ip_tables: (C) 2000-2006 Netfilter Core Team > [ 1.363833] arp_tables: (C) 2002 David S. Miller > [ 1.368503] TCP: cubic registered > [ 1.372857] NET: Registered protocol family 10 > [ 1.378750] mip6: Mobile IPv6 > [ 1.381690] ip6_tables: (C) 2000-2006 Netfilter Core Team > [ 1.387754] sit: IPv6 over IPv4 tunneling driver > [ 1.393221] NET: Registered protocol family 17 > [ 1.397704] Key type dns_resolver registered > [ 1.489370] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.496743] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.504023] rtc-pl031 1c170000.rtc: setting system clock to > 2015-07-17 17:24:37 UTC (1437153877) > [ 1.514005] ALSA device list: > [ 1.516898] No soundcards found. > [ 1.520950] Waiting for root device /dev/sda3... > [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb > [ 1.659215] usb 1-1: device descriptor read/64, error -32 > [ 1.889213] usb 1-1: device descriptor read/64, error -32 > [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb > [ 2.239213] usb 1-1: device descriptor read/64, error -32 > [ 2.469249] usb 1-1: device descriptor read/64, error -32 > [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb > [ 3.119197] usb 1-1: device not accepting address 4, error -32 > [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb > [ 3.659181] usb 1-1: device not accepting address 5, error -32 > [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 > > On Wed, Jul 15, 2015 at 4:41 PM, John Paul Walters wrote: > > I've included the output of building xen with debug=y and > > CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional > > CPUs aren't coming up, but I noticed an error message early in the Xen > > output: > > > > (XEN) Error: PSCI version 0x10000 is not supported. > > > > Then the dom0 kernel appears to crash inside of some PSCI initialization: > > > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: [] psci_init+0x2c/0x40 > > (XEN) DOM0: [] setup_arch+0x420/0x5ac > > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > > > Any suggestions would be welcome. > > > > thanks, > > JP > > > > FS2:\> xen -cfg=cfg > > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader > > junoX: 0x00000009faf87000-0x00000009faf89b89 > > ImageX: 0x00000009fa3be000-0x00000009fabf7000 > > - UART enabled - > > - CPU 00000100 booting - > > - Current EL 00000008 - > > - Xen starting at EL2 - > > - Zero BSS - > > - Setting up control registers - > > - Turning on paging - > > - Ready - > > (XEN) Checking for initrd in /chosen > > (XEN) RAM: 0000000080000000 - 00000000dfffffff > > (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff > > (XEN) RAM: 00000000feba0000 - 00000000febabfff > > (XEN) RAM: 00000000febac000 - 00000000feffffff > > (XEN) RAM: 0000000880000000 - 00000009fa3bdfff > > (XEN) RAM: 00000009fade9000 - 00000009faecffff > > (XEN) RAM: 00000009faf80000 - 00000009faf82fff > > (XEN) RAM: 00000009faf87000 - 00000009faf8afff > > (XEN) RAM: 00000009faf8c000 - 00000009febe3fff > > (XEN) RAM: 00000009febe4000 - 00000009ff142fff > > (XEN) RAM: 00000009ff143000 - 00000009ff144fff > > (XEN) RAM: 00000009ff145000 - 00000009ff16dfff > > (XEN) RAM: 00000009ff16e000 - 00000009ff170fff > > (XEN) RAM: 00000009ff171000 - 00000009ffdbffff > > (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff > > (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff > > (XEN) RAM: 00000009fff90000 - 00000009fff9ffff > > (XEN) RAM: 00000009ffff0000 - 00000009ffffefff > > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > > (XEN) > > (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree > > (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel > > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > > (XEN) > > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > > (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => > > 00000000dfe00000-00000000dff0ad81 > > (XEN) PFN compression on bits 21...22 > > (XEN) Domain heap initialised > > (XEN) Looking for UART console serial0 > > Xen 4.5.1 > > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > > 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 > > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty > > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > > (XEN) 64-bit Execution: > > (XEN) Processor Features: 0000000000002222 0000000000000000 > > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > > (XEN) Extensions: FloatingPoint AdvancedSIMD > > (XEN) Debug Features: 0000000010305106 0000000000000000 > > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > > (XEN) ISA Features: 0000000000011120 0000000000000000 > > (XEN) 32-bit Execution: > > (XEN) Processor Features: 00000131:00011011 > > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > > (XEN) Extensions: GenericTimer Security > > (XEN) Debug Features: 03010066 > > (XEN) Auxiliary Features: 00000000 > > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > > (XEN) Platform: VERSATILE EXPRESS > > (XEN) Error: PSCI version 0x10000 is not supported. > > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > > (XEN) Using generic timer at 50000 KHz > > (XEN) GICv2 initialization: > > (XEN) gic_dist_addr=000000002c010000 > > (XEN) gic_cpu_addr=000000002c02f000 > > (XEN) gic_hyp_addr=000000002c04f000 > > (XEN) gic_vcpu_addr=000000002c06f000 > > (XEN) gic_maintenance_irq=25 > > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) I/O virtualisation disabled > > (XEN) Allocated console ring of 64 KiB. > > (XEN) Bringing up CPU1 > > (XEN) Failed to bring up CPU1 > > (XEN) Failed to bring up CPU 1 (error -1) > > (XEN) Bringing up CPU2 > > (XEN) Failed to bring up CPU2 > > (XEN) Failed to bring up CPU 2 (error -1) > > (XEN) Bringing up CPU3 > > (XEN) Failed to bring up CPU3 > > (XEN) Failed to bring up CPU 3 (error -1) > > (XEN) Bringing up CPU4 > > (XEN) Failed to bring up CPU4 > > (XEN) Failed to bring up CPU 4 (error -1) > > (XEN) Bringing up CPU5 > > (XEN) Failed to bring up CPU5 > > (XEN) Failed to bring up CPU 5 (error -1) > > (XEN) Brought up 1 CPUs > > (XEN) P2M: 40-bit IPA with 40-bit PA > > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Loading kernel from boot module @ 00000009fa3be000 > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > > (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 > > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > > (XEN) ................................................................done. > > (XEN) Initial low memory virq threshold set at 0x4000 pages. > > (XEN) Std. Loglevel: All > > (XEN) Guest Loglevel: All > > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > > input to Xen) > > (XEN) Freed 284kB init memory. > > (XEN) DOM0: Booting Linux on physical CPU 0x0 > > (XEN) DOM0: Initializing cgroup subsys cpu > > (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 > > (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 > > (XEN) DOM0: > > (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 > > (XEN) DOM0: Detected VIPT I-cache on CPU0 > > (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, > > 827319, 824069 > > (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') > > (XEN) DOM0: bootconsole [uart0] enabled > > (XEN) DOM0: efi: Getting EFI parameters from FDT: > > (XEN) DOM0: efi: UEFI not found. > > (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 > > (XEN) DOM0: psci: probing for conduit method from DT. > > (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 > > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > > (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > > (XEN) DOM0: Modules linked in: > > (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 > > (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) > > (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: > > ffffffc000860000 > > (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 > > (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 > > (XEN) DOM0: sp : ffffffc000863ee0 > > (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 > > (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 > > (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 > > (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 > > (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 > > (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 > > (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 > > (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff > > (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 > > (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 > > (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f > > (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 > > (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 > > (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 > > (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 > > (XEN) DOM0: > > (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) > > (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) > > (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 > > 00000000 008bc000 ffffffc0 > > (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 > > ffffffc0 00817874 ffffffc0 > > (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 > > ffffffc0 00815670 ffffffc0 > > (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 > > ffffffc0 00866000 ffffffc0 > > (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 > > 00000000 d08f0000 00000000 > > (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 > > 00000000 64667467 ff616b73 > > (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 > > 00000000 00000e11 00000000 > > (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 > > 00000000 d0000000 00000000 > > (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 > > 00000000 00000000 00000000 > > (XEN) DOM0: Call trace: > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: [] psci_init+0x2c/0x40 > > (XEN) DOM0: [] setup_arch+0x420/0x5ac > > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > > (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- > > (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! > > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the > > idle task! > > > > On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters > > wrote: > >> Hi Ian, > >> > >>> > >>> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra > >>> info. It would also be useful to see your file "cfg", in particular the > >>> various command lines which it will contain. > >>> > >> I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but > >> to answer your other questions, my cfg file: > >> > >> [global] > >> default=default > >> > >> [default] > >> options=console=dtuart dtuart=serial0 conswitch=x > >> kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait > >> root=/dev/sda3 > >> dtb=junoX > >> > >> I copied that from the link I referenced earlier, I believe. The only > >> differences are that I differentiated my default kernel and dtb from > >> the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My > >> root device is indeed /dev/sda3. > >> > >> > >> > >>> I take it your dom0 kernel binary boot successfully with all CPUs > >>> natively? > >> > >> Yes, my dom0 kernel boots all CPUs successfully. I didn't really > >> exercise them, but I can see all six of them. > >> > >>> > >>>> > >>>> thanks, > >>>> JP > >>>> > >> > >> > >> > >> > >> > >>>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) > >>>> [1] Linux from NOR Flash > >>>> [2] Debian ARMv8 > >>>> [3] KVM > >>>> [4] Xen from NOR Flash > >>>> [5] Shell > >>>> [6] Boot Manager > >>>> Start: 5 > >>>> UEFI Interactive Shell v2.1 > >>>> EDK II > >>>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) > >>>> Mapping table > >>>> FS2: Alias(s):F10:;BLK1: > >>>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > >>>> FS0: Alias(s):F3: > >>>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > >>>> FS1: Alias(s):F4: > >>>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) > >>>> BLK0: Alias(s): > >>>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > >>>> Shell> fs2: > >>>> FS2:\> xen -cfg=cfg > >>>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader > >>>> junoX: 0x00000009faf87000-0x00000009faf89b89 > >>>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 > >>>> Xen 4.5.1 > >>>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > >>>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 > >>>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 > >>>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > >>>> (XEN) 64-bit Execution: > >>>> (XEN) Processor Features: 0000000000002222 0000000000000000 > >>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > >>>> (XEN) Extensions: FloatingPoint AdvancedSIMD > >>>> (XEN) Debug Features: 0000000010305106 0000000000000000 > >>>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > >>>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 > >>>> (XEN) ISA Features: 0000000000011120 0000000000000000 > >>>> (XEN) 32-bit Execution: > >>>> (XEN) Processor Features: 00000131:00011011 > >>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > >>>> (XEN) Extensions: GenericTimer Security > >>>> (XEN) Debug Features: 03010066 > >>>> (XEN) Auxiliary Features: 00000000 > >>>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > >>>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > >>>> (XEN) Error: PSCI version 0x10000 is not supported. > >>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > >>>> (XEN) Using generic timer at 50000 KHz > >>>> (XEN) GICv2 initialization: > >>>> (XEN) gic_dist_addr=000000002c010000 > >>>> (XEN) gic_cpu_addr=000000002c02f000 > >>>> (XEN) gic_hyp_addr=000000002c04f000 > >>>> (XEN) gic_vcpu_addr=000000002c06f000 > >>>> (XEN) gic_maintenance_irq=25 > >>>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > >>>> (XEN) Using scheduler: SMP Credit Scheduler (credit) > >>>> (XEN) I/O virtualisation disabled > >>>> (XEN) Allocated console ring of 16 KiB. > >>>> (XEN) Bringing up CPU1 > >>>> (XEN) Failed to bring up CPU1 > >>>> (XEN) Failed to bring up CPU 1 (error -1) > >>>> (XEN) Bringing up CPU2 > >>>> (XEN) Failed to bring up CPU2 > >>>> (XEN) Failed to bring up CPU 2 (error -1) > >>>> (XEN) Bringing up CPU3 > >>>> (XEN) Failed to bring up CPU3 > >>>> (XEN) Failed to bring up CPU 3 (error -1) > >>>> (XEN) Bringing up CPU4 > >>>> (XEN) Failed to bring up CPU4 > >>>> (XEN) Failed to bring up CPU 4 (error -1) > >>>> (XEN) Bringing up CPU5 > >>>> (XEN) Failed to bring up CPU5 > >>>> (XEN) Failed to bring up CPU 5 (error -1) > >>>> (XEN) Brought up 1 CPUs > >>>> (XEN) P2M: 40-bit IPA with 40-bit PA > >>>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > >>>> (XEN) *** LOADING DOMAIN 0 *** > >>>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 > >>>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > >>>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > >>>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 > >>>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > >>>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > >>>> (XEN) ................................................................done. > >>>> (XEN) Initial low memory virq threshold set at 0x4000 pages. > >>>> (XEN) Std. Loglevel: Errors and warnings > >>>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > >>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > >>>> input to Xen) > >>>> (XEN) Freed 280kB init memory. > >>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch > >>>> input to DOM0) > >>>> > >>>> _______________________________________________ > >>>> Xen-users mailing list > >>>> Xen-users@lists.xen.org > >>>> http://lists.xen.org/xen-users > >>> > >>> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 14:24:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 14:24:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHByF-0004xa-N2; Mon, 20 Jul 2015 14:23:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHByE-0004x4-Ba for xen-users@lists.xen.org; Mon, 20 Jul 2015 14:23:06 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 25/2B-06190-9440DA55; Mon, 20 Jul 2015 14:23:05 +0000 X-Env-Sender: prvs=636bdd352=Ian.Campbell@citrix.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1437402182!22343758!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32247 invoked from network); 20 Jul 2015 14:23:04 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 20 Jul 2015 14:23:04 -0000 X-IronPort-AV: E=Sophos;i="5.15,508,1432598400"; d="scan'208";a="282563279" Message-ID: <1437402151.17368.34.camel@citrix.com> From: Ian Campbell To: John Paul Walters Date: Mon, 20 Jul 2015 15:22:31 +0100 In-Reply-To: References: <1436974518.32371.116.camel@citrix.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Booting Xen on ARM Juno r0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi John, Ah, this rings a bell actually, I think this may have been the place I got to last year before I gave up as the firmware was too buggy (PXE broken, frequent decent into Synchronous Abort exception storms) to allow for sensible development. I started looking for some up to date firmware last week in response to your asking about Juno and had great difficulty finding modern bits which even booted UEFI, let alone Xen. I've been pointed to some bits which should work but still no PXE. I've mailed the Juno support folks at ARM to see what they advise. In the meantime I'll try and find some time to dig in without PXE and hope the other issues are improved enough that I don't just get fed up again. I'm sorry the news isn't better. Ian. On Fri, 2015-07-17 at 16:59 -0400, John Paul Walters wrote: > I've made some progress by rolling back to an earlier firmware and > kernel version. It looks like I'm now able to fully boot Xen along > with all 6 cores and Dom0 starts booting. Now, on waiting for the > root device to become available, USB enumeration fails. Since Juno > relies on USB for the root disk, this prevents booting. I've > confirmed that the same kernel boots fine outside of Xen. The boot > messages in question are, with the full boot log below: > > [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb > [ 1.659215] usb 1-1: device descriptor read/64, error -32 > [ 1.889213] usb 1-1: device descriptor read/64, error -32 > [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb > [ 2.239213] usb 1-1: device descriptor read/64, error -32 > [ 2.469249] usb 1-1: device descriptor read/64, error -32 > [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb > [ 3.119197] usb 1-1: device not accepting address 4, error -32 > [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb > [ 3.659181] usb 1-1: device not accepting address 5, error -32 > [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 > > So I have a couple of questions. Has anyone run into this USB issue > before? If not, can someone point me to the firmware/kernel versions > that were known to successfully boot Xen on the Juno board? > > > ARM V2M-Juno Boot loader v1.0.0 > HBI0262 build 1156 > > ARM V2M_Juno Firmware v1.2.7 > Build Date: Oct 3 2014 > > Time : 17:23:54 > Date : 17:07:2015 > > Cmd> > Powering up system... > > Switching on ATXPSU... > PMIC RAM configuration (pms_v103.bin)... > MBtemp : 37 degC > > Configuring motherboard (rev B, var B)... > IOFPGA image \MB\HBI0262B\io_b115.bit > IOFPGA config: PASSED > OSC CLK config: PASSED > > Configuring SCC registers... > Writing SCC 0x00000054 with 0x0007FFFE > Writing SCC 0x0000005C with 0x00FE001E > Writing SCC 0x00000100 with 0x003F1000 > Writing SCC 0x00000104 with 0x0001F300 > Writing SCC 0x00000108 with 0x00371000 > Writing SCC 0x0000010C with 0x0001B300 > Writing SCC 0x00000118 with 0x003F1000 > Writing SCC 0x0000011C with 0x0001F100 > Writing SCC 0x000000F8 with 0x0BEC0000 > Writing SCC 0x0000000C with 0x000000C2 > Writing SCC 0x00000010 with 0x000000C2 > > Peripheral ID0:0x000000AD > Peripheral ID1:0x000000B0 > Peripheral ID2:0x0000000B > Peripheral ID3:0x00000000 > Peripheral ID4:0x0000000D > Peripheral ID5:0x000000F0 > Peripheral ID6:0x00000005 > Peripheral ID7:0x000000B1 > > Programming NOR Flash > PCIE clock configured... > > Testing motherboard interfaces (FPGA build 115)... > SRAM 32MB test: PASSED > LAN9118 test: PASSED > KMI1/2 test: PASSED > MMC test: PASSED > PB/LEDs test: PASSED > FPGA UART test: PASSED > PCIe init test: PASSED > MAC addrs test: PASSED > > Setting HDMI0 mode for SVGA. > Setting HDMI1 mode for SVGA. > > SoC SMB clock enabled. > > Testing SMB clock... > SMB clock running > Releasing system resets... > > UART0 set to SoC UART0 > UART1 set to SoC UART1 > > NOTICE: Booting Trusted Firmware > NOTICE: BL1: v1.0(release):14b6608 > NOTICE: BL1: Built : 14:15:51, Sep 1 2014 > NOTICE: BL1: Booting BL2 > NOTICE: BL2: v1.0(release):14b6608 > NOTICE: BL2: Built : 14:15:51, Sep 1 2014 > NOTICE: BL1: Booting BL3-1 > NOTICE: BL3-1: v1.0(release):14b6608 > NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014 > UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014) > 3h3h3h3h3h3hThe default boot selection will start in 10 > seconds^H^H^H^H^H^H^H^H^H^H^H 9 seconds > [1] Linux from NOR Flash > [2] Debian ARMv8 > [3] KVM > [4] Xen from NOR Flash > [5] Shell > [6] Boot Manager > Start: 5 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.40 (ARM Juno EFI Oct 23 2014 14:42:29, 0x00000000) > Mapping table > FS2: Alias(s):F10:;BLK1: > VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > FS0: Alias(s):F3: > MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > FS1: Alias(s):F4: > MemoryMapped(0xB,0xFEBEE000,0xFEDDC0BF) > BLK0: Alias(s): > VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > Press ESC in 5 seconds to skip startup.nsh or any other key to > continue.Press ESC in 4 seconds to skip startup.nsh or any other key > to continue.Press ESC in 3 seconds to skip startup.nsh or any other > key to continue.Press ESC in 2 seconds to skip startup.nsh or any > other key to continue.Press ESC in 1 seconds to skip startup.nsh or > any other key to continue. > Shell> fs2: > FS2:\> xen -cfg=cfg > 3hXen 4.5-unstable (c/s Mon Oct 20 20:55:25 2014 -0700 git:91086d0) EFI loader > juno.dtb: 0x00000009fac99000-0x00000009fac9bfc9 > Image: 0x00000009fa27b000-0x00000009fac938a8 > - UART enabled - > - CPU 00000100 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Zero BSS - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) Checking for initrd in /chosen > (XEN) RAM: 0000000080000000 - 00000000dfffffff > (XEN) RAM: 00000000e00f0000 - 00000000febd1fff > (XEN) RAM: 00000000febd9000 - 00000000feffffff > (XEN) RAM: 0000000880000000 - 00000009fa27afff > (XEN) RAM: 00000009fac99000 - 00000009fac9afff > (XEN) RAM: 00000009fae8c000 - 00000009faf6efff > (XEN) RAM: 00000009fafaa000 - 00000009fec2cfff > (XEN) RAM: 00000009fec2d000 - 00000009ff1bbfff > (XEN) RAM: 00000009ff1bc000 - 00000009ff1c1fff > (XEN) RAM: 00000009ff1c2000 - 00000009ffb73fff > (XEN) RAM: 00000009ffb74000 - 00000009ffb77fff > (XEN) RAM: 00000009ffb78000 - 00000009ffdddfff > (XEN) RAM: 00000009ffdde000 - 00000009ffe75fff > (XEN) RAM: 00000009ffe76000 - 00000009fff6dfff > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > (XEN) > (XEN) MODULE[0]: 00000009fac94000 - 00000009fac99000 Device Tree > (XEN) MODULE[1]: 00000009fa27b000 - 00000009fac938a8 Kernel > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > (XEN) > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > (XEN) Update BOOTMOD_XEN from 00000009fac9e000-00000009fada8d81 => > 00000000dfe00000-00000000dff0ad81 > (XEN) PFN compression on bits 21...22 > (XEN) Domain heap initialised > (XEN) Looking for UART console serial0 > Xen 4.5-unstable > (XEN) Xen version 4.5-unstable (root@cambridge.arm.com) (gcc > (Debian/Linaro 4.9.2-20) 4.9.2) debug=y Wed Jul 15 21:18:51 UTC 2015 > (XEN) Latest ChangeSet: Mon Oct 20 20:55:25 2014 -0700 git:91086d0 > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > (XEN) 64-bit Execution: > (XEN) Processor Features: 0000000000002222 0000000000000000 > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > (XEN) Extensions: FloatingPoint AdvancedSIMD > (XEN) Debug Features: 0000000010305106 0000000000000000 > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > (XEN) ISA Features: 0000000000011120 0000000000000000 > (XEN) 32-bit Execution: > (XEN) Processor Features: 00000131:00011011 > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > (XEN) Extensions: GenericTimer Security > (XEN) Debug Features: 03010066 > (XEN) Auxiliary Features: 00000000 > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > (XEN) Platform: VERSATILE EXPRESS > (XEN) Using PSCI-0.1 for SMP bringup > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > (XEN) Using generic timer at 50000 KHz > (XEN) GICv2 initialization: > (XEN) gic_dist_addr=000000002c010000 > (XEN) gic_cpu_addr=000000002c02f000 > (XEN) gic_hyp_addr=000000002c04f000 > (XEN) gic_vcpu_addr=000000002c06f000 > (XEN) gic_maintenance_irq=25 > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > (XEN) Using scheduler: SMP Credit Scheduler (credit) > (XEN) I/O virtualisation disabled > (XEN) Allocated console ring of 64 KiB. > (XEN) Bringing up CPU1 > - CPU 00000101 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 1 booted. > (XEN) Bringing up CPU2 > - CPU 00000102 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 2 booted. > (XEN) Bringing up CPU3 > - CPU 00000103 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 3 booted. > (XEN) Bringing up CPU4 > - CPU 00000000 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 4 booted. > (XEN) Bringing up CPU5 > - CPU 00000001 booting - > - Current EL 00000008 - > - Xen starting at EL2 - > - Setting up control registers - > - Turning on paging - > - Ready - > (XEN) CPU 5 booted. > (XEN) Brought up 6 CPUs > (XEN) P2M: 40-bit IPA with 40-bit PA > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > (XEN) *** LOADING DOMAIN 0 *** > (XEN) Loading kernel from boot module @ 00000009fa27b000 > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > (XEN) Loading zImage from 00000009fa27b000 to 00000000d0080000-00000000d0a988a8 > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e02954 > (XEN) Scrubbing Free RAM on 1 nodes using 6 CPUs > (XEN) ...........done. > (XEN) Initial low memory virq threshold set at 0x4000 pages. > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > input to Xen) > (XEN) Freed 288kB init memory. > [ 0.000000] Initializing cgroup subsys cpuset > [ 0.000000] Initializing cgroup subsys cpu > [ 0.000000] Initializing cgroup subsys cpuacct > [ 0.000000] Linux version 3.15.0-rc8JP+ (root@arm64) (gcc version > 4.9.2 (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Thu Jul 16 16:54:26 > UTC 2015 > [ 0.000000] CPU: AArch64 Processor [410fd030] revision 0 > [ 0.000000] cma: CMA: reserved 32 MiB at d5c00000 > [ 0.000000] psci: probing function IDs from device-tree > [ 0.000000] PERCPU: Embedded 12 pages/cpu @ffffffc007fa2000 s19200 > r8192 d21760 u49152 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. > Total pages: 32256 > [ 0.000000] Kernel command line: console=hvc0 > earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > [ 0.000000] PID hash table entries: 512 (order: 0, 4096 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > [ 0.000000] Memory: 70524K/131072K available (6641K kernel code, > 582K rwdata, 2588K rodata, 518K init, 460K bss, 60548K reserved) > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbbffff0000 > (245759 MB) > [ 0.000000] vmemmap : 0xffffffbc03400000 - 0xffffffbc03600000 > ( 2 MB) > [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 > ( 64 MB) > [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc008000000 > ( 128 MB) > [ 0.000000] .init : 0xffffffc000985000 - 0xffffffc000a06b00 > ( 519 kB) > [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc0009847a4 > ( 9234 kB) > [ 0.000000] .data : 0xffffffc000a07000 - 0xffffffc000a988a8 > ( 583 kB) > [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=6, Nodes=1 > [ 0.000000] Preemptible hierarchical RCU implementation. > [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=6. > [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6 > [ 0.000000] NR_IRQS:64 nr_irqs:64 0 > [ 0.000000] Architected cp15 and mmio timer(s) running at 50.00MHz > (virt/phys). > [ 0.000005] sched_clock: 56 bits at 50MHz, resolution 20ns, wraps > every 2748779069440ns > [ 0.000227] Console: colour dummy device 80x25 > [ 0.001265] allocated 4194304 bytes of page_cgroup > [ 0.001273] please try 'cgroup_disable=memory' option if you don't > want memory cgroups > [ 0.001287] Calibrating delay loop (skipped), value calculated > using timer frequency.. 100.00 BogoMIPS (lpj=500000) > [ 0.001300] pid_max: default: 32768 minimum: 301 > [ 0.001423] Mount-cache hash table entries: 512 (order: 0, 4096 bytes) > [ 0.001435] Mountpoint-cache hash table entries: 512 (order: 0, 4096 bytes) > [ 0.002055] Initializing cgroup subsys debug > [ 0.002070] Initializing cgroup subsys memory > [ 0.002090] Initializing cgroup subsys devices > [ 0.002100] Initializing cgroup subsys freezer > [ 0.002109] Initializing cgroup subsys blkio > [ 0.002118] Initializing cgroup subsys perf_event > [ 0.002149] ftrace: allocating 23435 entries in 92 pages > [ 0.053959] /cpus/cpu@0: Missing clock-frequency property > [ 0.053995] /cpus/cpu@1: Missing clock-frequency property > [ 0.054024] /cpus/cpu@2: Missing clock-frequency property > [ 0.054055] /cpus/cpu@3: Missing clock-frequency property > [ 0.054089] /cpus/cpu@4: Missing clock-frequency property > [ 0.054126] /cpus/cpu@5: Missing clock-frequency property > [ 0.054152] hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, > 1 counters available > [ 0.054262] Xen 4.5 support found, events_irq=31 > gnttab_frame=0x00000000b0000000 > [ 0.054387] xen:grant_table: Grant tables using version 1 layout > [ 0.054430] Grant table initialized > [ 0.054474] xen:events: Using FIFO-based ABI > [ 0.054496] Xen: initializing cpu0 > [ 0.114225] CPU1: Booted secondary processor > [ 0.114282] Xen: initializing cpu1 > [ 0.134271] CPU2: Booted secondary processor > [ 0.134320] Xen: initializing cpu2 > [ 0.154303] CPU3: Booted secondary processor > [ 0.154351] Xen: initializing cpu3 > [ 0.174372] CPU4: Booted secondary processor > [ 0.174429] Xen: initializing cpu4 > [ 0.194398] CPU5: Booted secondary processor > [ 0.194446] Xen: initializing cpu5 > [ 0.194634] Brought up 6 CPUs > [ 0.194684] SMP: Total of 6 processors activated. > [ 0.195818] devtmpfs: initialized > [ 0.213972] sched: registering cpufreq notifiers for scale-invariant loads > [ 0.215643] atomic64 test passed > [ 0.216195] regulator-dummy: no parameters > [ 0.221431] NET: Registered protocol family 16 > [ 0.222781] vdso: 2 pages (1 code, 1 data) at base ffffffc000a0d000 > [ 0.222862] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers. > [ 0.224599] software IO TLB [mem 0xd3c00000-0xd4000000] (4MB) > mapped at [ffffffc003c00000-ffffffc003ffffff] > [ 0.226178] DMA: preallocated 256 KiB pool for atomic allocations > [ 0.227769] software IO TLB [mem 0xd3800000-0xd3c00000] (4MB) > mapped at [ffffffc003800000-ffffffc003bfffff] > [ 0.227843] Serial: AMBA PL011 UART driver > [ 0.252564] xen:balloon: Initialising balloon driver > [ 0.252950] xen_balloon: Initialising balloon driver > [ 0.253666] 3V3: 3300 mV > [ 0.254396] SCSI subsystem initialized > [ 0.255136] usbcore: registered new interface driver usbfs > [ 0.255236] usbcore: registered new interface driver hub > [ 0.255429] usbcore: registered new device driver usb > [ 0.258155] Advanced Linux Sound Architecture Driver Initialized. > [ 0.259140] Switched to clocksource arch_sys_counter > [ 0.326068] NET: Registered protocol family 2 > [ 0.326688] TCP established hash table entries: 1024 (order: 1, 8192 bytes) > [ 0.326729] TCP bind hash table entries: 1024 (order: 2, 16384 bytes) > [ 0.326768] TCP: Hash tables configured (established 1024 bind 1024) > [ 0.326839] TCP: reno registered > [ 0.326854] UDP hash table entries: 256 (order: 1, 8192 bytes) > [ 0.326886] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes) > [ 0.327134] NET: Registered protocol family 1 > [ 0.327663] RPC: Registered named UNIX socket transport module. > [ 0.327673] RPC: Registered udp transport module. > [ 0.327681] RPC: Registered tcp transport module. > [ 0.327689] RPC: Registered tcp NFSv4.1 backchannel transport module. > [ 0.328296] kvm [1]: HYP mode not available > [ 0.330205] futex hash table entries: 2048 (order: 5, 131072 bytes) > [ 0.331333] HugeTLB registered 2 MB page size, pre-allocated 0 pages > [ 0.353140] NFS: Registering the id_resolver key type > [ 0.353184] Key type id_resolver registered > [ 0.353196] Key type id_legacy registered > [ 0.353221] nfs4filelayout_init: NFSv4 File Layout Driver Registering... > [ 0.353543] fuse init (API version 7.23) > [ 0.354641] msgmni has been set to 201 > [ 0.356566] io scheduler noop registered > [ 0.356876] io scheduler cfq registered (default) > [ 0.359006] dma-pl330 7ff00000.dma: Loaded driver for PL330 DMAC-341330 > [ 0.359025] dma-pl330 7ff00000.dma: DBUFF-1024x16bytes Num_Chans-8 > Num_Peri-8 Num_Events-8 > [ 0.360142] xen:xen_evtchn: Event-channel device installed > [ 1.002919] console [hvc0] enabled > [ 1.006436] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled > [ 1.015155] [drm] Initialized drm 1.1.0 20060810 > [ 1.032004] brd: module loaded > [ 1.041132] loop: module loaded > [ 1.046906] libphy: smsc911x-mdio: probed > [ 1.129307] smsc911x 18000000.ethernet eth0: attached PHY driver > [Generic PHY] (mii_bus:phy_addr=18000000.etherne:01, irq=-1) > [ 1.140762] smsc911x 18000000.ethernet eth0: MAC Address: 00:02:f7:00:59:cd > [ 1.147699] xen_netfront: Initialising Xen virtual ethernet driver > [ 1.153991] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > [ 1.160562] ehci-h20ahb: H20AHB-EHCI Host Controller driver > [ 1.166347] ehci-h20ahb 7ffc0000.ehci: EHCI Host Controller > [ 1.171886] ehci-h20ahb 7ffc0000.ehci: new USB bus registered, > assigned bus number 1 > [ 1.179917] ehci-h20ahb 7ffc0000.ehci: irq 149, io mem 0x7ffc0000 > [ 1.185935] ehci-h20ahb 7ffc0000.ehci: enabled 64bit DMA > [ 1.209177] ehci-h20ahb 7ffc0000.ehci: USB 2.0 started, EHCI 1.00 > [ 1.216518] hub 1-0:1.0: USB hub found > [ 1.220247] hub 1-0:1.0: 1 port detected > [ 1.224761] ULPI transceiver vendor/product ID 0x0424/0x0009 > [ 1.230360] Found SMSC USB334x ULPI transceiver. > [ 1.235041] ULPI integrity check: passed. > [ 1.239369] usbcore: registered new interface driver usb-storage > [ 1.245623] mousedev: PS/2 mouse device common for all mice > [ 1.252106] rtc-pl031 1c170000.rtc: rtc core: registered pl031 as rtc0 > [ 1.258629] i2c /dev entries driver > [ 1.263461] usbcore: registered new interface driver usbhid > [ 1.268954] usbhid: USB HID core driver > [ 1.277165] ion_chunk_heap_create: base 3535798272 size 4194304 align 16384 > [ 1.285299] ashmem: initialized > [ 1.288713] logger: created 256K log 'log_main' > [ 1.293548] logger: created 256K log 'log_events' > [ 1.298515] logger: created 256K log 'log_radio' > [ 1.303445] logger: created 256K log 'log_system' > [ 1.308667] Channel(mhu_ctlr:cpu_to_scp_low) not found! > [ 1.313854] scpi_clocks clocks.2: failed to register clock 'vbig' > [ 1.320050] platform clocks.2: Driver scpi_clocks requests probe deferral > [ 1.327117] mhu_ctlr_drv 2b1f0000.mhu: registered mailbox controller mhu_ctlr > [ 1.337090] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.344453] ERROR: could not get clock /i2s@7ff90000:i2sclk(0) > [ 1.350253] platform 7ff90000.i2s: Driver designware-i2s requests > probe deferral > [ 1.357954] ip_tables: (C) 2000-2006 Netfilter Core Team > [ 1.363833] arp_tables: (C) 2002 David S. Miller > [ 1.368503] TCP: cubic registered > [ 1.372857] NET: Registered protocol family 10 > [ 1.378750] mip6: Mobile IPv6 > [ 1.381690] ip6_tables: (C) 2000-2006 Netfilter Core Team > [ 1.387754] sit: IPv6 over IPv4 tunneling driver > [ 1.393221] NET: Registered protocol family 17 > [ 1.397704] Key type dns_resolver registered > [ 1.489370] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.496743] platform sound.14: Driver asoc-simple-card requests > probe deferral > [ 1.504023] rtc-pl031 1c170000.rtc: setting system clock to > 2015-07-17 17:24:37 UTC (1437153877) > [ 1.514005] ALSA device list: > [ 1.516898] No soundcards found. > [ 1.520950] Waiting for root device /dev/sda3... > [ 1.539278] usb 1-1: new high-speed USB device number 2 using ehci-h20ahb > [ 1.659215] usb 1-1: device descriptor read/64, error -32 > [ 1.889213] usb 1-1: device descriptor read/64, error -32 > [ 2.119216] usb 1-1: new high-speed USB device number 3 using ehci-h20ahb > [ 2.239213] usb 1-1: device descriptor read/64, error -32 > [ 2.469249] usb 1-1: device descriptor read/64, error -32 > [ 2.699252] usb 1-1: new high-speed USB device number 4 using ehci-h20ahb > [ 3.119197] usb 1-1: device not accepting address 4, error -32 > [ 3.239219] usb 1-1: new high-speed USB device number 5 using ehci-h20ahb > [ 3.659181] usb 1-1: device not accepting address 5, error -32 > [ 3.664987] hub 1-0:1.0: unable to enumerate USB device on port 1 > > On Wed, Jul 15, 2015 at 4:41 PM, John Paul Walters wrote: > > I've included the output of building xen with debug=y and > > CONFIG_EARLY_PRINTK=juno. It's not obvious to me why the additional > > CPUs aren't coming up, but I noticed an error message early in the Xen > > output: > > > > (XEN) Error: PSCI version 0x10000 is not supported. > > > > Then the dom0 kernel appears to crash inside of some PSCI initialization: > > > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: [] psci_init+0x2c/0x40 > > (XEN) DOM0: [] setup_arch+0x420/0x5ac > > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > > > Any suggestions would be welcome. > > > > thanks, > > JP > > > > FS2:\> xen -cfg=cfg > > 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty) EFI loader > > junoX: 0x00000009faf87000-0x00000009faf89b89 > > ImageX: 0x00000009fa3be000-0x00000009fabf7000 > > - UART enabled - > > - CPU 00000100 booting - > > - Current EL 00000008 - > > - Xen starting at EL2 - > > - Zero BSS - > > - Setting up control registers - > > - Turning on paging - > > - Ready - > > (XEN) Checking for initrd in /chosen > > (XEN) RAM: 0000000080000000 - 00000000dfffffff > > (XEN) RAM: 00000000e00f0000 - 00000000feb2ffff > > (XEN) RAM: 00000000feba0000 - 00000000febabfff > > (XEN) RAM: 00000000febac000 - 00000000feffffff > > (XEN) RAM: 0000000880000000 - 00000009fa3bdfff > > (XEN) RAM: 00000009fade9000 - 00000009faecffff > > (XEN) RAM: 00000009faf80000 - 00000009faf82fff > > (XEN) RAM: 00000009faf87000 - 00000009faf8afff > > (XEN) RAM: 00000009faf8c000 - 00000009febe3fff > > (XEN) RAM: 00000009febe4000 - 00000009ff142fff > > (XEN) RAM: 00000009ff143000 - 00000009ff144fff > > (XEN) RAM: 00000009ff145000 - 00000009ff16dfff > > (XEN) RAM: 00000009ff16e000 - 00000009ff170fff > > (XEN) RAM: 00000009ff171000 - 00000009ffdbffff > > (XEN) RAM: 00000009ffdc0000 - 00000009ffe44fff > > (XEN) RAM: 00000009ffe45000 - 00000009fff4ffff > > (XEN) RAM: 00000009fff90000 - 00000009fff9ffff > > (XEN) RAM: 00000009ffff0000 - 00000009ffffefff > > (XEN) RAM: 00000009fffff000 - 00000009ffffffff > > (XEN) > > (XEN) MODULE[0]: 00000009faf83000 - 00000009faf87000 Device Tree > > (XEN) MODULE[1]: 00000009fa3be000 - 00000009fabf7000 Kernel > > console=hvc0 earlycon=pl011,0x7ff80000 rootwait root=/dev/sda3 > > (XEN) > > (XEN) Command line: xen console=dtuart dtuart=serial0 conswitch=x > > (XEN) Placing Xen at 0x00000000dfe00000-0x00000000e0000000 > > (XEN) Update BOOTMOD_XEN from 00000009fabf7000-00000009fad01d81 => > > 00000000dfe00000-00000000dff0ad81 > > (XEN) PFN compression on bits 21...22 > > (XEN) Domain heap initialised > > (XEN) Looking for UART console serial0 > > Xen 4.5.1 > > (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > > 4.9.2-20) 4.9.2) debug=y Wed Jul 15 20:13:08 UTC 2015 > > (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty > > (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > > (XEN) 64-bit Execution: > > (XEN) Processor Features: 0000000000002222 0000000000000000 > > (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > > (XEN) Extensions: FloatingPoint AdvancedSIMD > > (XEN) Debug Features: 0000000010305106 0000000000000000 > > (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > > (XEN) Memory Model Features: 0000000000001122 0000000000000000 > > (XEN) ISA Features: 0000000000011120 0000000000000000 > > (XEN) 32-bit Execution: > > (XEN) Processor Features: 00000131:00011011 > > (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > > (XEN) Extensions: GenericTimer Security > > (XEN) Debug Features: 03010066 > > (XEN) Auxiliary Features: 00000000 > > (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > > (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > > (XEN) Platform: VERSATILE EXPRESS > > (XEN) Error: PSCI version 0x10000 is not supported. > > (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > > (XEN) Using generic timer at 50000 KHz > > (XEN) GICv2 initialization: > > (XEN) gic_dist_addr=000000002c010000 > > (XEN) gic_cpu_addr=000000002c02f000 > > (XEN) gic_hyp_addr=000000002c04f000 > > (XEN) gic_vcpu_addr=000000002c06f000 > > (XEN) gic_maintenance_irq=25 > > (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > > (XEN) Using scheduler: SMP Credit Scheduler (credit) > > (XEN) I/O virtualisation disabled > > (XEN) Allocated console ring of 64 KiB. > > (XEN) Bringing up CPU1 > > (XEN) Failed to bring up CPU1 > > (XEN) Failed to bring up CPU 1 (error -1) > > (XEN) Bringing up CPU2 > > (XEN) Failed to bring up CPU2 > > (XEN) Failed to bring up CPU 2 (error -1) > > (XEN) Bringing up CPU3 > > (XEN) Failed to bring up CPU3 > > (XEN) Failed to bring up CPU 3 (error -1) > > (XEN) Bringing up CPU4 > > (XEN) Failed to bring up CPU4 > > (XEN) Failed to bring up CPU 4 (error -1) > > (XEN) Bringing up CPU5 > > (XEN) Failed to bring up CPU5 > > (XEN) Failed to bring up CPU 5 (error -1) > > (XEN) Brought up 1 CPUs > > (XEN) P2M: 40-bit IPA with 40-bit PA > > (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > > (XEN) *** LOADING DOMAIN 0 *** > > (XEN) Loading kernel from boot module @ 00000009fa3be000 > > (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > > (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > > (XEN) Loading zImage from 00000009fa3be000 to 00000000d0080000-00000000d08b9000 > > (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > > (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > > (XEN) ................................................................done. > > (XEN) Initial low memory virq threshold set at 0x4000 pages. > > (XEN) Std. Loglevel: All > > (XEN) Guest Loglevel: All > > (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > > input to Xen) > > (XEN) Freed 284kB init memory. > > (XEN) DOM0: Booting Linux on physical CPU 0x0 > > (XEN) DOM0: Initializing cgroup subsys cpu > > (XEN) DOM0: Linux version 4.0.0Xen+ (root@arm64) (gcc version 4.9.2 > > (Debian/Linaro 4.9.2-20) ) #1 SMP PREEMPT Tue Jul 14 18:10:53 UTC 2015 > > (XEN) DOM0: > > (XEN) DOM0: CPU: AArch64 Processor [410fd030] revision 0 > > (XEN) DOM0: Detected VIPT I-cache on CPU0 > > (XEN) DOM0: alternatives: enabling workaround for ARM errata 826319, > > 827319, 824069 > > (XEN) DOM0: Early serial console at MMIO 0x7ff80000 (options '') > > (XEN) DOM0: bootconsole [uart0] enabled > > (XEN) DOM0: efi: Getting EFI parameters from FDT: > > (XEN) DOM0: efi: UEFI not found. > > (XEN) DOM0: cma: Reserved 64 MiB at 0x00000000d3c00000 > > (XEN) DOM0: psci: probing for conduit method from DT. > > (XEN) DOM0: swapper[0]: undefined instruction: pc=ffffffc00008be20 > > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > > (XEN) DOM0: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP > > (XEN) DOM0: Modules linked in: > > (XEN) DOM0: CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.0Xen+ #1 > > (XEN) DOM0: Hardware name: ARM Juno development board (r0) (DT) > > (XEN) DOM0: task: ffffffc00086d2b0 ti: ffffffc000860000 task.ti: > > ffffffc000860000 > > (XEN) DOM0: PC is at __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: LR is at psci_0_2_init+0x3c/0x170 > > (XEN) DOM0: pc : [] lr : [] pstate: 400000c5 > > (XEN) DOM0: sp : ffffffc000863ee0 > > (XEN) DOM0: x29: ffffffc000863ee0 x28: 00000040d0000000 > > (XEN) DOM0: x27: ffffffc000081230 x26: ffffffc0008cb9a0 > > (XEN) DOM0: x25: 0000000080000200 x24: ffffffc00076b100 > > (XEN) DOM0: x23: ffffffc000866000 x22: ffffffc00087b000 > > (XEN) DOM0: x21: ffffffc00086e000 x20: ffffffc0008bc000 > > (XEN) DOM0: x19: 0000000000000000 x18: 0000000000000409 > > (XEN) DOM0: x17: 0000000000001000 x16: 0000000000000000 > > (XEN) DOM0: x15: 664e321b1f041800 x14: ffffffffffffffff > > (XEN) DOM0: x13: 0000000000000018 x12: 0101010101010101 > > (XEN) DOM0: x11: 0000000000000018 x10: 0101010101010101 > > (XEN) DOM0: x9 : 7f7f7f7f7f7f7f7f x8 : 7f7f7f7f7f7f7f7f > > (XEN) DOM0: x7 : fefefefeff626c72 x6 : 0000008080808082 > > (XEN) DOM0: x5 : 0200000000000000 x4 : ffffffc00008be20 > > (XEN) DOM0: x3 : 0000000000000000 x2 : 0000000000000000 > > (XEN) DOM0: x1 : 0000000000000000 x0 : 0000000084000000 > > (XEN) DOM0: > > (XEN) DOM0: Process swapper (pid: 0, stack limit = 0xffffffc000860028) > > (XEN) DOM0: Stack: (0xffffffc000863ee0 to 0xffffffc000864000) > > (XEN) DOM0: 3ee0: 00863f10 ffffffc0 00817eac ffffffc0 00000000 > > 00000000 008bc000 ffffffc0 > > (XEN) DOM0: 3f00: 0086e000 ffffffc0 0087b000 ffffffc0 00863f30 > > ffffffc0 00817874 ffffffc0 > > (XEN) DOM0: 3f20: 07ffd2c0 ffffffc0 0084cfc0 ffffffc0 00863fa0 > > ffffffc0 00815670 ffffffc0 > > (XEN) DOM0: 3f40: 00844738 ffffffc0 008bc000 ffffffc0 008bc000 > > ffffffc0 00866000 ffffffc0 > > (XEN) DOM0: 3f60: d086ea10 00000000 d0000000 00000000 d08ee000 > > 00000000 d08f0000 00000000 > > (XEN) DOM0: 3f80: 00000000 00000000 00000000 80000000 00000080 > > 00000000 64667467 ff616b73 > > (XEN) DOM0: 3fa0: 00000000 00000000 d0082700 00000000 00000000 > > 00000000 00000e11 00000000 > > (XEN) DOM0: 3fc0: d7e00000 00000000 410fd030 00000000 d086ea10 > > 00000000 d0000000 00000000 > > (XEN) DOM0: 3fe0: 00000000 00000000 00844738 ffffffc0 00000000 > > 00000000 00000000 00000000 > > (XEN) DOM0: Call trace: > > (XEN) DOM0: [] __invoke_psci_fn_smc+0x0/0x10 > > (XEN) DOM0: [] psci_init+0x2c/0x40 > > (XEN) DOM0: [] setup_arch+0x420/0x5ac > > (XEN) DOM0: [] start_kernel+0xa0/0x3a4 > > (XEN) DOM0: Code: d4000002 d65f03c0 d503201f d503201f (d4000003) > > (XEN) DOM0: ---[ end trace cb88537fdc8fa200 ]--- > > (XEN) DOM0: Kernel panic - not syncing: Attempted to kill the idle task! > > (XEN) DOM0: ---[ end Kernel panic - not syncing: Attempted to kill the > > idle task! > > > > On Wed, Jul 15, 2015 at 11:54 AM, John Paul Walters > > wrote: > >> Hi Ian, > >> > >>> > >>> Building Xen with CONFIG_EARLY_PRINTK=juno might get some useful extra > >>> info. It would also be useful to see your file "cfg", in particular the > >>> various command lines which it will contain. > >>> > >> I'll follow up with an update after enabling CONFIG_EARLY_PRINTK, but > >> to answer your other questions, my cfg file: > >> > >> [global] > >> default=default > >> > >> [default] > >> options=console=dtuart dtuart=serial0 conswitch=x > >> kernel=ImageX console=hvc0 earlycon=pl011,0x7ff80000 rootwait > >> root=/dev/sda3 > >> dtb=junoX > >> > >> I copied that from the link I referenced earlier, I believe. The only > >> differences are that I differentiated my default kernel and dtb from > >> the Xen ones by calling the Xen kernel and dtb ImageX and junoX. My > >> root device is indeed /dev/sda3. > >> > >> > >> > >>> I take it your dom0 kernel binary boot successfully with all CPUs > >>> natively? > >> > >> Yes, my dom0 kernel boots all CPUs successfully. I didn't really > >> exercise them, but I can see all six of them. > >> > >>> > >>>> > >>>> thanks, > >>>> JP > >>>> > >> > >> > >> > >> > >> > >>>> UEFI firmware (version v3.0-rc0 built at 21:19:44 on Apr 8 2015) > >>>> [1] Linux from NOR Flash > >>>> [2] Debian ARMv8 > >>>> [3] KVM > >>>> [4] Xen from NOR Flash > >>>> [5] Shell > >>>> [6] Boot Manager > >>>> Start: 5 > >>>> UEFI Interactive Shell v2.1 > >>>> EDK II > >>>> UEFI v2.40 (ARM Juno EFI Apr 8 2015 21:19:51, 0x00000000) > >>>> Mapping table > >>>> FS2: Alias(s):F10:;BLK1: > >>>> VenHw(E7223039-5836-41E1-B542-D7EC736C5E59) > >>>> FS0: Alias(s):F3: > >>>> MemoryMapped(0xB,0xE0000000,0xE00EFFFF) > >>>> FS1: Alias(s):F4: > >>>> MemoryMapped(0xB,0xFEBC2000,0xFEDC693F) > >>>> BLK0: Alias(s): > >>>> VenHw(02118005-9DA7-443A-92D5-781F022AEDBB) > >>>> Shell> fs2: > >>>> FS2:\> xen -cfg=cfg > >>>> 3hXen 4.5.1 (c/s Mon Jun 22 14:12:56 2015 +0100 git:6e865a4) EFI loader > >>>> junoX: 0x00000009faf87000-0x00000009faf89b89 > >>>> ImageX: 0x00000009fa3ce000-0x00000009fac07000 > >>>> Xen 4.5.1 > >>>> (XEN) Xen version 4.5.1 (root@cambridge.arm.com) (gcc (Debian/Linaro > >>>> 4.9.2-20) 4.9.2) debug=n Tue Jul 14 18:20:46 UTC 2015 > >>>> (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4 > >>>> (XEN) Processor: 410fd030: "ARM Limited", variant: 0x0, part 0xd03, rev 0x0 > >>>> (XEN) 64-bit Execution: > >>>> (XEN) Processor Features: 0000000000002222 0000000000000000 > >>>> (XEN) Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32 > >>>> (XEN) Extensions: FloatingPoint AdvancedSIMD > >>>> (XEN) Debug Features: 0000000010305106 0000000000000000 > >>>> (XEN) Auxiliary Features: 0000000000000000 0000000000000000 > >>>> (XEN) Memory Model Features: 0000000000001122 0000000000000000 > >>>> (XEN) ISA Features: 0000000000011120 0000000000000000 > >>>> (XEN) 32-bit Execution: > >>>> (XEN) Processor Features: 00000131:00011011 > >>>> (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle > >>>> (XEN) Extensions: GenericTimer Security > >>>> (XEN) Debug Features: 03010066 > >>>> (XEN) Auxiliary Features: 00000000 > >>>> (XEN) Memory Model Features: 10101105 40000000 01260000 02102211 > >>>> (XEN) ISA Features: 02101110 13112111 21232042 01112131 00011142 00011121 > >>>> (XEN) Error: PSCI version 0x10000 is not supported. > >>>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 > >>>> (XEN) Using generic timer at 50000 KHz > >>>> (XEN) GICv2 initialization: > >>>> (XEN) gic_dist_addr=000000002c010000 > >>>> (XEN) gic_cpu_addr=000000002c02f000 > >>>> (XEN) gic_hyp_addr=000000002c04f000 > >>>> (XEN) gic_vcpu_addr=000000002c06f000 > >>>> (XEN) gic_maintenance_irq=25 > >>>> (XEN) GICv2: 352 lines, 6 cpus, secure (IID 0200143b). > >>>> (XEN) Using scheduler: SMP Credit Scheduler (credit) > >>>> (XEN) I/O virtualisation disabled > >>>> (XEN) Allocated console ring of 16 KiB. > >>>> (XEN) Bringing up CPU1 > >>>> (XEN) Failed to bring up CPU1 > >>>> (XEN) Failed to bring up CPU 1 (error -1) > >>>> (XEN) Bringing up CPU2 > >>>> (XEN) Failed to bring up CPU2 > >>>> (XEN) Failed to bring up CPU 2 (error -1) > >>>> (XEN) Bringing up CPU3 > >>>> (XEN) Failed to bring up CPU3 > >>>> (XEN) Failed to bring up CPU 3 (error -1) > >>>> (XEN) Bringing up CPU4 > >>>> (XEN) Failed to bring up CPU4 > >>>> (XEN) Failed to bring up CPU 4 (error -1) > >>>> (XEN) Bringing up CPU5 > >>>> (XEN) Failed to bring up CPU5 > >>>> (XEN) Failed to bring up CPU 5 (error -1) > >>>> (XEN) Brought up 1 CPUs > >>>> (XEN) P2M: 40-bit IPA with 40-bit PA > >>>> (XEN) P2M: 3 levels with order-1 root, VTCR 0x80023558 > >>>> (XEN) *** LOADING DOMAIN 0 *** > >>>> (XEN) Loading kernel from boot module @ 00000009fa3ce000 > >>>> (XEN) Allocating 1:1 mappings totalling 128MB for dom0: > >>>> (XEN) BANK[0] 0x000000d0000000-0x000000d8000000 (128MB) > >>>> (XEN) Loading zImage from 00000009fa3ce000 to 00000000d0080000-00000000d08b9000 > >>>> (XEN) Loading dom0 DTB to 0x00000000d7e00000-0x00000000d7e0204f > >>>> (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs > >>>> (XEN) ................................................................done. > >>>> (XEN) Initial low memory virq threshold set at 0x4000 pages. > >>>> (XEN) Std. Loglevel: Errors and warnings > >>>> (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) > >>>> (XEN) *** Serial input -> DOM0 (type 'CTRL-x' three times to switch > >>>> input to Xen) > >>>> (XEN) Freed 280kB init memory. > >>>> (XEN) *** Serial input -> Xen (type 'CTRL-x' three times to switch > >>>> input to DOM0) > >>>> > >>>> _______________________________________________ > >>>> Xen-users mailing list > >>>> Xen-users@lists.xen.org > >>>> http://lists.xen.org/xen-users > >>> > >>> _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 20:01:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 20:01:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHHEX-0001Y7-Sf; Mon, 20 Jul 2015 20:00:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHHEW-0001Y2-8S for xen-users@lists.xen.org; Mon, 20 Jul 2015 20:00:16 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id F4/3B-32733-F435DA55; Mon, 20 Jul 2015 20:00:15 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1437422414!33744885!1 X-Originating-IP: [216.31.210.62] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2870 invoked from network); 20 Jul 2015 20:00:14 -0000 Received: from mail-gw1-out.broadcom.com (HELO mail-gw1-out.broadcom.com) (216.31.210.62) by server-13.tower-27.messagelabs.com with SMTP; 20 Jul 2015 20:00:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="70401664" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 20 Jul 2015 14:09:50 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 13:00:10 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 13:00:11 -0700 From: "Chris (Christopher) Brand" To: Ian Campbell Thread-Topic: [Xen-users] ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQCRQakAAAIevkA= Date: Mon, 20 Jul 2015 20:00:09 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> In-Reply-To: <1437393238.12274.5.camel@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Thanks, Ian. >That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. I thought that might have been for x86. >One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling >that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). > >Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... I saw an older email of yours relating to this. Will see if I can try that. This did prompt me to try building without CONFIG_SEPARATE_XENHEAP, which seems like it should also solve my problem, but the result didn't boot (which is a bit surprising, given that it looks like that is not set for ARM64). >WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 20:01:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 20:01:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHHEX-0001Y7-Sf; Mon, 20 Jul 2015 20:00:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHHEW-0001Y2-8S for xen-users@lists.xen.org; Mon, 20 Jul 2015 20:00:16 +0000 Received: from [193.109.254.147] by server-8.bemta-14.messagelabs.com id F4/3B-32733-F435DA55; Mon, 20 Jul 2015 20:00:15 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1437422414!33744885!1 X-Originating-IP: [216.31.210.62] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2870 invoked from network); 20 Jul 2015 20:00:14 -0000 Received: from mail-gw1-out.broadcom.com (HELO mail-gw1-out.broadcom.com) (216.31.210.62) by server-13.tower-27.messagelabs.com with SMTP; 20 Jul 2015 20:00:14 -0000 X-IronPort-AV: E=Sophos;i="5.15,509,1432623600"; d="scan'208";a="70401664" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 20 Jul 2015 14:09:50 -0700 Received: from SJEXCHCAS05.corp.ad.broadcom.com (10.16.203.12) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 13:00:10 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS05.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 13:00:11 -0700 From: "Chris (Christopher) Brand" To: Ian Campbell Thread-Topic: [Xen-users] ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQCRQakAAAIevkA= Date: Mon, 20 Jul 2015 20:00:09 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> In-Reply-To: <1437393238.12274.5.camel@citrix.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Thanks, Ian. >That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. I thought that might have been for x86. >One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling >that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). > >Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... I saw an older email of yours relating to this. Will see if I can try that. This did prompt me to try building without CONFIG_SEPARATE_XENHEAP, which seems like it should also solve my problem, but the result didn't boot (which is a bit surprising, given that it looks like that is not set for ARM64). >WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 21:39:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 21:39:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHIlN-0004jT-NW; Mon, 20 Jul 2015 21:38:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHIlM-0004jO-K4 for xen-users@lists.xen.org; Mon, 20 Jul 2015 21:38:16 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 0B/4A-27015-74A6DA55; Mon, 20 Jul 2015 21:38:15 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1437428294!18307589!1 X-Originating-IP: [216.31.210.64] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22019 invoked from network); 20 Jul 2015 21:38:15 -0000 Received: from mail-gw3-out.broadcom.com (HELO mail-gw3-out.broadcom.com) (216.31.210.64) by server-11.tower-206.messagelabs.com with SMTP; 20 Jul 2015 21:38:15 -0000 X-IronPort-AV: E=Sophos;i="5.15,510,1432623600"; d="scan'208";a="70140765" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 20 Jul 2015 14:55:20 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 14:38:11 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:38:11 -0700 From: "Chris (Christopher) Brand" To: Ian Campbell Thread-Topic: [Xen-users] ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQCRQakAAAIevkAAA4j6YA== Date: Mon, 20 Jul 2015 21:38:10 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D6BEE@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org >>WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? >I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. This seems to be correct. I tried xenheap_megabytes=62, and that failed to boot too. I assume it's hitting the ASSERT() in create_32mb_mappings(). Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 20 21:39:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 20 Jul 2015 21:39:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHIlN-0004jT-NW; Mon, 20 Jul 2015 21:38:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHIlM-0004jO-K4 for xen-users@lists.xen.org; Mon, 20 Jul 2015 21:38:16 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 0B/4A-27015-74A6DA55; Mon, 20 Jul 2015 21:38:15 +0000 X-Env-Sender: chris.brand@broadcom.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1437428294!18307589!1 X-Originating-IP: [216.31.210.64] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22019 invoked from network); 20 Jul 2015 21:38:15 -0000 Received: from mail-gw3-out.broadcom.com (HELO mail-gw3-out.broadcom.com) (216.31.210.64) by server-11.tower-206.messagelabs.com with SMTP; 20 Jul 2015 21:38:15 -0000 X-IronPort-AV: E=Sophos;i="5.15,510,1432623600"; d="scan'208";a="70140765" Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw3-out.broadcom.com with ESMTP; 20 Jul 2015 14:55:20 -0700 Received: from SJEXCHCAS06.corp.ad.broadcom.com (10.16.203.14) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jul 2015 14:38:11 -0700 Received: from SJEXCHMB05.corp.ad.broadcom.com ([fe80::4ccf:d24d:fe6c:9594]) by SJEXCHCAS06.corp.ad.broadcom.com ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:38:11 -0700 From: "Chris (Christopher) Brand" To: Ian Campbell Thread-Topic: [Xen-users] ARM: xehheap_megabytes less than 32 Thread-Index: AdDA2GiABDb1FlELSz+6x/rH512pZQCRQakAAAIevkAAA4j6YA== Date: Mon, 20 Jul 2015 21:38:10 +0000 Message-ID: <4EE5B48738DDED408878C97C8E050A8B1D7D6BEE@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org >>WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? >I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. This seems to be correct. I tried xenheap_megabytes=62, and that failed to boot too. I assume it's hitting the ASSERT() in create_32mb_mappings(). Chris _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 00:25:25 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 00:25:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLM1-0003tQ-UJ; Tue, 21 Jul 2015 00:24:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLM0-0003tL-8N for xen-users@lists.xen.org; Tue, 21 Jul 2015 00:24:16 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 01/6F-24599-F219DA55; Tue, 21 Jul 2015 00:24:15 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1437438253!22425822!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14846 invoked from network); 21 Jul 2015 00:24:14 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 00:24:14 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6L0OCoB002998 for ; Mon, 20 Jul 2015 19:24:13 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6L0OCgI013508 for ; Mon, 20 Jul 2015 19:24:12 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 20 Jul 2015 19:23:41 -0500 Message-ID: <55AD832E.2060003@ti.com> Date: Mon, 20 Jul 2015 19:24:30 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues with root NFS on Dom0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello All, Here's a quick overview of my setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 - Repo URL: git://xenbits.xen.org/xen.git - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 - Repo URL: git://git.omapzoom.org/kernel/omap.git I'm attempting to get an root NFS boot working with a Linux Dom0. The boot works, but is horrendously slow. A /bin/sh boot takes several minutes, and an init boot takes hours (I gave up on init after 20 minutes). For comparison, a boot from an SD card takes about 15 seconds. Also, with a native Linux root NFS boot, the total boot time is about 25 seconds, so the issue seems to be related with Xen or my Xen configuration. I haven't done a lot of debugging yet, so I don't have much additional information. Before I go deep into debugging this, I was wondering if this is an issue you guys have heard of before. Also, I was wondering if there was any immediate things you can think of that might be causing this problem. One thing I have quickly looked over is /proc/interrupts. For a native boot, there are several hundred ethernet transmit interrupts. On the Xen boot, there are several million transmit interrupts. Thanks, Brandon Perez _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 00:25:25 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 00:25:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLM1-0003tQ-UJ; Tue, 21 Jul 2015 00:24:17 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLM0-0003tL-8N for xen-users@lists.xen.org; Tue, 21 Jul 2015 00:24:16 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 01/6F-24599-F219DA55; Tue, 21 Jul 2015 00:24:15 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1437438253!22425822!1 X-Originating-IP: [198.47.26.153] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MyA9PiAxNjk4NDE=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 14846 invoked from network); 21 Jul 2015 00:24:14 -0000 Received: from devils.ext.ti.com (HELO devils.ext.ti.com) (198.47.26.153) by server-8.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 00:24:14 -0000 Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6L0OCoB002998 for ; Mon, 20 Jul 2015 19:24:13 -0500 Received: from DLEE70.ent.ti.com (dlee70.ent.ti.com [157.170.170.113]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6L0OCgI013508 for ; Mon, 20 Jul 2015 19:24:12 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Mon, 20 Jul 2015 19:23:41 -0500 Message-ID: <55AD832E.2060003@ti.com> Date: Mon, 20 Jul 2015 19:24:30 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues with root NFS on Dom0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello All, Here's a quick overview of my setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 - Repo URL: git://xenbits.xen.org/xen.git - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 - Repo URL: git://git.omapzoom.org/kernel/omap.git I'm attempting to get an root NFS boot working with a Linux Dom0. The boot works, but is horrendously slow. A /bin/sh boot takes several minutes, and an init boot takes hours (I gave up on init after 20 minutes). For comparison, a boot from an SD card takes about 15 seconds. Also, with a native Linux root NFS boot, the total boot time is about 25 seconds, so the issue seems to be related with Xen or my Xen configuration. I haven't done a lot of debugging yet, so I don't have much additional information. Before I go deep into debugging this, I was wondering if this is an issue you guys have heard of before. Also, I was wondering if there was any immediate things you can think of that might be causing this problem. One thing I have quickly looked over is /proc/interrupts. For a native boot, there are several hundred ethernet transmit interrupts. On the Xen boot, there are several million transmit interrupts. Thanks, Brandon Perez _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 00:59:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 00:59:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLtV-0005bv-4p; Tue, 21 Jul 2015 00:58:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLtT-0005bm-Ch for xen-users@lists.xen.org; Tue, 21 Jul 2015 00:58:51 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id A7/42-27764-A499DA55; Tue, 21 Jul 2015 00:58:50 +0000 X-Env-Sender: mailinglists@websitemanagers.com.au X-Msg-Ref: server-2.tower-27.messagelabs.com!1437440325!33737962!1 X-Originating-IP: [203.98.89.10] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22808 invoked from network); 21 Jul 2015 00:58:49 -0000 Received: from hammer.websitemanagers.com.au (HELO hammer.websitemanagers.com.au) (203.98.89.10) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 00:58:49 -0000 Received: (qmail 18614 invoked by uid 1011); 21 Jul 2015 00:58:43 -0000 Received: from 124.246.8.196 by hammer (envelope-from , uid 1008) with qmail-scanner-1.24 (clamdscan: 0.98.1/20703. spamassassin: 3.3.1. Clear:RC:1(124.246.8.196):. Processed in 0.185893 secs); 21 Jul 2015 00:58:43 -0000 Received: from unknown (HELO ?10.97.0.6?) (124.246.8.196) by 0 with SMTP; 21 Jul 2015 00:58:43 -0000 Message-ID: <55AD9943.4010804@websitemanagers.com.au> Date: Tue, 21 Jul 2015 10:58:43 +1000 From: Adam Goryachev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55AD832E.2060003@ti.com> In-Reply-To: <55AD832E.2060003@ti.com> Subject: Re: [Xen-users] [Xen-Users] Issues with root NFS on Dom0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Brandon, I tried a NFS root solution for my group of dom0 hosts a number of years ago (using xen4.0). Due to a number of lockups and issues I suffered over a period of time my "solution" which has worked very well for me, using a custom initrd I actually copy the rootfs to a ram disk, and then boot from memory. This meant that I no longer had to worry about the NFS server availability for the dom0's to be working, and also I could use a single copy of the rootfs for all dom0's, and no problem with a shared /tmp or /etc and so on. While I can still see the advantages of using this style solution (NFS root), I think there are better options today (that I haven't investigated/used). One issue with the shared NFS root was also dealing with updates/upgrades, where my current solution handles that (chroot, install new package, reboot dom0 one at a time with appropriate live migrations). Today, with all the fancy management tools like puppet/chef/etc (I know nothing about them, except I vaguely understand they should support booting and installing/configuring your dom0, including any update/upgrades on each reboot). You might want to look into some of those options. Of course, none of that directly helps you with your issue. Have you tried getting shell access early in the init process, and measuring/testing what is actually wrong, is it CPU performance, network performance, or NFS performance? Possibly there is a network card driver issue, have you tried a different network card (different brand/model/etc)? What about your switch, does it report any collisions, dropped packets, errors, etc? Faulty network cable perhaps? Sorry I couldn't help really, but maybe it will provide some ideas. Regards, Adam On 21/07/15 09:24, Brandon Perez wrote: > Hello All, > > Here's a quick overview of my setup: > - Hardware: TI DRA72 Chip, Arm Cortex A15 > - Xen: > - Version: 4.6-unstable > - Compiled from source, with some local changes > - Branch: master > - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 > - Repo URL: git://xenbits.xen.org/xen.git > - Linux Kernel: > - Version: 3.14 > - Compiled From source, with some local changes > - Branch: android-3.14-6AL.1.0 > - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 > - Repo URL: git://git.omapzoom.org/kernel/omap.git > > I'm attempting to get an root NFS boot working with a Linux Dom0. > The boot works, but is horrendously slow. A /bin/sh boot takes several > minutes, and an init boot takes hours (I gave up on init after 20 > minutes). For comparison, a boot from an SD card takes about 15 seconds. > Also, with a native Linux root NFS boot, the total boot time is about > 25 seconds, so the issue seems to be related with Xen or my Xen > configuration. > > I haven't done a lot of debugging yet, so I don't have much > additional information. Before I go deep into debugging this, I was > wondering if this is an issue you guys have heard of before. Also, I > was wondering if there was any immediate things you can think of that > might be causing this problem. > > One thing I have quickly looked over is /proc/interrupts. For a > native boot, there are several hundred ethernet transmit interrupts. > On the Xen boot, there are several million transmit interrupts. > > Thanks, > > Brandon Perez > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- Adam Goryachev Website Managers www.websitemanagers.com.au _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 00:59:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 00:59:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLtV-0005bv-4p; Tue, 21 Jul 2015 00:58:53 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHLtT-0005bm-Ch for xen-users@lists.xen.org; Tue, 21 Jul 2015 00:58:51 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id A7/42-27764-A499DA55; Tue, 21 Jul 2015 00:58:50 +0000 X-Env-Sender: mailinglists@websitemanagers.com.au X-Msg-Ref: server-2.tower-27.messagelabs.com!1437440325!33737962!1 X-Originating-IP: [203.98.89.10] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22808 invoked from network); 21 Jul 2015 00:58:49 -0000 Received: from hammer.websitemanagers.com.au (HELO hammer.websitemanagers.com.au) (203.98.89.10) by server-2.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 00:58:49 -0000 Received: (qmail 18614 invoked by uid 1011); 21 Jul 2015 00:58:43 -0000 Received: from 124.246.8.196 by hammer (envelope-from , uid 1008) with qmail-scanner-1.24 (clamdscan: 0.98.1/20703. spamassassin: 3.3.1. Clear:RC:1(124.246.8.196):. Processed in 0.185893 secs); 21 Jul 2015 00:58:43 -0000 Received: from unknown (HELO ?10.97.0.6?) (124.246.8.196) by 0 with SMTP; 21 Jul 2015 00:58:43 -0000 Message-ID: <55AD9943.4010804@websitemanagers.com.au> Date: Tue, 21 Jul 2015 10:58:43 +1000 From: Adam Goryachev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: xen-users@lists.xen.org References: <55AD832E.2060003@ti.com> In-Reply-To: <55AD832E.2060003@ti.com> Subject: Re: [Xen-users] [Xen-Users] Issues with root NFS on Dom0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi Brandon, I tried a NFS root solution for my group of dom0 hosts a number of years ago (using xen4.0). Due to a number of lockups and issues I suffered over a period of time my "solution" which has worked very well for me, using a custom initrd I actually copy the rootfs to a ram disk, and then boot from memory. This meant that I no longer had to worry about the NFS server availability for the dom0's to be working, and also I could use a single copy of the rootfs for all dom0's, and no problem with a shared /tmp or /etc and so on. While I can still see the advantages of using this style solution (NFS root), I think there are better options today (that I haven't investigated/used). One issue with the shared NFS root was also dealing with updates/upgrades, where my current solution handles that (chroot, install new package, reboot dom0 one at a time with appropriate live migrations). Today, with all the fancy management tools like puppet/chef/etc (I know nothing about them, except I vaguely understand they should support booting and installing/configuring your dom0, including any update/upgrades on each reboot). You might want to look into some of those options. Of course, none of that directly helps you with your issue. Have you tried getting shell access early in the init process, and measuring/testing what is actually wrong, is it CPU performance, network performance, or NFS performance? Possibly there is a network card driver issue, have you tried a different network card (different brand/model/etc)? What about your switch, does it report any collisions, dropped packets, errors, etc? Faulty network cable perhaps? Sorry I couldn't help really, but maybe it will provide some ideas. Regards, Adam On 21/07/15 09:24, Brandon Perez wrote: > Hello All, > > Here's a quick overview of my setup: > - Hardware: TI DRA72 Chip, Arm Cortex A15 > - Xen: > - Version: 4.6-unstable > - Compiled from source, with some local changes > - Branch: master > - Commit: ecdae1cfaa7f6123decaa1b9d7205c3ff726b941 > - Repo URL: git://xenbits.xen.org/xen.git > - Linux Kernel: > - Version: 3.14 > - Compiled From source, with some local changes > - Branch: android-3.14-6AL.1.0 > - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 > - Repo URL: git://git.omapzoom.org/kernel/omap.git > > I'm attempting to get an root NFS boot working with a Linux Dom0. > The boot works, but is horrendously slow. A /bin/sh boot takes several > minutes, and an init boot takes hours (I gave up on init after 20 > minutes). For comparison, a boot from an SD card takes about 15 seconds. > Also, with a native Linux root NFS boot, the total boot time is about > 25 seconds, so the issue seems to be related with Xen or my Xen > configuration. > > I haven't done a lot of debugging yet, so I don't have much > additional information. Before I go deep into debugging this, I was > wondering if this is an issue you guys have heard of before. Also, I > was wondering if there was any immediate things you can think of that > might be causing this problem. > > One thing I have quickly looked over is /proc/interrupts. For a > native boot, there are several hundred ethernet transmit interrupts. > On the Xen boot, there are several million transmit interrupts. > > Thanks, > > Brandon Perez > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users -- Adam Goryachev Website Managers www.websitemanagers.com.au _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 08:13:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 08:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSf1-0002Zy-7U; Tue, 21 Jul 2015 08:12:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSez-0002Zt-Vi for xen-users@lists.xen.org; Tue, 21 Jul 2015 08:12:22 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id A7/EF-18733-5EEFDA55; Tue, 21 Jul 2015 08:12:21 +0000 X-Env-Sender: alex@wakizashi.info X-Msg-Ref: server-11.tower-27.messagelabs.com!1437466339!27724284!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28584 invoked from network); 21 Jul 2015 08:12:20 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 08:12:20 -0000 Received: by lbbzr7 with SMTP id zr7so110565178lbb.1 for ; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakizashi.info; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxPOtpNtX++eqjX9qYatNJdHjUX+XxaVtcGPrcLc20Q=; b=VVbQfUMe2DeKoxdga7G0Vz4liBHIYQnAYnWbbuca7G9Z0C66q3qihfvNPfVu8hDYLx 8HSTsAF8mp0SCYiX13TryA5TCluXxmFp2Z4XGM7ztKjKZxE9uTZOL5gYsUbUfhqlwiZf OU4WcTumr6Yy+9Svo7OP5+mhBCR8jtr7v9Tx4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AxPOtpNtX++eqjX9qYatNJdHjUX+XxaVtcGPrcLc20Q=; b=ZWn2GiMbutNj+o0V9+IilVkVSX0bovTX1KLZq9rOX+AEbpnA6jHzNzWZ+pbqrLuwZd uhLOWZ6tbLyWI1WIl67dz88P7/gAVmbUkLETRbO9mPxyGa0KnfG3YnvMTyu3WlzADL7D HHXP1mBTPM10/TYGRBgyIORymykJCku1LwFVqLEw+W/kayw6aG8k0pOuL9AX24xSfkm6 oy7mvYJcFrZOVHdJEWFGQLrVdcMtCeN+EK/QNgLg4k4w1izIYEJWYJ3cIUGWn2FbWSTJ jM0eT74/w/UMCEpHv6ARw1O3OO2txG7VaV1PLfi+iyo9lq2pjrrl4svLurP2D4AugVi3 oEhA== X-Gm-Message-State: ALoCoQlGt0xmF6pM+vBWhsrEiEQm09U7zHg+EnuHEaajUQAOIbEwpDVOY9EbfQqkxm+gWEp18ZPH MIME-Version: 1.0 X-Received: by 10.152.42.230 with SMTP id r6mr28763962lal.30.1437466339666; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) Received: by 10.152.210.198 with HTTP; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) In-Reply-To: <20150716104440.GA2986@dingwall.me.uk> References: <20150716104440.GA2986@dingwall.me.uk> Date: Tue, 21 Jul 2015 11:12:19 +0300 Message-ID: From: Alex Wakizashi To: James Dingwall Cc: xen-users@lists.xen.org, Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello James, all, Yes, course XEN is compiled with ovmf path, and as I mentioned above, have tried 2 versions of OVMF - both from XEN's GIT, and latest upstream OVMF from it's own repository. Both are booting fine with XEN without PCI passthrough, but regardless of EFI boot partition (0xef00 GPT, or 0xef MBR) it doesn't save values. I've seen file created in root of this partitions - but still not able to save values neither from UEFI itself, nor with efibootmanager under Linux. And this is really minor problem. Still not received an answer about PCI devices with UEFI ROM BIOS passthrough, which is a major problem, or how to get debug output from OVMF. I'm very interested to make separated OVMF binary and pflash image for EFI variables, work in XEN. As far as I understand from mentioned thread, this is what Andrew told about. In this case it would be possible to test different OVMF modifications without recompilation of XEN. Regards. Alex On 16 July 2015 at 13:44, James Dingwall wrote: > On Wed, Jul 15, 2015 at 09:02:13AM +0300, Alex Wakizashi wrote: >> Second problem - XEN implementation of OVMF doesn't allow to save any settings. >> Regardless of pflash image, specified in QEMU as "-drive if=pflash..." >> - it's just not saving settings at all. >> >> Again, would be excellent to be able to specify separate OVMF image, >> like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that >> is a problem. >> >> I've seen discussion in this mail list about separated version of OVMF >> for XEN, but it stopped few months ago without any links/solutions. >> (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA >> Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave >> some answers). >> >> So, would be glad to get hands on such version and test it :) > > I did some experimentation with uefi guests recently, iirc if your disk image has an ef00 partition then > settings will be saved there. I would need to go back and confirm that this is the case since it was several > months since I did this. There is a ./configure option for the xen build which allows an external ovmf binary > too be used. > > ./configure --with-system-ovmf=/my/ovmf/build/OVMF.fd --enable-ovmf > > James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 08:13:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 08:13:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSf1-0002Zy-7U; Tue, 21 Jul 2015 08:12:23 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSez-0002Zt-Vi for xen-users@lists.xen.org; Tue, 21 Jul 2015 08:12:22 +0000 Received: from [193.109.254.147] by server-12.bemta-14.messagelabs.com id A7/EF-18733-5EEFDA55; Tue, 21 Jul 2015 08:12:21 +0000 X-Env-Sender: alex@wakizashi.info X-Msg-Ref: server-11.tower-27.messagelabs.com!1437466339!27724284!1 X-Originating-IP: [209.85.217.172] X-SpamReason: No, hits=0.3 required=7.0 tests=RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 28584 invoked from network); 21 Jul 2015 08:12:20 -0000 Received: from mail-lb0-f172.google.com (HELO mail-lb0-f172.google.com) (209.85.217.172) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 08:12:20 -0000 Received: by lbbzr7 with SMTP id zr7so110565178lbb.1 for ; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wakizashi.info; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AxPOtpNtX++eqjX9qYatNJdHjUX+XxaVtcGPrcLc20Q=; b=VVbQfUMe2DeKoxdga7G0Vz4liBHIYQnAYnWbbuca7G9Z0C66q3qihfvNPfVu8hDYLx 8HSTsAF8mp0SCYiX13TryA5TCluXxmFp2Z4XGM7ztKjKZxE9uTZOL5gYsUbUfhqlwiZf OU4WcTumr6Yy+9Svo7OP5+mhBCR8jtr7v9Tx4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AxPOtpNtX++eqjX9qYatNJdHjUX+XxaVtcGPrcLc20Q=; b=ZWn2GiMbutNj+o0V9+IilVkVSX0bovTX1KLZq9rOX+AEbpnA6jHzNzWZ+pbqrLuwZd uhLOWZ6tbLyWI1WIl67dz88P7/gAVmbUkLETRbO9mPxyGa0KnfG3YnvMTyu3WlzADL7D HHXP1mBTPM10/TYGRBgyIORymykJCku1LwFVqLEw+W/kayw6aG8k0pOuL9AX24xSfkm6 oy7mvYJcFrZOVHdJEWFGQLrVdcMtCeN+EK/QNgLg4k4w1izIYEJWYJ3cIUGWn2FbWSTJ jM0eT74/w/UMCEpHv6ARw1O3OO2txG7VaV1PLfi+iyo9lq2pjrrl4svLurP2D4AugVi3 oEhA== X-Gm-Message-State: ALoCoQlGt0xmF6pM+vBWhsrEiEQm09U7zHg+EnuHEaajUQAOIbEwpDVOY9EbfQqkxm+gWEp18ZPH MIME-Version: 1.0 X-Received: by 10.152.42.230 with SMTP id r6mr28763962lal.30.1437466339666; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) Received: by 10.152.210.198 with HTTP; Tue, 21 Jul 2015 01:12:19 -0700 (PDT) In-Reply-To: <20150716104440.GA2986@dingwall.me.uk> References: <20150716104440.GA2986@dingwall.me.uk> Date: Tue, 21 Jul 2015 11:12:19 +0300 Message-ID: From: Alex Wakizashi To: James Dingwall Cc: xen-users@lists.xen.org, Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello James, all, Yes, course XEN is compiled with ovmf path, and as I mentioned above, have tried 2 versions of OVMF - both from XEN's GIT, and latest upstream OVMF from it's own repository. Both are booting fine with XEN without PCI passthrough, but regardless of EFI boot partition (0xef00 GPT, or 0xef MBR) it doesn't save values. I've seen file created in root of this partitions - but still not able to save values neither from UEFI itself, nor with efibootmanager under Linux. And this is really minor problem. Still not received an answer about PCI devices with UEFI ROM BIOS passthrough, which is a major problem, or how to get debug output from OVMF. I'm very interested to make separated OVMF binary and pflash image for EFI variables, work in XEN. As far as I understand from mentioned thread, this is what Andrew told about. In this case it would be possible to test different OVMF modifications without recompilation of XEN. Regards. Alex On 16 July 2015 at 13:44, James Dingwall wrote: > On Wed, Jul 15, 2015 at 09:02:13AM +0300, Alex Wakizashi wrote: >> Second problem - XEN implementation of OVMF doesn't allow to save any settings. >> Regardless of pflash image, specified in QEMU as "-drive if=pflash..." >> - it's just not saving settings at all. >> >> Again, would be excellent to be able to specify separate OVMF image, >> like in normal QEMU. AFAIK, now hvmloader includes ovmf.bin - and that >> is a problem. >> >> I've seen discussion in this mail list about separated version of OVMF >> for XEN, but it stopped few months ago without any links/solutions. >> (Thread was named "Some questions regarding QEMU, UEFI, PCI/VGA >> Passthrough, and other things", so I've cc-ed Andrew Cooper as he gave >> some answers). >> >> So, would be glad to get hands on such version and test it :) > > I did some experimentation with uefi guests recently, iirc if your disk image has an ef00 partition then > settings will be saved there. I would need to go back and confirm that this is the case since it was several > months since I did this. There is a ./configure option for the xen build which allows an external ovmf binary > too be used. > > ./configure --with-system-ovmf=/my/ovmf/build/OVMF.fd --enable-ovmf > > James _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 08:29:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 08:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSvO-0003LS-T7; Tue, 21 Jul 2015 08:29:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSvN-0003LN-HJ for xen-users@lists.xen.org; Tue, 21 Jul 2015 08:29:17 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 76/2A-00727-CD20EA55; Tue, 21 Jul 2015 08:29:16 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437467354!26468120!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12764 invoked from network); 21 Jul 2015 08:29:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 08:29:15 -0000 X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="285985640" Message-ID: <1437467349.17368.75.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Tue, 21 Jul 2015 09:29:09 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-20 at 20:00 +0000, Chris (Christopher) Brand wrote: > Thanks, Ian. > > >That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. > I thought that might have been for x86. > > >One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling >that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). > > > >Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... > I saw an older email of yours relating to this. Will see if I can try that. > This did prompt me to try building without CONFIG_SEPARATE_XENHEAP, > which seems like it should also solve my problem, but the result > didn't boot (which is a bit surprising, given that it looks like that > is not set for ARM64). CONFIG_SEPARATE_XENHEAP is not a user facing option, it is something which the architecture port can opt in or out of. Turning it off requires a large 1:1 mapping covering most of RAM, which cannot be done on arm32 since the 32-bit address space is too limited. Even if it made sense for arm32 changing this option would also require reworking of the start of day heap setup code. Ian. > > >WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? > I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. > > Chris > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 08:29:41 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 08:29:41 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSvO-0003LS-T7; Tue, 21 Jul 2015 08:29:18 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHSvN-0003LN-HJ for xen-users@lists.xen.org; Tue, 21 Jul 2015 08:29:17 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 76/2A-00727-CD20EA55; Tue, 21 Jul 2015 08:29:16 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437467354!26468120!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12764 invoked from network); 21 Jul 2015 08:29:15 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 08:29:15 -0000 X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="285985640" Message-ID: <1437467349.17368.75.camel@citrix.com> From: Ian Campbell To: "Chris (Christopher) Brand" Date: Tue, 21 Jul 2015 09:29:09 +0100 In-Reply-To: <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> References: <4EE5B48738DDED408878C97C8E050A8B1D7D58EA@SJEXCHMB05.corp.ad.broadcom.com> <1437393238.12274.5.camel@citrix.com> <4EE5B48738DDED408878C97C8E050A8B1D7D6AAF@SJEXCHMB05.corp.ad.broadcom.com> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA2 Cc: "xen-users@lists.xen.org" Subject: Re: [Xen-users] ARM: xehheap_megabytes less than 32 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-20 at 20:00 +0000, Chris (Christopher) Brand wrote: > Thanks, Ian. > > >That was for x86, but no I don't think it is inherently ridiculous to try and reduce the Xen heap quite substantially. > I thought that might have been for x86. > > >One thing you should check though is what happens to domheap allocations when the domheap is empty but the xenheap still has pages. I have a feeling >that such allocations can be satisfied from the xenheap, at least under some circumstances (depending on CONFIG_SEPARATE_XENHEAP?). > > > >Rather than trying to unpick xen/common/page_alloc.c and the various heaps/nodes it might be easier to just confirm experimentally... > I saw an older email of yours relating to this. Will see if I can try that. > This did prompt me to try building without CONFIG_SEPARATE_XENHEAP, > which seems like it should also solve my problem, but the result > didn't boot (which is a bit surprising, given that it looks like that > is not set for ARM64). CONFIG_SEPARATE_XENHEAP is not a user facing option, it is something which the architecture port can opt in or out of. Turning it off requires a large 1:1 mapping covering most of RAM, which cannot be done on arm32 since the 32-bit address space is too limited. Even if it made sense for arm32 changing this option would also require reworking of the start of day heap setup code. Ian. > > >WRT the 32mb limit, I wonder if that is the same underlying issue as you tripped over for the frametable mapping? > I do now see that setup_xenheap_mappings() calls create_32mb_mappings(), which presumably imposes a granularity of 32MB on xenheap_megabytes. > > Chris > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 09:11:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 09:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHTZl-0005PE-98; Tue, 21 Jul 2015 09:11:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHTZj-0005P9-3Z for xen-users@lists.xen.org; Tue, 21 Jul 2015 09:10:59 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id BE/F2-10437-2AC0EA55; Tue, 21 Jul 2015 09:10:58 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437469856!26487817!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30001 invoked from network); 21 Jul 2015 09:10:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 09:10:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="285993550" Message-ID: <1437469848.17368.92.camel@citrix.com> From: Ian Campbell To: Alex Wakizashi Date: Tue, 21 Jul 2015 10:10:48 +0100 In-Reply-To: References: <20150716104440.GA2986@dingwall.me.uk> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org, James Dingwall , Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 11:12 +0300, Alex Wakizashi wrote: > Still not received an answer about PCI devices with UEFI ROM BIOS > passthrough, which is a major problem, or how to get debug output from > OVMF. > > I'm very interested to make separated OVMF binary and pflash image for > EFI variables, work in XEN. I think this pair of topics would therefore be suitable for the devel list, and perhaps even cross posting to the upstream ovmf/edk2 list (which I know just moved off sf.net, but I'm not sure where too...). > As far as I understand from mentioned thread, this is what Andrew told > about. In this case it would be possible to test different OVMF > modifications without recompilation of XEN. IIRC Andrew would like to make hvmloader multiboot aware, such that it can be passed the BIOS as a payload (loaded by the toolstack) and avoiding the need to build it into hvmloader statically. AFAIAA there has been no work done on this front, but if you were interested in picking it up that would be pretty awesome. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 09:11:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 09:11:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHTZl-0005PE-98; Tue, 21 Jul 2015 09:11:01 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHTZj-0005P9-3Z for xen-users@lists.xen.org; Tue, 21 Jul 2015 09:10:59 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id BE/F2-10437-2AC0EA55; Tue, 21 Jul 2015 09:10:58 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1437469856!26487817!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30001 invoked from network); 21 Jul 2015 09:10:57 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 09:10:57 -0000 X-IronPort-AV: E=Sophos;i="5.15,514,1432598400"; d="scan'208";a="285993550" Message-ID: <1437469848.17368.92.camel@citrix.com> From: Ian Campbell To: Alex Wakizashi Date: Tue, 21 Jul 2015 10:10:48 +0100 In-Reply-To: References: <20150716104440.GA2986@dingwall.me.uk> X-Mailer: Evolution 3.12.9-1+b1 MIME-Version: 1.0 X-DLP: MIA1 Cc: xen-users@lists.xen.org, James Dingwall , Andrew Cooper Subject: Re: [Xen-users] OVMF and XEN - hangs on boot with pci-passthrough, not saving settings X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 11:12 +0300, Alex Wakizashi wrote: > Still not received an answer about PCI devices with UEFI ROM BIOS > passthrough, which is a major problem, or how to get debug output from > OVMF. > > I'm very interested to make separated OVMF binary and pflash image for > EFI variables, work in XEN. I think this pair of topics would therefore be suitable for the devel list, and perhaps even cross posting to the upstream ovmf/edk2 list (which I know just moved off sf.net, but I'm not sure where too...). > As far as I understand from mentioned thread, this is what Andrew told > about. In this case it would be possible to test different OVMF > modifications without recompilation of XEN. IIRC Andrew would like to make hvmloader multiboot aware, such that it can be passed the BIOS as a payload (loaded by the toolstack) and avoiding the need to build it into hvmloader statically. AFAIAA there has been no work done on this front, but if you were interested in picking it up that would be pretty awesome. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 13:08:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 13:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXGX-0002Tt-TR; Tue, 21 Jul 2015 13:07:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXGW-0002Tj-Af for xen-users@lists.xen.org; Tue, 21 Jul 2015 13:07:24 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id 54/A3-18947-B044EA55; Tue, 21 Jul 2015 13:07:23 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1437484042!33961921!1 X-Originating-IP: [64.12.232.237] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9144 invoked from network); 21 Jul 2015 13:07:22 -0000 Received: from omr-m5.mx.aol.com (HELO omr-m5.mx.aol.com) (64.12.232.237) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 13:07:22 -0000 Received: from mtaout-mad01.mx.aol.com (mtaout-mad01.mx.aol.com [172.26.221.205]) by omr-m5.mx.aol.com (Outbound Mail Relay) with ESMTP id D9A6638000179 for ; Tue, 21 Jul 2015 09:07:21 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 48EA038000091 for ; Tue, 21 Jul 2015 09:07:21 -0400 (EDT) Message-ID: <1437484138.11484.3.camel@aol.com> From: pietrop To: xen-users@lists.xen.org Date: Tue, 21 Jul 2015 14:08:58 +0100 X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1437484041; bh=lll6jfP+WrP496fB8SY8ssGPLUubK/dtQ/eMoH2811E=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=YBYTkHyog4qp/h2sEGfSYeZAPh5167RylRbRcbIlNB4kYGpoXRcBkfUDjbO2Vp148 EtmRVMYuQOotgtH2D3D2NLNtTJBSuklEwBoNrBFPyvNtPYxuF5pOt0mQx0Rsw+NS1E RT4DzOeQTLBezWimLk7FTo/bKYRYlnKtjw9UPCxs= x-aol-sid: 3039ac1addcd55ae440934ed X-AOL-IP: 185.25.64.249 Subject: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, I've accidentally deleted the configuration file of my guest during a clean up, fortunately I am still able to restore and save the guest I was running but I'd like to regenerate the configuration file in order to shut it down and create it again when needed. Apparently I can generate a new config file running the command 'xl list -l ' but that command results in a file format - phyton ? - which is not recognized by the xl tool. I am running Xen 4.4.1 on a Debian 64 bits disto. Any tips ? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 13:08:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 13:08:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXGX-0002Tt-TR; Tue, 21 Jul 2015 13:07:25 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXGW-0002Tj-Af for xen-users@lists.xen.org; Tue, 21 Jul 2015 13:07:24 +0000 Received: from [193.109.254.147] by server-15.bemta-14.messagelabs.com id 54/A3-18947-B044EA55; Tue, 21 Jul 2015 13:07:23 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1437484042!33961921!1 X-Originating-IP: [64.12.232.237] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9144 invoked from network); 21 Jul 2015 13:07:22 -0000 Received: from omr-m5.mx.aol.com (HELO omr-m5.mx.aol.com) (64.12.232.237) by server-15.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 13:07:22 -0000 Received: from mtaout-mad01.mx.aol.com (mtaout-mad01.mx.aol.com [172.26.221.205]) by omr-m5.mx.aol.com (Outbound Mail Relay) with ESMTP id D9A6638000179 for ; Tue, 21 Jul 2015 09:07:21 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mad01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 48EA038000091 for ; Tue, 21 Jul 2015 09:07:21 -0400 (EDT) Message-ID: <1437484138.11484.3.camel@aol.com> From: pietrop To: xen-users@lists.xen.org Date: Tue, 21 Jul 2015 14:08:58 +0100 X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1437484041; bh=lll6jfP+WrP496fB8SY8ssGPLUubK/dtQ/eMoH2811E=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=YBYTkHyog4qp/h2sEGfSYeZAPh5167RylRbRcbIlNB4kYGpoXRcBkfUDjbO2Vp148 EtmRVMYuQOotgtH2D3D2NLNtTJBSuklEwBoNrBFPyvNtPYxuF5pOt0mQx0Rsw+NS1E RT4DzOeQTLBezWimLk7FTo/bKYRYlnKtjw9UPCxs= x-aol-sid: 3039ac1addcd55ae440934ed X-AOL-IP: 185.25.64.249 Subject: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hi all, I've accidentally deleted the configuration file of my guest during a clean up, fortunately I am still able to restore and save the guest I was running but I'd like to regenerate the configuration file in order to shut it down and create it again when needed. Apparently I can generate a new config file running the command 'xl list -l ' but that command results in a file format - phyton ? - which is not recognized by the xl tool. I am running Xen 4.4.1 on a Debian 64 bits disto. Any tips ? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 13:38:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 13:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXjc-0004ya-Df; Tue, 21 Jul 2015 13:37:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXjb-0004yV-BD for xen-users@lists.xen.org; Tue, 21 Jul 2015 13:37:27 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 2B/4A-21115-61B4EA55; Tue, 21 Jul 2015 13:37:26 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1437485844!22653175!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10675 invoked from network); 21 Jul 2015 13:37:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 13:37:25 -0000 X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="282914649" Message-ID: <1437485738.8383.25.camel@citrix.com> From: Ian Campbell To: pietrop , Date: Tue, 21 Jul 2015 14:35:38 +0100 In-Reply-To: <1437484138.11484.3.camel@aol.com> References: <1437484138.11484.3.camel@aol.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 14:08 +0100, pietrop wrote: > Hi all, > > I've accidentally deleted the configuration file of my guest during a > clean up, fortunately I am still able to restore and save the guest I > was running but I'd like to regenerate the configuration file in > order > to shut it down and create it again when needed. > > Apparently I can generate a new config file running the command 'xl > list > -l ' but that command results in a file format - phyton ? - > which is not recognized by the xl tool. It'll be either sxp or json. > I am running Xen 4.4.1 on a Debian 64 bits disto. > > Any tips ? There should be a copy in one of the /var/lib/xen/userdata-* files, I think. If not then I think with 4.4.x the domain config is contained in the save file near the start, so with a suitably tolerant editor you might be able to open it and grab what you need, ignoring the binary bits... Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 13:38:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 13:38:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXjc-0004ya-Df; Tue, 21 Jul 2015 13:37:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHXjb-0004yV-BD for xen-users@lists.xen.org; Tue, 21 Jul 2015 13:37:27 +0000 Received: from [85.158.139.211] by server-13.bemta-5.messagelabs.com id 2B/4A-21115-61B4EA55; Tue, 21 Jul 2015 13:37:26 +0000 X-Env-Sender: prvs=637454ca5=Ian.Campbell@citrix.com X-Msg-Ref: server-13.tower-206.messagelabs.com!1437485844!22653175!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10675 invoked from network); 21 Jul 2015 13:37:25 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-13.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 13:37:25 -0000 X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="282914649" Message-ID: <1437485738.8383.25.camel@citrix.com> From: Ian Campbell To: pietrop , Date: Tue, 21 Jul 2015 14:35:38 +0100 In-Reply-To: <1437484138.11484.3.camel@aol.com> References: <1437484138.11484.3.camel@aol.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 14:08 +0100, pietrop wrote: > Hi all, > > I've accidentally deleted the configuration file of my guest during a > clean up, fortunately I am still able to restore and save the guest I > was running but I'd like to regenerate the configuration file in > order > to shut it down and create it again when needed. > > Apparently I can generate a new config file running the command 'xl > list > -l ' but that command results in a file format - phyton ? - > which is not recognized by the xl tool. It'll be either sxp or json. > I am running Xen 4.4.1 on a Debian 64 bits disto. > > Any tips ? There should be a copy in one of the /var/lib/xen/userdata-* files, I think. If not then I think with 4.4.x the domain config is contained in the save file near the start, so with a suitably tolerant editor you might be able to open it and grab what you need, ignoring the binary bits... Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 14:52:08 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 14:52:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHYtL-00014m-UA; Tue, 21 Jul 2015 14:51:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHYtK-00014K-D2 for xen-users@lists.xen.org; Tue, 21 Jul 2015 14:51:34 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id DB/C3-20690-57C5EA55; Tue, 21 Jul 2015 14:51:33 +0000 X-Env-Sender: Keith.Roberts@ecric.nhs.uk X-Msg-Ref: server-11.tower-206.messagelabs.com!1437490292!18520456!1 X-Originating-IP: [62.208.144.128] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA2Mi4yMDguMTQ0LjEyOCA9PiAxMzI2OTIz\n,sa_preprocessor: QmFkIElQOiA2Mi4yMDguMTQ0LjEyOCA9PiAxMzI2OTIz\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7212 invoked from network); 21 Jul 2015 14:51:32 -0000 Received: from relay.nhs.uk (HELO relay.nhs.uk) (62.208.144.128) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 14:51:32 -0000 Received: from nhs-pd1e-esg103.ad1.nhs.net (nhs-pd1e-esg103.ad1.nhs.net [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 5520431FC6D; Tue, 21 Jul 2015 15:51:27 +0100 (BST) Received: from andromeda.magog.ecric.org.uk (smtp.cpcr.nhs.uk [10.195.239.2]) by nhs-pd1e-esg103.ad1.nhs.net (Postfix) with ESMTP id 7EA0831FB21; Tue, 21 Jul 2015 15:51:24 +0100 (BST) Received: from [158.119.43.108] (158.119.43.108) by andromeda.magog.ecric.org.uk (158.119.43.14) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 21 Jul 2015 15:51:24 +0100 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Keith Roberts In-Reply-To: <20150721132119.CB38E4496A7@nhs-pd1e-esg006.ad1.nhs.net> Date: Tue, 21 Jul 2015 15:51:24 +0100 OLD-MSG-ID: <3B0DE14C-8677-4F60-B933-4736771229D9@ecric.nhs.uk> References: <20150721132119.CB38E4496A7@nhs-pd1e-esg006.ad1.nhs.net> To: pietrop X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [158.119.43.108] Message-Id: <20150721145124.7EA0831FB21@nhs-pd1e-esg103.ad1.nhs.net> X-TM-AS-Product-Ver: IMSVA-8.0.0.1495-8.0.0.1202-21694.000 X-TM-AS-Result: No--22.286-60-31-10 X-imss-scan-details: No--22.286-60-31-10; No--22.286-3-31-10; No--22.286-4-31-10 X-TMASE-MatchedRID: hls5oAVArl8iA21F+hMaQU+ch/KuZSKte66+p3XLeUikTUq6Te4eS8kU hKWc+gwPyEbk0Lyoaik18PpljofaTsEElERnDJHCi82UiskMqcwhwKIIdklOV4KwF4K/wIz9P84 LfIrZUU3GFRTyAp2D0aODywa1e0B4imxB5lXt7967bScJeyAvlgD9xYJNnIwUaRwOL8w79opK9u Atx9Qwj7ceAeUs/txNsSJ+AR8LiUJvGnp4kZisNVoS15Sc+1wzB2Px0PWnGruL+lFNviyszCPTy o5Y6UW7lfqp93dECVN7CRtj4pxOfZcFdomgH0lnvaMRkAFPKY2SiN8MzoBQOPoLR4+zsDTtAqYB E3k9Mpw= Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 21 Jul 2015, at 14:08, pietrop wrote: > Hi all, > = > I've accidentally deleted the configuration file of my guest during a > clean up, fortunately I am still able to restore and save the guest I > was running but I'd like to regenerate the configuration file in order > to shut it down and create it again when needed. > = > Apparently I can generate a new config file running the command 'xl list > -l ' but that command results in a file format - phyton ? - > which is not recognized by the xl tool. > = > I am running Xen 4.4.1 on a Debian 64 bits disto. > = > Any tips ? Hi Pietrop. I=92ve been fiddling with dumping xml configs from a running Xen PV guest. Is this any help at all? ---------------------------------------------------------------------------= ------------------------ From: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu= x/5/html/Virtualization/chap-Virtualization-Managing_guests_with_virsh.html Creating a virtual machine XML dump (configuration file) Output a guest's XML configuration file with virsh: # virsh dumpxml {domain-id, domain-name or domain-uuid} This command outputs the guest's XML configuration file to standard out (st= dout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml: # virsh dumpxml GuestID > guest.xml This file guest.xml can recreate the guest (see Editing a guest's configura= tion file). You can edit this XML configuration file to configure additional devices or to deploy additional guests. See Section 34.1, =93Using XML configuratio= n files with virsh=94 for more information on modifying files created with virsh dumpxml. ---------------------------------------------------------------------------= ------------------------ Kind Regards, Keith Roberts _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 14:52:08 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 14:52:08 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHYtL-00014m-UA; Tue, 21 Jul 2015 14:51:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHYtK-00014K-D2 for xen-users@lists.xen.org; Tue, 21 Jul 2015 14:51:34 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id DB/C3-20690-57C5EA55; Tue, 21 Jul 2015 14:51:33 +0000 X-Env-Sender: Keith.Roberts@ecric.nhs.uk X-Msg-Ref: server-11.tower-206.messagelabs.com!1437490292!18520456!1 X-Originating-IP: [62.208.144.128] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: QmFkIElQOiA2Mi4yMDguMTQ0LjEyOCA9PiAxMzI2OTIz\n,sa_preprocessor: QmFkIElQOiA2Mi4yMDguMTQ0LjEyOCA9PiAxMzI2OTIz\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7212 invoked from network); 21 Jul 2015 14:51:32 -0000 Received: from relay.nhs.uk (HELO relay.nhs.uk) (62.208.144.128) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 14:51:32 -0000 Received: from nhs-pd1e-esg103.ad1.nhs.net (nhs-pd1e-esg103.ad1.nhs.net [127.0.0.1]) by IMSVA80 (Postfix) with ESMTP id 5520431FC6D; Tue, 21 Jul 2015 15:51:27 +0100 (BST) Received: from andromeda.magog.ecric.org.uk (smtp.cpcr.nhs.uk [10.195.239.2]) by nhs-pd1e-esg103.ad1.nhs.net (Postfix) with ESMTP id 7EA0831FB21; Tue, 21 Jul 2015 15:51:24 +0100 (BST) Received: from [158.119.43.108] (158.119.43.108) by andromeda.magog.ecric.org.uk (158.119.43.14) with Microsoft SMTP Server (TLS) id 14.2.347.0; Tue, 21 Jul 2015 15:51:24 +0100 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Keith Roberts In-Reply-To: <20150721132119.CB38E4496A7@nhs-pd1e-esg006.ad1.nhs.net> Date: Tue, 21 Jul 2015 15:51:24 +0100 OLD-MSG-ID: <3B0DE14C-8677-4F60-B933-4736771229D9@ecric.nhs.uk> References: <20150721132119.CB38E4496A7@nhs-pd1e-esg006.ad1.nhs.net> To: pietrop X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [158.119.43.108] Message-Id: <20150721145124.7EA0831FB21@nhs-pd1e-esg103.ad1.nhs.net> X-TM-AS-Product-Ver: IMSVA-8.0.0.1495-8.0.0.1202-21694.000 X-TM-AS-Result: No--22.286-60-31-10 X-imss-scan-details: No--22.286-60-31-10; No--22.286-3-31-10; No--22.286-4-31-10 X-TMASE-MatchedRID: hls5oAVArl8iA21F+hMaQU+ch/KuZSKte66+p3XLeUikTUq6Te4eS8kU hKWc+gwPyEbk0Lyoaik18PpljofaTsEElERnDJHCi82UiskMqcwhwKIIdklOV4KwF4K/wIz9P84 LfIrZUU3GFRTyAp2D0aODywa1e0B4imxB5lXt7967bScJeyAvlgD9xYJNnIwUaRwOL8w79opK9u Atx9Qwj7ceAeUs/txNsSJ+AR8LiUJvGnp4kZisNVoS15Sc+1wzB2Px0PWnGruL+lFNviyszCPTy o5Y6UW7lfqp93dECVN7CRtj4pxOfZcFdomgH0lnvaMRkAFPKY2SiN8MzoBQOPoLR4+zsDTtAqYB E3k9Mpw= Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 21 Jul 2015, at 14:08, pietrop wrote: > Hi all, > = > I've accidentally deleted the configuration file of my guest during a > clean up, fortunately I am still able to restore and save the guest I > was running but I'd like to regenerate the configuration file in order > to shut it down and create it again when needed. > = > Apparently I can generate a new config file running the command 'xl list > -l ' but that command results in a file format - phyton ? - > which is not recognized by the xl tool. > = > I am running Xen 4.4.1 on a Debian 64 bits disto. > = > Any tips ? Hi Pietrop. I=92ve been fiddling with dumping xml configs from a running Xen PV guest. Is this any help at all? ---------------------------------------------------------------------------= ------------------------ From: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linu= x/5/html/Virtualization/chap-Virtualization-Managing_guests_with_virsh.html Creating a virtual machine XML dump (configuration file) Output a guest's XML configuration file with virsh: # virsh dumpxml {domain-id, domain-name or domain-uuid} This command outputs the guest's XML configuration file to standard out (st= dout). You can save the data by piping the output to a file. An example of piping the output to a file called guest.xml: # virsh dumpxml GuestID > guest.xml This file guest.xml can recreate the guest (see Editing a guest's configura= tion file). You can edit this XML configuration file to configure additional devices or to deploy additional guests. See Section 34.1, =93Using XML configuratio= n files with virsh=94 for more information on modifying files created with virsh dumpxml. ---------------------------------------------------------------------------= ------------------------ Kind Regards, Keith Roberts _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 15:19:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 15:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHZK2-0003eI-EU; Tue, 21 Jul 2015 15:19:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHZK1-0003eD-8i for xen-users@lists.xen.org; Tue, 21 Jul 2015 15:19:09 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 28/02-20690-CE26EA55; Tue, 21 Jul 2015 15:19:08 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437491947!17242430!1 X-Originating-IP: [64.12.232.237] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9645 invoked from network); 21 Jul 2015 15:19:08 -0000 Received: from omr-m5.mx.aol.com (HELO omr-m5.mx.aol.com) (64.12.232.237) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 15:19:08 -0000 Received: from mtaout-mbd02.mx.aol.com (mtaout-mbd02.mx.aol.com [172.26.252.14]) by omr-m5.mx.aol.com (Outbound Mail Relay) with ESMTP id 2A01F38000187; Tue, 21 Jul 2015 11:19:07 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mbd02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7F93E3800008E; Tue, 21 Jul 2015 11:19:06 -0400 (EDT) Message-ID: <1437492047.11484.7.camel@aol.com> From: pietrop To: Ian Campbell Date: Tue, 21 Jul 2015 16:20:47 +0100 In-Reply-To: <1437485738.8383.25.camel@citrix.com> References: <1437484138.11484.3.camel@aol.com> <1437485738.8383.25.camel@citrix.com> X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1437491947; bh=yEpt9YewFimMyUcUKY5yzopd1wkexZmysM5lKkeRREU=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=eltXoBW4TtxbcH8Oj9g1eioIk4ph3vNvF7JsgIulAE4Kzc+jkqXx/f1KoViLZjUN8 K/QtVBxo+l52UOJockSaGYl8uQn3ch9CJDChsa9YgQClRRqg3IxyDQ2FR9segOxpIl 4TI19+bIqNEkokCxc+yubiAe+R/J8n1K7kvmN1c0= x-aol-sid: 3039ac1afc0e55ae62ea20a7 X-AOL-IP: 185.25.64.249 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 14:35 +0100, Ian Campbell wrote: > If not then I think with 4.4.x the domain config is contained in the > save file near the start, so with a suitably tolerant editor you might > be able to open it and grab what you need, ignoring the binary bits... > > Ian. Thanks a lot, it was there. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 15:19:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 15:19:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHZK2-0003eI-EU; Tue, 21 Jul 2015 15:19:10 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHZK1-0003eD-8i for xen-users@lists.xen.org; Tue, 21 Jul 2015 15:19:09 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 28/02-20690-CE26EA55; Tue, 21 Jul 2015 15:19:08 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437491947!17242430!1 X-Originating-IP: [64.12.232.237] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9645 invoked from network); 21 Jul 2015 15:19:08 -0000 Received: from omr-m5.mx.aol.com (HELO omr-m5.mx.aol.com) (64.12.232.237) by server-14.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Jul 2015 15:19:08 -0000 Received: from mtaout-mbd02.mx.aol.com (mtaout-mbd02.mx.aol.com [172.26.252.14]) by omr-m5.mx.aol.com (Outbound Mail Relay) with ESMTP id 2A01F38000187; Tue, 21 Jul 2015 11:19:07 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mbd02.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id 7F93E3800008E; Tue, 21 Jul 2015 11:19:06 -0400 (EDT) Message-ID: <1437492047.11484.7.camel@aol.com> From: pietrop To: Ian Campbell Date: Tue, 21 Jul 2015 16:20:47 +0100 In-Reply-To: <1437485738.8383.25.camel@citrix.com> References: <1437484138.11484.3.camel@aol.com> <1437485738.8383.25.camel@citrix.com> X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1437491947; bh=yEpt9YewFimMyUcUKY5yzopd1wkexZmysM5lKkeRREU=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=eltXoBW4TtxbcH8Oj9g1eioIk4ph3vNvF7JsgIulAE4Kzc+jkqXx/f1KoViLZjUN8 K/QtVBxo+l52UOJockSaGYl8uQn3ch9CJDChsa9YgQClRRqg3IxyDQ2FR9segOxpIl 4TI19+bIqNEkokCxc+yubiAe+R/J8n1K7kvmN1c0= x-aol-sid: 3039ac1afc0e55ae62ea20a7 X-AOL-IP: 185.25.64.249 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] Configuration file guest deleted X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 14:35 +0100, Ian Campbell wrote: > If not then I think with 4.4.x the domain config is contained in the > save file near the start, so with a suitably tolerant editor you might > be able to open it and grab what you need, ignoring the binary bits... > > Ian. Thanks a lot, it was there. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 21 21:30:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 21:30:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHf6D-0006eQ-VM; Tue, 21 Jul 2015 21:29:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHf6D-0006eL-3R for xen-users@lists.xen.org; Tue, 21 Jul 2015 21:29:17 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id CB/00-06739-CA9BEA55; Tue, 21 Jul 2015 21:29:16 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1437514154!34104383!1 X-Originating-IP: [209.85.223.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_IMAGE_RATIO_04, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10577 invoked from network); 21 Jul 2015 21:29:15 -0000 Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 21:29:15 -0000 Received: by ietj16 with SMTP id j16so153048112iet.0 for ; Tue, 21 Jul 2015 14:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=VwTE200WpZj+HTJkgPKBz/LCMhMZ7/NPPbL3iua0PWo=; b=kuoezu4GR1qXDglyoS7fbnNlIrdOuhOs0sLvRi39V6thECcOWJEGqFPTZEKtJukVH8 43aTlTPNrpZa79GGW9iIR3VFq68/U5ADgBq3gtvngE8QOPgHJ0ZrbDAal0l6bTTuj7GK RucdBUO6iB6XXtACuLsf1NuAM8+PL/kP/2T6sVeBFP1izJMqs8a9VmvdKRISOH6zGKuh qJeCK0wC7u3cVxcreatFXyDRTz04Hmn9sn77KcqYa6LAzupR3sf0kneQsgXKeCftGlL+ 4FDPlE+ZlvdLwluLJNEs9q3XPzlXCj4sry6oymDWERN+AT1rX4Nl1mOphe93YeQiMe6u Loaw== X-Gm-Message-State: ALoCoQlB39ALUHwGe31ZVz9YRsOhFsje/Z90bjVnHXNbAd+RAWhCm92rktW3WmrL3gQ5sJyN+r4m X-Received: by 10.107.136.160 with SMTP id s32mr50298644ioi.174.1437514153937; Tue, 21 Jul 2015 14:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Tue, 21 Jul 2015 14:28:54 -0700 (PDT) From: Gabriel Queiroz Silva Date: Tue, 21 Jul 2015 18:28:54 -0300 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7997772995949087753==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7997772995949087753== Content-Type: multipart/alternative; boundary=001a113ecffe817d80051b695899 --001a113ecffe817d80051b695899 Content-Type: text/plain; charset=UTF-8 Hi, I have around 10 VMs running on two XCP 1.6 servers, and i'm planning to upgrade both of them to XS. How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any stories of people losing data when applying this upgrade? Thanks, Gabriel *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com --001a113ecffe817d80051b695899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,


I have around 10 VMs running on two XCP 1.6 servers, and i'm plann= ing to upgrade both of them to XS.


How safe is it to upgrade a XCP 1.6 to a XS 6.2= ? Are there any stories of people losing data when applying this upgrade?=C2=A0

=C2=A0

Thanks,

Gabriel

<= div class=3D"gmail_signature">

Gabriel Queiroz

+55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www.flowecommerce.com<= /u>

=C2=A0

--001a113ecffe817d80051b695899-- --===============7997772995949087753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7997772995949087753==-- From xen-users-bounces@lists.xen.org Tue Jul 21 21:30:37 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 21 Jul 2015 21:30:37 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHf6D-0006eQ-VM; Tue, 21 Jul 2015 21:29:17 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHf6D-0006eL-3R for xen-users@lists.xen.org; Tue, 21 Jul 2015 21:29:17 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id CB/00-06739-CA9BEA55; Tue, 21 Jul 2015 21:29:16 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1437514154!34104383!1 X-Originating-IP: [209.85.223.170] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_IMAGE_RATIO_04, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 10577 invoked from network); 21 Jul 2015 21:29:15 -0000 Received: from mail-ie0-f170.google.com (HELO mail-ie0-f170.google.com) (209.85.223.170) by server-12.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 21 Jul 2015 21:29:15 -0000 Received: by ietj16 with SMTP id j16so153048112iet.0 for ; Tue, 21 Jul 2015 14:29:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=VwTE200WpZj+HTJkgPKBz/LCMhMZ7/NPPbL3iua0PWo=; b=kuoezu4GR1qXDglyoS7fbnNlIrdOuhOs0sLvRi39V6thECcOWJEGqFPTZEKtJukVH8 43aTlTPNrpZa79GGW9iIR3VFq68/U5ADgBq3gtvngE8QOPgHJ0ZrbDAal0l6bTTuj7GK RucdBUO6iB6XXtACuLsf1NuAM8+PL/kP/2T6sVeBFP1izJMqs8a9VmvdKRISOH6zGKuh qJeCK0wC7u3cVxcreatFXyDRTz04Hmn9sn77KcqYa6LAzupR3sf0kneQsgXKeCftGlL+ 4FDPlE+ZlvdLwluLJNEs9q3XPzlXCj4sry6oymDWERN+AT1rX4Nl1mOphe93YeQiMe6u Loaw== X-Gm-Message-State: ALoCoQlB39ALUHwGe31ZVz9YRsOhFsje/Z90bjVnHXNbAd+RAWhCm92rktW3WmrL3gQ5sJyN+r4m X-Received: by 10.107.136.160 with SMTP id s32mr50298644ioi.174.1437514153937; Tue, 21 Jul 2015 14:29:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Tue, 21 Jul 2015 14:28:54 -0700 (PDT) From: Gabriel Queiroz Silva Date: Tue, 21 Jul 2015 18:28:54 -0300 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7997772995949087753==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7997772995949087753== Content-Type: multipart/alternative; boundary=001a113ecffe817d80051b695899 --001a113ecffe817d80051b695899 Content-Type: text/plain; charset=UTF-8 Hi, I have around 10 VMs running on two XCP 1.6 servers, and i'm planning to upgrade both of them to XS. How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any stories of people losing data when applying this upgrade? Thanks, Gabriel *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com --001a113ecffe817d80051b695899 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,


I have around 10 VMs running on two XCP 1.6 servers, and i'm plann= ing to upgrade both of them to XS.


How safe is it to upgrade a XCP 1.6 to a XS 6.2= ? Are there any stories of people losing data when applying this upgrade?=C2=A0

=C2=A0

Thanks,

Gabriel

<= div class=3D"gmail_signature">

Gabriel Queiroz

+55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www.flowecommerce.com<= /u>

=C2=A0

--001a113ecffe817d80051b695899-- --===============7997772995949087753== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7997772995949087753==-- From xen-users-bounces@lists.xen.org Wed Jul 22 09:44:32 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 09:44:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHqYl-0007Xk-4x; Wed, 22 Jul 2015 09:43:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHqYj-0007Xf-FF for xen-users@lists.xen.org; Wed, 22 Jul 2015 09:43:29 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 2C/24-31258-0C56FA55; Wed, 22 Jul 2015 09:43:28 +0000 X-Env-Sender: prvs=638d64336=Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1437558207!34234562!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27726 invoked from network); 22 Jul 2015 09:43:28 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 09:43:28 -0000 X-IronPort-AV: E=Sophos;i="5.15,522,1432598400"; d="scan'208";a="286406988" Message-ID: <1437558204.8383.68.camel@citrix.com> From: Ian Campbell To: Gabriel Queiroz Silva , Date: Wed, 22 Jul 2015 10:43:24 +0100 In-Reply-To: References: X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queiroz Silva wrote: > > I have around 10 VMs running on two XCP 1.6 servers, and i'm planning > to upgrade both of them to XS. > > How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any > stories of people losing data when applying this upgrade? Hi Gabriel, This list deals primarily with the Xen Project releases of Xen and the associated toolstacks. XS is a separate project and questions regarding XS (which subsumed XCP) are better asked on the lists/forums over at www.xenserver.org. FWIW I've not heard of any problems, but then I wouldn't necessarily expect to have done so. Obviously having up to date backups of a system is good practice whether that system is virtualised or not. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 22 09:44:32 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 09:44:32 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHqYl-0007Xk-4x; Wed, 22 Jul 2015 09:43:31 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHqYj-0007Xf-FF for xen-users@lists.xen.org; Wed, 22 Jul 2015 09:43:29 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 2C/24-31258-0C56FA55; Wed, 22 Jul 2015 09:43:28 +0000 X-Env-Sender: prvs=638d64336=Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-27.messagelabs.com!1437558207!34234562!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27726 invoked from network); 22 Jul 2015 09:43:28 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-14.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 09:43:28 -0000 X-IronPort-AV: E=Sophos;i="5.15,522,1432598400"; d="scan'208";a="286406988" Message-ID: <1437558204.8383.68.camel@citrix.com> From: Ian Campbell To: Gabriel Queiroz Silva , Date: Wed, 22 Jul 2015 10:43:24 +0100 In-Reply-To: References: X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queiroz Silva wrote: > > I have around 10 VMs running on two XCP 1.6 servers, and i'm planning > to upgrade both of them to XS. > > How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any > stories of people losing data when applying this upgrade? Hi Gabriel, This list deals primarily with the Xen Project releases of Xen and the associated toolstacks. XS is a separate project and questions regarding XS (which subsumed XCP) are better asked on the lists/forums over at www.xenserver.org. FWIW I've not heard of any problems, but then I wouldn't necessarily expect to have done so. Obviously having up to date backups of a system is good practice whether that system is virtualised or not. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 22 10:19:54 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 10:19:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHr7D-00040g-71; Wed, 22 Jul 2015 10:19:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHr7B-00040Z-WD for xen-users@lists.xen.org; Wed, 22 Jul 2015 10:19:06 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id DC/6F-28408-91E6FA55; Wed, 22 Jul 2015 10:19:05 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1437560342!28039959!1 X-Originating-IP: [209.85.223.169] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26193 invoked from network); 22 Jul 2015 10:19:03 -0000 Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 10:19:03 -0000 Received: by iecri3 with SMTP id ri3so68758034iec.2 for ; Wed, 22 Jul 2015 03:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Kp1kXNvZjC/60rR8vAac3K7JgV8HWvwr0KahR6lbTSQ=; b=cRYeY+3DXwzgh1X3azuCru27cWDeytVLjNg7473aSjPMUwnjFIwDNT9fbi8BGL3vY2 g3L+qnNOPfVRvwYDj7kCCQh3IudcUJOhvYRUFyAPirpr77BQ4gWVfCPKdnrscSNbUDlS ptaWRfvWFrk0gHKtpUxE5cb5Iqr/rJhgzOqi/b33yLDJiPwDASwpKT69sXvxwY/BsfYs H7Pc9Fr41tU8op/6TzX1g7NJv2Yd/d7gx0Bb26fpBVMvOdKc17u50HgX7//ktvMhxR2p P4tV9x78HOzRAeC1aag2TNNtqfCwfrIXQLMfxBZS4erxgFOtn+7PVKUF4BrOaTl52BCs HNRA== X-Gm-Message-State: ALoCoQluTIS3310Ry0zmmwTgxodiSgnVE3I9/Uqzanpys97sZ7UxXljqCs/AciIi6ppsRDfmDKbx X-Received: by 10.50.44.100 with SMTP id d4mr4058196igm.67.1437560341894; Wed, 22 Jul 2015 03:19:01 -0700 (PDT) MIME-Version: 1.0 References: <1437558204.8383.68.camel@citrix.com> In-Reply-To: <1437558204.8383.68.camel@citrix.com> From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 10:18:52 +0000 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9148795775972187482==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9148795775972187482== Content-Type: multipart/alternative; boundary=e89a8f839f9185b12b051b741982 --e89a8f839f9185b12b051b741982 Content-Type: text/plain; charset=UTF-8 On Wed, 22 Jul 2015 06:43 Ian Campbell wrote: On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queiroz Silva wrote: > > I have around 10 VMs running on two XCP 1.6 servers, and i'm planning > to upgrade both of them to XS. > > How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any > stories of people losing data when applying this upgrade? Hi Gabriel, This list deals primarily with the Xen Project releases of Xen and the associated toolstacks. XS is a separate project and questions regarding XS (which subsumed XCP) are better asked on the lists/forums over at www.xenserver.org. FWIW I've not heard of any problems, but then I wouldn't necessarily expect to have done so. Obviously having up to date backups of a system is good practice whether that system is virtualised or not. Ian. Hi Ian, Thanks for your reply. I have already asked XCP questions there before and have been recommended to try these lists instead. Anyway, if by any chance someone could point me to any material regarding this migration I would be extremely thankful. Regards, Gabriel --e89a8f839f9185b12b051b741982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, 22 Jul 2015 06:43=C2=A0Ian Campbell <ian.campbell@citrix.com> wrote:

On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queir= oz Silva wrote:
>
> I have around 10 VMs running on two XCP 1.6 servers, and i'm plann= ing
> to upgrade both of them to XS.
>
> How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any
> stories of people losing data when applying this upgrade?

Hi Gabriel,

This list deals primarily with the Xen Project releases of X= en and the
associated toolstacks. XS is a separate project and questions regarding
XS (which subsumed XCP) are better asked on the lists/forums over at
www.xenserver.org.

FWIW I've not heard of any problems, but then I wouldn&#= 39;t necessarily
expect to have done so.

Obviously having up to date backups of a system is good prac= tice
whether that system is virtualised or not.

Ian.


Hi Ian,

Thanks for your reply.

I have already asked XCP questions there before and have bee= n recommended to try these lists instead.

Anyway, if by any chance someone could point me to any mater= ial regarding this migration I would be extremely thankful.

Regards,
Gabriel


--e89a8f839f9185b12b051b741982-- --===============9148795775972187482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9148795775972187482==-- From xen-users-bounces@lists.xen.org Wed Jul 22 10:19:54 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 10:19:54 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHr7D-00040g-71; Wed, 22 Jul 2015 10:19:07 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHr7B-00040Z-WD for xen-users@lists.xen.org; Wed, 22 Jul 2015 10:19:06 +0000 Received: from [85.158.137.68] by server-15.bemta-3.messagelabs.com id DC/6F-28408-91E6FA55; Wed, 22 Jul 2015 10:19:05 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1437560342!28039959!1 X-Originating-IP: [209.85.223.169] X-SpamReason: No, hits=0.9 required=7.0 tests=HTML_20_30,HTML_MESSAGE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26193 invoked from network); 22 Jul 2015 10:19:03 -0000 Received: from mail-ie0-f169.google.com (HELO mail-ie0-f169.google.com) (209.85.223.169) by server-15.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 10:19:03 -0000 Received: by iecri3 with SMTP id ri3so68758034iec.2 for ; Wed, 22 Jul 2015 03:19:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=Kp1kXNvZjC/60rR8vAac3K7JgV8HWvwr0KahR6lbTSQ=; b=cRYeY+3DXwzgh1X3azuCru27cWDeytVLjNg7473aSjPMUwnjFIwDNT9fbi8BGL3vY2 g3L+qnNOPfVRvwYDj7kCCQh3IudcUJOhvYRUFyAPirpr77BQ4gWVfCPKdnrscSNbUDlS ptaWRfvWFrk0gHKtpUxE5cb5Iqr/rJhgzOqi/b33yLDJiPwDASwpKT69sXvxwY/BsfYs H7Pc9Fr41tU8op/6TzX1g7NJv2Yd/d7gx0Bb26fpBVMvOdKc17u50HgX7//ktvMhxR2p P4tV9x78HOzRAeC1aag2TNNtqfCwfrIXQLMfxBZS4erxgFOtn+7PVKUF4BrOaTl52BCs HNRA== X-Gm-Message-State: ALoCoQluTIS3310Ry0zmmwTgxodiSgnVE3I9/Uqzanpys97sZ7UxXljqCs/AciIi6ppsRDfmDKbx X-Received: by 10.50.44.100 with SMTP id d4mr4058196igm.67.1437560341894; Wed, 22 Jul 2015 03:19:01 -0700 (PDT) MIME-Version: 1.0 References: <1437558204.8383.68.camel@citrix.com> In-Reply-To: <1437558204.8383.68.camel@citrix.com> From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 10:18:52 +0000 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============9148795775972187482==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============9148795775972187482== Content-Type: multipart/alternative; boundary=e89a8f839f9185b12b051b741982 --e89a8f839f9185b12b051b741982 Content-Type: text/plain; charset=UTF-8 On Wed, 22 Jul 2015 06:43 Ian Campbell wrote: On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queiroz Silva wrote: > > I have around 10 VMs running on two XCP 1.6 servers, and i'm planning > to upgrade both of them to XS. > > How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any > stories of people losing data when applying this upgrade? Hi Gabriel, This list deals primarily with the Xen Project releases of Xen and the associated toolstacks. XS is a separate project and questions regarding XS (which subsumed XCP) are better asked on the lists/forums over at www.xenserver.org. FWIW I've not heard of any problems, but then I wouldn't necessarily expect to have done so. Obviously having up to date backups of a system is good practice whether that system is virtualised or not. Ian. Hi Ian, Thanks for your reply. I have already asked XCP questions there before and have been recommended to try these lists instead. Anyway, if by any chance someone could point me to any material regarding this migration I would be extremely thankful. Regards, Gabriel --e89a8f839f9185b12b051b741982 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, 22 Jul 2015 06:43=C2=A0Ian Campbell <ian.campbell@citrix.com> wrote:

On Tue, 2015-07-21 at 18:28 -0300, Gabriel Queir= oz Silva wrote:
>
> I have around 10 VMs running on two XCP 1.6 servers, and i'm plann= ing
> to upgrade both of them to XS.
>
> How safe is it to upgrade a XCP 1.6 to a XS 6.2? Are there any
> stories of people losing data when applying this upgrade?

Hi Gabriel,

This list deals primarily with the Xen Project releases of X= en and the
associated toolstacks. XS is a separate project and questions regarding
XS (which subsumed XCP) are better asked on the lists/forums over at
www.xenserver.org.

FWIW I've not heard of any problems, but then I wouldn&#= 39;t necessarily
expect to have done so.

Obviously having up to date backups of a system is good prac= tice
whether that system is virtualised or not.

Ian.


Hi Ian,

Thanks for your reply.

I have already asked XCP questions there before and have bee= n recommended to try these lists instead.

Anyway, if by any chance someone could point me to any mater= ial regarding this migration I would be extremely thankful.

Regards,
Gabriel


--e89a8f839f9185b12b051b741982-- --===============9148795775972187482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============9148795775972187482==-- From xen-users-bounces@lists.xen.org Wed Jul 22 10:39:57 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 10:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHrR4-0005sO-7z; Wed, 22 Jul 2015 10:39:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHrR2-0005sJ-LR for xen-users@lists.xen.org; Wed, 22 Jul 2015 10:39:36 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 12/66-31650-7E27FA55; Wed, 22 Jul 2015 10:39:35 +0000 X-Env-Sender: prvs=638d64336=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1437561573!34249265!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16602 invoked from network); 22 Jul 2015 10:39:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 10:39:34 -0000 X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="283255086" Message-ID: <1437561546.12884.19.camel@citrix.com> From: Ian Campbell To: Gabriel Queiroz Silva , Date: Wed, 22 Jul 2015 11:39:06 +0100 In-Reply-To: References: <1437558204.8383.68.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: > I have already asked XCP questions there before and have been > recommended to try these lists instead. For a pure XCP question that is probably correct, however for an upgrade to XenServer I think the xenserver.org resources are going to be the most likely place you will find help. > Anyway, if by any chance someone could point me to any material > regarding this migration I would be extremely thankful. I don't have anything myself. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 22 10:39:57 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 10:39:57 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHrR4-0005sO-7z; Wed, 22 Jul 2015 10:39:38 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHrR2-0005sJ-LR for xen-users@lists.xen.org; Wed, 22 Jul 2015 10:39:36 +0000 Received: from [193.109.254.147] by server-16.bemta-14.messagelabs.com id 12/66-31650-7E27FA55; Wed, 22 Jul 2015 10:39:35 +0000 X-Env-Sender: prvs=638d64336=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1437561573!34249265!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16602 invoked from network); 22 Jul 2015 10:39:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 10:39:34 -0000 X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="283255086" Message-ID: <1437561546.12884.19.camel@citrix.com> From: Ian Campbell To: Gabriel Queiroz Silva , Date: Wed, 22 Jul 2015 11:39:06 +0100 In-Reply-To: References: <1437558204.8383.68.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: > I have already asked XCP questions there before and have been > recommended to try these lists instead. For a pure XCP question that is probably correct, however for an upgrade to XenServer I think the xenserver.org resources are going to be the most likely place you will find help. > Anyway, if by any chance someone could point me to any material > regarding this migration I would be extremely thankful. I don't have anything myself. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 22 11:56:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 11:56:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHscs-00043I-PZ; Wed, 22 Jul 2015 11:55:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHscr-00043D-KI for xen-users@lists.xen.org; Wed, 22 Jul 2015 11:55:53 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 16/21-30658-8C48FA55; Wed, 22 Jul 2015 11:55:52 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1437566150!26684378!1 X-Originating-IP: [209.85.223.178] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31477 invoked from network); 22 Jul 2015 11:55:51 -0000 Received: from mail-ie0-f178.google.com (HELO mail-ie0-f178.google.com) (209.85.223.178) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 11:55:51 -0000 Received: by iecri3 with SMTP id ri3so70394855iec.2 for ; Wed, 22 Jul 2015 04:55:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=paw0+gBE5xIs7ZQV/HONNZetjzbPzobTCvg8ZyrypTU=; b=Krd2s6gxzXNltJKHC27MiIpQKOartEYZYgWvzNtE8CSERNMiA/ZSsblfcxAK6eEY4v kL4k0cZkvPNm1GdqBANTdheVUh1VDRuqkUpW16uMHASU+C+heRm9jwLK0bIpzlmWhWtK Vhvd6lApSg8HLzD4aTCOT1N9fQF9CW2dia60Ux7YRjqyySTHyHGl4P6AKhbLD6OY2DGx 3FukUPUIG6SDNsd5M28fBR8rwSe38vU0Uimxq6fBXYHPXWXLMYAeVyY+D07jG9N20LoY W/Ov6qcajqc45TBSM4ZneLg9UF2saYsNLWTM5+1LPlspYkdrGIUdm/P6CMwq7f86dPh5 BXSA== X-Gm-Message-State: ALoCoQk8UdLEDMoBWLppZxf0Cs80F3kqqgEmJ31sCGdGBED2STFSnNGTdQT9LaOPVkjsfdB96sZ9 X-Received: by 10.50.225.35 with SMTP id rh3mr33708368igc.29.1437566150503; Wed, 22 Jul 2015 04:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Wed, 22 Jul 2015 04:55:31 -0700 (PDT) In-Reply-To: <1437561546.12884.19.camel@citrix.com> References: <1437558204.8383.68.camel@citrix.com> <1437561546.12884.19.camel@citrix.com> From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 08:55:31 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1816470127468385507==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1816470127468385507== Content-Type: multipart/alternative; boundary=001a1132f214be5351051b757376 --001a1132f214be5351051b757376 Content-Type: text/plain; charset=UTF-8 Thanks Ian. Will try there again. *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 7:39 GMT-03:00 Ian Campbell : > On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: > > I have already asked XCP questions there before and have been > > recommended to try these lists instead. > > For a pure XCP question that is probably correct, however for an > upgrade to XenServer I think the xenserver.org resources are going to > be the most likely place you will find help. > > > Anyway, if by any chance someone could point me to any material > > regarding this migration I would be extremely thankful. > > I don't have anything myself. > > Ian. > --001a1132f214be5351051b757376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Ian. Will try there again.


2015-07-22 7:39 GMT-03:00 Ian Campbell <ian.campbell@citrix.com>:
On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva= wrote:
> I have already asked XCP questions there before and have been
> recommended to try these lists instead.

For a pure XCP question that is probably correct, however for an
upgrade to XenServer I think the xenserver.org resources are going to
be the most likely place you will find help.

> Anyway, if by any chance someone could point me to any material
> regarding this migration I would be extremely thankful.

I don't have anything myself.

Ian.

--001a1132f214be5351051b757376-- --===============1816470127468385507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1816470127468385507==-- From xen-users-bounces@lists.xen.org Wed Jul 22 11:56:34 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 11:56:34 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHscs-00043I-PZ; Wed, 22 Jul 2015 11:55:54 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHscr-00043D-KI for xen-users@lists.xen.org; Wed, 22 Jul 2015 11:55:53 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id 16/21-30658-8C48FA55; Wed, 22 Jul 2015 11:55:52 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-16.tower-27.messagelabs.com!1437566150!26684378!1 X-Originating-IP: [209.85.223.178] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31477 invoked from network); 22 Jul 2015 11:55:51 -0000 Received: from mail-ie0-f178.google.com (HELO mail-ie0-f178.google.com) (209.85.223.178) by server-16.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 11:55:51 -0000 Received: by iecri3 with SMTP id ri3so70394855iec.2 for ; Wed, 22 Jul 2015 04:55:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=paw0+gBE5xIs7ZQV/HONNZetjzbPzobTCvg8ZyrypTU=; b=Krd2s6gxzXNltJKHC27MiIpQKOartEYZYgWvzNtE8CSERNMiA/ZSsblfcxAK6eEY4v kL4k0cZkvPNm1GdqBANTdheVUh1VDRuqkUpW16uMHASU+C+heRm9jwLK0bIpzlmWhWtK Vhvd6lApSg8HLzD4aTCOT1N9fQF9CW2dia60Ux7YRjqyySTHyHGl4P6AKhbLD6OY2DGx 3FukUPUIG6SDNsd5M28fBR8rwSe38vU0Uimxq6fBXYHPXWXLMYAeVyY+D07jG9N20LoY W/Ov6qcajqc45TBSM4ZneLg9UF2saYsNLWTM5+1LPlspYkdrGIUdm/P6CMwq7f86dPh5 BXSA== X-Gm-Message-State: ALoCoQk8UdLEDMoBWLppZxf0Cs80F3kqqgEmJ31sCGdGBED2STFSnNGTdQT9LaOPVkjsfdB96sZ9 X-Received: by 10.50.225.35 with SMTP id rh3mr33708368igc.29.1437566150503; Wed, 22 Jul 2015 04:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Wed, 22 Jul 2015 04:55:31 -0700 (PDT) In-Reply-To: <1437561546.12884.19.camel@citrix.com> References: <1437558204.8383.68.camel@citrix.com> <1437561546.12884.19.camel@citrix.com> From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 08:55:31 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1816470127468385507==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1816470127468385507== Content-Type: multipart/alternative; boundary=001a1132f214be5351051b757376 --001a1132f214be5351051b757376 Content-Type: text/plain; charset=UTF-8 Thanks Ian. Will try there again. *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 7:39 GMT-03:00 Ian Campbell : > On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: > > I have already asked XCP questions there before and have been > > recommended to try these lists instead. > > For a pure XCP question that is probably correct, however for an > upgrade to XenServer I think the xenserver.org resources are going to > be the most likely place you will find help. > > > Anyway, if by any chance someone could point me to any material > > regarding this migration I would be extremely thankful. > > I don't have anything myself. > > Ian. > --001a1132f214be5351051b757376 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Ian. Will try there again.


2015-07-22 7:39 GMT-03:00 Ian Campbell <ian.campbell@citrix.com>:
On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva= wrote:
> I have already asked XCP questions there before and have been
> recommended to try these lists instead.

For a pure XCP question that is probably correct, however for an
upgrade to XenServer I think the xenserver.org resources are going to
be the most likely place you will find help.

> Anyway, if by any chance someone could point me to any material
> regarding this migration I would be extremely thankful.

I don't have anything myself.

Ian.

--001a1132f214be5351051b757376-- --===============1816470127468385507== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1816470127468385507==-- From xen-users-bounces@lists.xen.org Wed Jul 22 12:00:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 12:00:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHshH-0004t7-Jt; Wed, 22 Jul 2015 12:00:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHshG-0004sw-Cw for xen-users@lists.xen.org; Wed, 22 Jul 2015 12:00:26 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id ED/49-12200-9D58FA55; Wed, 22 Jul 2015 12:00:25 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437566423!17465095!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=2.1 required=7.0 tests=HOT_NASTY,HTML_40_50, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4620 invoked from network); 22 Jul 2015 12:00:24 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 12:00:24 -0000 Received: by iebmu5 with SMTP id mu5so164973990ieb.1 for ; Wed, 22 Jul 2015 05:00:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=wfjdzgbW3wYAM1VprQ0fybZZjbJ/beRE8aQv3C1nDM0=; b=Xhj2dSyVJnWOia/KL7aOZcaH9Oq+OFzmUqjQFZQ++suTRB2kT8JapVYxnlcyAlTwE0 FOVWLrk1oQ5ZVJ/PMEMzh7E5l7JCzFuWb4iHEiqQSmlIy81R8Tt/QJ0l/GGXNo3GeV3N cn81EcRPgJeMKzwWjy2YEJMkfKRW7SZpXD3D3rHVAdPYPF0/eOUHTp+ZOzZK3nHI1RC/ Hvq4ublFb1s8KYKTxACiC95qajAuPKR14BPlsGUpiETSdjKZ1w/SEBhoDhqbODXctdV+ 5vFtqUybRlEsGGUX2652vQe2sbE8T1KiRhiAFuL4ftRFgU/DhJ0cB0VD2n5yrfHDAK8Q /XpQ== X-Gm-Message-State: ALoCoQlFEOK2lJ3vF4A8jfafwBZYvN149B+e/RFhSHZ//ibmw0Ti0PkVpocllxcFD5f04ucE+6zc X-Received: by 10.50.62.106 with SMTP id x10mr5192463igr.29.1437566421960; Wed, 22 Jul 2015 05:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Wed, 22 Jul 2015 05:00:02 -0700 (PDT) From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 09:00:02 -0300 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] No network on VM after migrating to another xcp server on the same pool X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4103995207837731356==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4103995207837731356== Content-Type: multipart/alternative; boundary=047d7b3a8218ec3217051b7583d0 --047d7b3a8218ec3217051b7583d0 Content-Type: text/plain; charset=UTF-8 Hi, I have migrated one ubuntu VM from one XCP 1.6 server to another. After doing this, this VM is not able to connect to the networks as before. I have kept IP and MAC Addresses the same. After running ifconfig, i can see the interface as follows: *eth0 Link encap:Ethernet HWaddr YYY * * inet addr:XXXX Bcast:XXXX Mask:255.255.255.192* * inet6 addr: XXXXXX/64 Scope:Link* * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* * RX packets:0 errors:0 dropped:0 overruns:0 frame:0* * TX packets:319 errors:0 dropped:0 overruns:0 carrier:0* * collisions:0 txqueuelen:1000 * * RX bytes:0 (0.0 B) TX bytes:13614 (13.6 KB)* * Interrupt:68 * *lo Link encap:Local Loopback * * inet addr:127.0.0.1 Mask:255.0.0.0* * inet6 addr: ::1/128 Scope:Host* * UP LOOPBACK RUNNING MTU:16436 Metric:1* * RX packets:679 errors:0 dropped:0 overruns:0 frame:0* * TX packets:679 errors:0 dropped:0 overruns:0 carrier:0* * collisions:0 txqueuelen:0 * * RX bytes:3985002 (3.9 MB) TX bytes:3985002 (3.9 MB)* Bringing down and up the eth0 interface works, as follows: *root@xx:~# ifdown -v eth0* *Configuring interface eth0=eth0 (inet)* *run-parts --verbose /etc/network/if-down.d* *run-parts: executing /etc/network/if-down.d/resolvconf* *run-parts: executing /etc/network/if-down.d/sendmail* *run-parts: executing /etc/network/if-down.d/upstart* *run-parts: executing /etc/network/if-down.d/wpasupplicant* *ip route del default via XXX metric 100 dev eth0 2>&1 1>/dev/null || true * *ip -4 addr flush dev eth0 label eth0* *ip link set dev eth0 down* *run-parts --verbose /etc/network/if-post-down.d* *run-parts: executing /etc/network/if-post-down.d/sendmail* *run-parts: executing /etc/network/if-post-down.d/wireless-tools* *run-parts: executing /etc/network/if-post-down.d/wpasupplicant* *root@xx:~# ifup -v eth0* *Configuring interface eth0=eth0 (inet)* *run-parts --verbose /etc/network/if-pre-up.d* *run-parts: executing /etc/network/if-pre-up.d/ethtool* *run-parts: executing /etc/network/if-pre-up.d/wireless-tools* *run-parts: executing /etc/network/if-pre-up.d/wpasupplicant* *ip addr add XXXX/255.255.255.192 broadcast + dev eth0 label eth0* *ip link set dev eth0 up* * ip route add default via XXXX metric 100 dev eth0 * *run-parts --verbose /etc/network/if-up.d* *run-parts: executing /etc/network/if-up.d/000resolvconf* *run-parts: executing /etc/network/if-up.d/ethtool* *run-parts: executing /etc/network/if-up.d/ntpdate* *run-parts: executing /etc/network/if-up.d/openssh-server* Routes seem to be in order: *Destination Gateway Genmask Flags Metric Ref Use Iface* *0.0.0.0 XXX 0.0.0.0 UG 100 0 0 eth0* *XXX 0.0.0.0 255.255.255.192 U 0 0 0 eth0* But i still can't start the networking service... *root@xxx:~# service networking start* *networking stop/waiting* No error messages are shown anywhere. Is there some point to the migration i could be missing? What could differ from one server to another to cause the networking to fail on the new host? Thanks, Gabriel --047d7b3a8218ec3217051b7583d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
I have migrated one ub= untu VM from one XCP 1.6 server to another. After doing this, this VM is no= t able to connect to the networks as before. I have kept IP and MAC Address= es the same.
=C2=A0
After running ifconfig, i can see t= he interface as follows:
=C2=A0
eth0 =C2=A0 =C2=A0 =C2=A0Link e= ncap:Ethernet =C2=A0HWaddr YYY =C2=A0
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 inet addr:XXXX =C2=A0Bcast:XXXX =C2=A0Mask:255.255.255.192
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: XXXXXX/64 Sc= ope:Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP BROADCAST R= UNNING MULTICAST =C2=A0MTU:1500 =C2=A0Metric:1
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RX packets:0 errors:0 dropped:0 overruns:0 frame:0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets:319 errors:= 0 dropped:0 overruns:0 carrier:0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 collisions:0 txqueuelen:1000=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:0 (0.0 B) =C2=A0TX bytes:13614 (13.6 KB)<= /i>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interrupt:68=C2=A0<= /div>
=C2=A0
lo =C2=A0 =C2=A0 =C2=A0 =C2=A0Link enc= ap:Local Loopback =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 inet addr:127.0.0.1 =C2=A0Mask:255.0.0.0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING =C2=A0MTU:16436 =C2=A0M= etric:1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:679 = errors:0 dropped:0 overruns:0 frame:0
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 TX packets:679 errors:0 dropped:0 overruns:0 carrier:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:0=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:3985002 (3= .9 MB) =C2=A0TX bytes:3985002 (3.9 MB)
=C2=A0
=C2=A0
Bringing down and up the eth0 interface works, as = follows:
=C2=A0
root@xx:~# ifdown -v eth0
Conf= iguring interface eth0=3Deth0 (inet)
run-parts --verbose /= etc/network/if-down.d
run-parts: executing /etc/network/if= -down.d/resolvconf
run-parts: executing /etc/network/if-do= wn.d/sendmail
run-parts: executing /etc/network/if-down.d/= upstart
run-parts: executing /etc/network/if-down.d/wpasup= plicant
ip route del default via XXX metric 100 dev eth0 2= >&1 1>/dev/null || true=C2=A0
ip -4 addr flush d= ev eth0 label eth0
ip link set dev eth0 down
run-parts --verbose /etc/network/if-post-down.d
run-pa= rts: executing /etc/network/if-post-down.d/sendmail
run-pa= rts: executing /etc/network/if-post-down.d/wireless-tools
= run-parts: executing /etc/network/if-post-down.d/wpasupplicant
=C2=A0
root@xx:~# ifup -v eth0
Confi= guring interface eth0=3Deth0 (inet)
run-parts --verbose /e= tc/network/if-pre-up.d
run-parts: executing /etc/network/i= f-pre-up.d/ethtool
run-parts: executing /etc/network/if-pr= e-up.d/wireless-tools
run-parts: executing /etc/network/if= -pre-up.d/wpasupplicant
ip addr add XXXX/255.255.255.192 broadcast + =C2=A0 dev eth0 label eth= 0
ip link set dev eth0 =C2=A0 up
=C2=A0ip= route add default via XXXX metric 100 dev eth0=C2=A0
run-= parts --verbose /etc/network/if-up.d
run-parts: executing = /etc/network/if-up.d/000resolvconf
run-parts: executing /e= tc/network/if-up.d/ethtool
run-parts: executing /etc/netwo= rk/if-up.d/ntpdate
run-parts: executing /etc/network/if-up= .d/openssh-server
=C2=A0
Routes seem t= o be in order:
=C2=A0
Destination =C2=A0 =C2=A0 Gateway =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Genmask =C2=A0 =C2=A0 =C2=A0 =C2=A0 Flags Metric Ref = =C2=A0 =C2=A0Use Iface
0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= XXX 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UG =C2=A0 =C2=A0100 =C2=A0 =C2=A00= =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
XXX 0.0.0.0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 255.255.255.192 U =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A00 = =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
=C2=A0
=C2=A0
But i still can't start the networking service...
=C2=A0
root@xxx:~# service networking start
net= working stop/waiting

No error mes= sages are shown anywhere.

Is there some point to t= he migration i could be missing? What could differ from one server to anoth= er to cause the networking to fail on the new host?
=C2=A0
<= div>Thanks,
Gabriel
--047d7b3a8218ec3217051b7583d0-- --===============4103995207837731356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4103995207837731356==-- From xen-users-bounces@lists.xen.org Wed Jul 22 12:00:30 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 12:00:30 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHshH-0004t7-Jt; Wed, 22 Jul 2015 12:00:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHshG-0004sw-Cw for xen-users@lists.xen.org; Wed, 22 Jul 2015 12:00:26 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id ED/49-12200-9D58FA55; Wed, 22 Jul 2015 12:00:25 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437566423!17465095!1 X-Originating-IP: [209.85.223.173] X-SpamReason: No, hits=2.1 required=7.0 tests=HOT_NASTY,HTML_40_50, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 4620 invoked from network); 22 Jul 2015 12:00:24 -0000 Received: from mail-ie0-f173.google.com (HELO mail-ie0-f173.google.com) (209.85.223.173) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 12:00:24 -0000 Received: by iebmu5 with SMTP id mu5so164973990ieb.1 for ; Wed, 22 Jul 2015 05:00:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=wfjdzgbW3wYAM1VprQ0fybZZjbJ/beRE8aQv3C1nDM0=; b=Xhj2dSyVJnWOia/KL7aOZcaH9Oq+OFzmUqjQFZQ++suTRB2kT8JapVYxnlcyAlTwE0 FOVWLrk1oQ5ZVJ/PMEMzh7E5l7JCzFuWb4iHEiqQSmlIy81R8Tt/QJ0l/GGXNo3GeV3N cn81EcRPgJeMKzwWjy2YEJMkfKRW7SZpXD3D3rHVAdPYPF0/eOUHTp+ZOzZK3nHI1RC/ Hvq4ublFb1s8KYKTxACiC95qajAuPKR14BPlsGUpiETSdjKZ1w/SEBhoDhqbODXctdV+ 5vFtqUybRlEsGGUX2652vQe2sbE8T1KiRhiAFuL4ftRFgU/DhJ0cB0VD2n5yrfHDAK8Q /XpQ== X-Gm-Message-State: ALoCoQlFEOK2lJ3vF4A8jfafwBZYvN149B+e/RFhSHZ//ibmw0Ti0PkVpocllxcFD5f04ucE+6zc X-Received: by 10.50.62.106 with SMTP id x10mr5192463igr.29.1437566421960; Wed, 22 Jul 2015 05:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Wed, 22 Jul 2015 05:00:02 -0700 (PDT) From: Gabriel Queiroz Silva Date: Wed, 22 Jul 2015 09:00:02 -0300 Message-ID: To: xen-users@lists.xen.org Subject: [Xen-users] No network on VM after migrating to another xcp server on the same pool X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4103995207837731356==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4103995207837731356== Content-Type: multipart/alternative; boundary=047d7b3a8218ec3217051b7583d0 --047d7b3a8218ec3217051b7583d0 Content-Type: text/plain; charset=UTF-8 Hi, I have migrated one ubuntu VM from one XCP 1.6 server to another. After doing this, this VM is not able to connect to the networks as before. I have kept IP and MAC Addresses the same. After running ifconfig, i can see the interface as follows: *eth0 Link encap:Ethernet HWaddr YYY * * inet addr:XXXX Bcast:XXXX Mask:255.255.255.192* * inet6 addr: XXXXXX/64 Scope:Link* * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* * RX packets:0 errors:0 dropped:0 overruns:0 frame:0* * TX packets:319 errors:0 dropped:0 overruns:0 carrier:0* * collisions:0 txqueuelen:1000 * * RX bytes:0 (0.0 B) TX bytes:13614 (13.6 KB)* * Interrupt:68 * *lo Link encap:Local Loopback * * inet addr:127.0.0.1 Mask:255.0.0.0* * inet6 addr: ::1/128 Scope:Host* * UP LOOPBACK RUNNING MTU:16436 Metric:1* * RX packets:679 errors:0 dropped:0 overruns:0 frame:0* * TX packets:679 errors:0 dropped:0 overruns:0 carrier:0* * collisions:0 txqueuelen:0 * * RX bytes:3985002 (3.9 MB) TX bytes:3985002 (3.9 MB)* Bringing down and up the eth0 interface works, as follows: *root@xx:~# ifdown -v eth0* *Configuring interface eth0=eth0 (inet)* *run-parts --verbose /etc/network/if-down.d* *run-parts: executing /etc/network/if-down.d/resolvconf* *run-parts: executing /etc/network/if-down.d/sendmail* *run-parts: executing /etc/network/if-down.d/upstart* *run-parts: executing /etc/network/if-down.d/wpasupplicant* *ip route del default via XXX metric 100 dev eth0 2>&1 1>/dev/null || true * *ip -4 addr flush dev eth0 label eth0* *ip link set dev eth0 down* *run-parts --verbose /etc/network/if-post-down.d* *run-parts: executing /etc/network/if-post-down.d/sendmail* *run-parts: executing /etc/network/if-post-down.d/wireless-tools* *run-parts: executing /etc/network/if-post-down.d/wpasupplicant* *root@xx:~# ifup -v eth0* *Configuring interface eth0=eth0 (inet)* *run-parts --verbose /etc/network/if-pre-up.d* *run-parts: executing /etc/network/if-pre-up.d/ethtool* *run-parts: executing /etc/network/if-pre-up.d/wireless-tools* *run-parts: executing /etc/network/if-pre-up.d/wpasupplicant* *ip addr add XXXX/255.255.255.192 broadcast + dev eth0 label eth0* *ip link set dev eth0 up* * ip route add default via XXXX metric 100 dev eth0 * *run-parts --verbose /etc/network/if-up.d* *run-parts: executing /etc/network/if-up.d/000resolvconf* *run-parts: executing /etc/network/if-up.d/ethtool* *run-parts: executing /etc/network/if-up.d/ntpdate* *run-parts: executing /etc/network/if-up.d/openssh-server* Routes seem to be in order: *Destination Gateway Genmask Flags Metric Ref Use Iface* *0.0.0.0 XXX 0.0.0.0 UG 100 0 0 eth0* *XXX 0.0.0.0 255.255.255.192 U 0 0 0 eth0* But i still can't start the networking service... *root@xxx:~# service networking start* *networking stop/waiting* No error messages are shown anywhere. Is there some point to the migration i could be missing? What could differ from one server to another to cause the networking to fail on the new host? Thanks, Gabriel --047d7b3a8218ec3217051b7583d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
I have migrated one ub= untu VM from one XCP 1.6 server to another. After doing this, this VM is no= t able to connect to the networks as before. I have kept IP and MAC Address= es the same.
=C2=A0
After running ifconfig, i can see t= he interface as follows:
=C2=A0
eth0 =C2=A0 =C2=A0 =C2=A0Link e= ncap:Ethernet =C2=A0HWaddr YYY =C2=A0
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 inet addr:XXXX =C2=A0Bcast:XXXX =C2=A0Mask:255.255.255.192
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: XXXXXX/64 Sc= ope:Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP BROADCAST R= UNNING MULTICAST =C2=A0MTU:1500 =C2=A0Metric:1
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RX packets:0 errors:0 dropped:0 overruns:0 frame:0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets:319 errors:= 0 dropped:0 overruns:0 carrier:0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 collisions:0 txqueuelen:1000=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:0 (0.0 B) =C2=A0TX bytes:13614 (13.6 KB)<= /i>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interrupt:68=C2=A0<= /div>
=C2=A0
lo =C2=A0 =C2=A0 =C2=A0 =C2=A0Link enc= ap:Local Loopback =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 inet addr:127.0.0.1 =C2=A0Mask:255.0.0.0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING =C2=A0MTU:16436 =C2=A0M= etric:1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:679 = errors:0 dropped:0 overruns:0 frame:0
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 TX packets:679 errors:0 dropped:0 overruns:0 carrier:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:0=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:3985002 (3= .9 MB) =C2=A0TX bytes:3985002 (3.9 MB)
=C2=A0
=C2=A0
Bringing down and up the eth0 interface works, as = follows:
=C2=A0
root@xx:~# ifdown -v eth0
Conf= iguring interface eth0=3Deth0 (inet)
run-parts --verbose /= etc/network/if-down.d
run-parts: executing /etc/network/if= -down.d/resolvconf
run-parts: executing /etc/network/if-do= wn.d/sendmail
run-parts: executing /etc/network/if-down.d/= upstart
run-parts: executing /etc/network/if-down.d/wpasup= plicant
ip route del default via XXX metric 100 dev eth0 2= >&1 1>/dev/null || true=C2=A0
ip -4 addr flush d= ev eth0 label eth0
ip link set dev eth0 down
run-parts --verbose /etc/network/if-post-down.d
run-pa= rts: executing /etc/network/if-post-down.d/sendmail
run-pa= rts: executing /etc/network/if-post-down.d/wireless-tools
= run-parts: executing /etc/network/if-post-down.d/wpasupplicant
=C2=A0
root@xx:~# ifup -v eth0
Confi= guring interface eth0=3Deth0 (inet)
run-parts --verbose /e= tc/network/if-pre-up.d
run-parts: executing /etc/network/i= f-pre-up.d/ethtool
run-parts: executing /etc/network/if-pr= e-up.d/wireless-tools
run-parts: executing /etc/network/if= -pre-up.d/wpasupplicant
ip addr add XXXX/255.255.255.192 broadcast + =C2=A0 dev eth0 label eth= 0
ip link set dev eth0 =C2=A0 up
=C2=A0ip= route add default via XXXX metric 100 dev eth0=C2=A0
run-= parts --verbose /etc/network/if-up.d
run-parts: executing = /etc/network/if-up.d/000resolvconf
run-parts: executing /e= tc/network/if-up.d/ethtool
run-parts: executing /etc/netwo= rk/if-up.d/ntpdate
run-parts: executing /etc/network/if-up= .d/openssh-server
=C2=A0
Routes seem t= o be in order:
=C2=A0
Destination =C2=A0 =C2=A0 Gateway =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Genmask =C2=A0 =C2=A0 =C2=A0 =C2=A0 Flags Metric Ref = =C2=A0 =C2=A0Use Iface
0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= XXX 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UG =C2=A0 =C2=A0100 =C2=A0 =C2=A00= =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
XXX 0.0.0.0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 255.255.255.192 U =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A00 = =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
=C2=A0
=C2=A0
But i still can't start the networking service...
=C2=A0
root@xxx:~# service networking start
net= working stop/waiting

No error mes= sages are shown anywhere.

Is there some point to t= he migration i could be missing? What could differ from one server to anoth= er to cause the networking to fail on the new host?
=C2=A0
<= div>Thanks,
Gabriel
--047d7b3a8218ec3217051b7583d0-- --===============4103995207837731356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4103995207837731356==-- From xen-users-bounces@lists.xen.org Wed Jul 22 14:52:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 14:52:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHvMW-0004oS-0I; Wed, 22 Jul 2015 14:51:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHvMU-0004na-6X for xen-users@lists.xen.org; Wed, 22 Jul 2015 14:51:10 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 06/B7-21947-DDDAFA55; Wed, 22 Jul 2015 14:51:09 +0000 X-Env-Sender: prvs=63841d76d=roger.pau@citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1437576664!18805425!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1186 invoked from network); 22 Jul 2015 14:51:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 14:51:06 -0000 X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="286502337" Message-ID: <55AFADD4.9070205@citrix.com> Date: Wed, 22 Jul 2015 16:51:00 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell , "Manfred Haertel, DB3HM" References: <559EB33C.8010800@rz-online.de> <1436519554.23508.183.camel@citrix.com> In-Reply-To: <1436519554.23508.183.camel@citrix.com> X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello, El 10/07/15 a les 11.12, Ian Campbell ha escrit: > On Thu, 2015-07-09 at 19:45 +0200, Manfred Haertel, DB3HM wrote: >> I would like to use the Xen serial console, but on a computer which does >> not have a serial device. >> >> So I have to use the so-called USB debugging port (console=dbgp). The >> USB controller in my system seems to support this. >> >> But where do I find an USB cable to connect my computer to another one >> via USB? >> >> Most documentations refer to a small device called NET20DC, to which you >> can connect both computers via USB. Unfortunately, this device doesn't >> seem to be available anymore. > > Indeed, a while back I searched long and hard for such a thing and > didn't come up with anything, I concluded that they were either > fictional, ancient and unavailable or something one needed to build for > oneself with a soldering iron :-/ The only one of this kind of devices that's available right now it's AMIDebug RX (http://www.ami.com/products/bios-uefi-tools-and-utilities/amidebug-rx/) which does a bunch of other things apart from Host-to-Host debugging, and more important, it costs 500$ per unit. > I just had another look and things seem more promising, the "Net chip > USB debug link" in > https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt remains > dead but I found https://github.com/avivgr/teensy_debugdev and > http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx > > Which lead me to google "usb debug cable" and find things such as: > http://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html > and a bunch of ones which don't look right (mostly extension cables or > TTL/serial on one end). AFAIK this only works if you have a XHCI (USB 3.0) debug port, it's not going to work with the more common EHCI (USB 2.0) debug ports. And I've been told XHCI debug ports are not that common even on new hardware. > I have no idea if that datapro thing is actually the right thing, but it > looks promising... > >> Is there another device, which is still available and is known to work? IMHO the only realistic option (unless you want to spend 500$) is to build one yourself, I've found the following wiki page with _some_ information, although I have not tried to follow it myself: http://www.coreboot.org/DIY_EHCI_debug_dongle Roger. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 22 14:52:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 22 Jul 2015 14:52:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHvMW-0004oS-0I; Wed, 22 Jul 2015 14:51:12 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZHvMU-0004na-6X for xen-users@lists.xen.org; Wed, 22 Jul 2015 14:51:10 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 06/B7-21947-DDDAFA55; Wed, 22 Jul 2015 14:51:09 +0000 X-Env-Sender: prvs=63841d76d=roger.pau@citrix.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1437576664!18805425!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1186 invoked from network); 22 Jul 2015 14:51:06 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-11.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 22 Jul 2015 14:51:06 -0000 X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="286502337" Message-ID: <55AFADD4.9070205@citrix.com> Date: Wed, 22 Jul 2015 16:51:00 +0200 From: =?windows-1252?Q?Roger_Pau_Monn=E9?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Ian Campbell , "Manfred Haertel, DB3HM" References: <559EB33C.8010800@rz-online.de> <1436519554.23508.183.camel@citrix.com> In-Reply-To: <1436519554.23508.183.camel@citrix.com> X-DLP: MIA1 Cc: xen-users Subject: Re: [Xen-users] Where can I find a USB debug cable? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Hello, El 10/07/15 a les 11.12, Ian Campbell ha escrit: > On Thu, 2015-07-09 at 19:45 +0200, Manfred Haertel, DB3HM wrote: >> I would like to use the Xen serial console, but on a computer which does >> not have a serial device. >> >> So I have to use the so-called USB debugging port (console=dbgp). The >> USB controller in my system seems to support this. >> >> But where do I find an USB cable to connect my computer to another one >> via USB? >> >> Most documentations refer to a small device called NET20DC, to which you >> can connect both computers via USB. Unfortunately, this device doesn't >> seem to be available anymore. > > Indeed, a while back I searched long and hard for such a thing and > didn't come up with anything, I concluded that they were either > fictional, ancient and unavailable or something one needed to build for > oneself with a soldering iron :-/ The only one of this kind of devices that's available right now it's AMIDebug RX (http://www.ami.com/products/bios-uefi-tools-and-utilities/amidebug-rx/) which does a bunch of other things apart from Host-to-Host debugging, and more important, it costs 500$ per unit. > I just had another look and things seem more promising, the "Net chip > USB debug link" in > https://www.kernel.org/doc/Documentation/x86/earlyprintk.txt remains > dead but I found https://github.com/avivgr/teensy_debugdev and > http://blogs.msdn.com/b/usbcoreblog/archive/2010/10/25/setting-up-kernel-debugging-with-usb-2-0.aspx > > Which lead me to google "usb debug cable" and find things such as: > http://www.datapro.net/products/usb-3-0-super-speed-a-a-debugging-cable.html > and a bunch of ones which don't look right (mostly extension cables or > TTL/serial on one end). AFAIK this only works if you have a XHCI (USB 3.0) debug port, it's not going to work with the more common EHCI (USB 2.0) debug ports. And I've been told XHCI debug ports are not that common even on new hardware. > I have no idea if that datapro thing is actually the right thing, but it > looks promising... > >> Is there another device, which is still available and is known to work? IMHO the only realistic option (unless you want to spend 500$) is to build one yourself, I've found the following wiki page with _some_ information, although I have not tried to follow it myself: http://www.coreboot.org/DIY_EHCI_debug_dongle Roger. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 23 21:55:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 23 Jul 2015 21:55:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIORg-0007l1-4T; Thu, 23 Jul 2015 21:54:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIO17-0004bU-K5 for xen-users@lists.xen.org; Thu, 23 Jul 2015 21:27:01 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id D5/93-29980-42C51B55; Thu, 23 Jul 2015 21:27:00 +0000 X-Env-Sender: cardoe@cardoe.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1437686817!23255292!1 X-Originating-IP: [209.85.223.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25942 invoked from network); 23 Jul 2015 21:26:58 -0000 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 23 Jul 2015 21:26:58 -0000 Received: by ietj16 with SMTP id j16so4347541iet.0 for ; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=1+6DBy07PN5bvxHscWE1cMnc0sz4SVK3Xk9P4iEGe3w=; b=efTTYql26nyoKaK+m6zGpw3ecttKV7aLO2eTO7Q6+Nld3pxihiZHm3Sm37OYjCtKbn HG/wjpu9Uc7nHkQdwDu4Awl5WQkhojYM7Lde27d+dEIS8Erv2+SkZghSODTmUdvtkyVB 72f1EBwfhQeAm6dvydDsc6RpXI8yfyb7XIQJaUiqSl4ow97isNuWDmNpIeWxK7qI8K5L Do9xPD6fmEdgzIQomP4mmzAkUZcvnvo1SQXJQtlU1sOwFObRF/JrYCjmnnHQEjrr9xRq ECK8R9LN7OwvFH6zIfDa2+KOUEwva61vEBt8jQO7nPno/azHpWsMhnQ67n/58q/aAzaf 30bw== X-Gm-Message-State: ALoCoQmzJZwCjYCLB/XLfqwMIiXjlgtLRRK1UDbeg24CMxgAzOWavx+dD9ByrF1p36NUOKMMy2GJ MIME-Version: 1.0 X-Received: by 10.50.98.3 with SMTP id ee3mr610253igb.10.1437686817416; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) Received: by 10.107.140.143 with HTTP; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) Date: Thu, 23 Jul 2015 16:26:57 -0500 X-Google-Sender-Auth: MIX2Yixyxunpf9UhY-_eqSS34Hs Message-ID: From: Doug Goldstein To: xen-users@lists.xen.org X-Mailman-Approved-At: Thu, 23 Jul 2015 21:54:26 +0000 Subject: [Xen-users] Xen 4.5.x / master ACPI failures X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I have been trying to get Xen to work for me on a Lenovo T430 laptop for a few days now and I'm hoping someone had some better suggestions to try. I know it should work because I actually have two of these machines. They are identical machines except for the BIOS version (UEFI really). The one where everything is working is running 2.05 of Lenovo's BIOS while the one that is failing is 2.68. Unfortunately Lenovo prevents you from reverting versions. Both machines are able to successfully boot Ubuntu 15.04 where everything related to EFI appears to work correctly. I have tried the Ubuntu 15.04 package (Xen 4.5.0) and I've also built the code from source (using master and the RELEASE-4.5.1 tag). Here's the output of booting from the 4.5.1 build (note I had to apply a patch to get it to compile. I got the patch from the xen-devel mailing list for OCaml dependencies). $ sudo xl dmesg Xen 4.5.1 (XEN) Xen version 4.5.1 (doug@) (gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2) debug=n Wed Jul 22 15:20:53 CDT 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty (XEN) Bootloader: GRUB 2.02~beta2-22ubuntu1.1 (XEN) Command line: placeholder loglvl=all no-real-mode edd=off (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Multiboot-e820 RAM map: (XEN) 0000000000000000 - 000000000009c000 (usable) (XEN) 000000000009c000 - 000000000009d000 (reserved) (XEN) 000000000009d000 - 000000000009e000 (usable) (XEN) 000000000009e000 - 00000000000c0000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040004000 (usable) (XEN) 0000000040004000 - 0000000040005000 (reserved) (XEN) 0000000040005000 - 00000000cff31000 (usable) (XEN) 00000000cff31000 - 00000000d0133000 (reserved) (XEN) 00000000d0133000 - 00000000d660b000 (usable) (XEN) 00000000d660b000 - 00000000d680b000 type 20 (XEN) 00000000d680b000 - 00000000daa9f000 (reserved) (XEN) 00000000daa9f000 - 00000000dab9f000 (ACPI NVS) (XEN) 00000000dab9f000 - 00000000dabff000 (ACPI data) (XEN) 00000000dabff000 - 00000000dac00000 (usable) (XEN) 00000000dac00000 - 00000000dfa00000 (reserved) (XEN) 00000000f80f8000 - 00000000f80f9000 (reserved) (XEN) 00000000fed1c000 - 00000000fed90000 (reserved) (XEN) 0000000100000000 - 000000021e600000 (usable) (XEN) 000000021e600000 - 000000021f000000 (reserved) (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] (XEN) System RAM: 8007MB (8199832kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000021e600000 (XEN) Domain heap initialised (XEN) DMI not present. (XEN) Using APIC driver default (XEN) ERST table was not found (XEN) SMP: Allowing 1 CPUs (1 hotplug CPUs) (XEN) Found and enabled local APIC! (XEN) IRQ limits: 16 GSI, 192 MSI/MSI-X (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2594.174 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) alt table ffff82d0802bcbd0 -> ffff82d0802bdd28 (XEN) I/O virtualisation disabled (XEN) SMP motherboard not detected. (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) TSC deadline timer enabled (XEN) Platform timer is 1.193MHz PIT (XEN) Allocated console ring of 16 KiB. (XEN) mwait-idle: MWAIT substates: 0x21120 (XEN) mwait-idle: v0.4 model 0x3a (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) Brought up 1 CPUs (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) Dom0 has maximum 208 PIRQs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x200b000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000210000000->0000000214000000 (1968568 pages to be allocated) (XEN) Init. ramdisk: 000000021c6fa000->000000021e5ffaf2 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff8200b000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffffff8200b000->ffffffff82f3f5f0 (XEN) Start info: ffffffff82f40000->ffffffff82f404b4 (XEN) Page tables: ffffffff82f41000->ffffffff82f5c000 (XEN) Boot stack: ffffffff82f5c000->ffffffff82f5d000 (XEN) TOTAL: ffffffff80000000->ffffffff83000000 (XEN) ENTRY ADDRESS: ffffffff81d4c1f0 (XEN) Dom0 has maximum 1 VCPUs (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ....................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802c3000 to 0xffffffff817cb1d0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802c3080 to 0xffffffff817cd7a0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802c7fc0 to 0x0000000000000000. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080225f00 to 0xffffffff817cdab0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802c3080 to 0xffffffff817cdcf0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.3 (XEN) PCI add device 0000:00:19.0 (XEN) PCI add device 0000:00:1a.0 (XEN) PCI add device 0000:00:1b.0 (XEN) PCI add device 0000:00:1c.0 (XEN) PCI add device 0000:00:1c.1 (XEN) PCI add device 0000:00:1d.0 (XEN) PCI add device 0000:00:1f.0 (XEN) PCI add device 0000:00:1f.2 (XEN) PCI add device 0000:00:1f.3 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) traps.c:3161: GPF (0000): ffff82d080190f5d -> ffff82d08022a693 (XEN) traps.c:3161: GPF (0000): ffff82d080190f5d -> ffff82d08022a693 When booting on the working T430, I don't see the error about ACPI RSDP missing and the machine properly sees 4 cores. I figured if I was able to boot Xen via EFI then things would work a little bit better. Unfortunately the screen was completely black when I managed this but I did manage to configure Intel AMT SOL and get output from what appears to be the dom0 kernel. Unfortunately it too hangs. amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active) serial-over-lan redirection ok connected now, use ^] to escape 0] init_memory_mapping: [mem 0x40005000-0xceaacfff] [ 0.000000] init_memory_mapping: [mem 0xcecaf000-0xd660afff] [ 0.000000] init_memory_mapping: [mem 0xdabff000-0xdabfffff] [ 0.000000] init_memory_mapping: [mem 0x100000000-0x1bfffffff] [ 0.000000] init_memory_mapping: [mem 0x1e5200000-0x21e5fffff] [ 0.000000] RAMDISK: [mem 0x04000000-0x05f09fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000DABFE014 000024 (v02 LENOVO) [ 0.000000] ACPI: XSDT 0x00000000DABFE170 0000CC (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: FACP 0x00000000DABE6000 00010C (v05 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DSDT 0x00000000DABE8000 0103F7 (v01 LENOVO TP-G1 00002680 INTL 20061109) [ 0.000000] ACPI: FACS 0x00000000DAB5A000 000040 [ 0.000000] ACPI: SLIC 0x00000000DABFD000 000176 (v01 LENOVO TP-G1 00002680 PTL 00000001) [ 0.000000] ACPI: TCPA 0x00000000DABFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 0x00000000DABFB000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABF9000 000797 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 0x00000000DABE4000 000038 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: APIC 0x00000000DABE3000 000098 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: MCFG 0x00000000DABE2000 00003C (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: ECDT 0x00000000DABE1000 000052 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: FPDT 0x00000000DABE0000 000064 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: ASF! 0x00000000DABE7000 0000A5 (v32 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000DABDF000 00003E (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000DABDE000 000042 (v01 PTL COMBUF 00000001 PTL 00000001) [ 0.000000] ACPI: POAT 0x00000000DABDD000 000055 (v03 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: SSDT 0x00000000DABDC000 000C51 (v01 PmRef Cpu0Ist 00003000 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABDB000 000A83 (v01 PmRef CpuPm 00003000 INTL 20061109) [ 0.000000] ACPI: XMAR 0x00000000DABDA000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) [ 0.000000] ACPI: UEFI 0x00000000DABD9000 0002A6 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DBG2 0x00000000DABD8000 0000E9 (v00 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: BGRT 0x00000000DABD7000 000038 (v00 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DMI detected: Lenovo ThinkPad T430 [ 0.000000] NUMA turned off [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000021e5fffff] [ 0.000000] NODE_DATA(0) allocated [mem 0x1e53bb000-0x1e53bffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0x21e5fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009bfff] [ 0.000000] node 0: [mem 0x0009d000-0x0009dfff] [ 0.000000] node 0: [mem 0x00100000-0x1fffffff] [ 0.000000] node 0: [mem 0x20200000-0x40003fff] [ 0.000000] node 0: [mem 0x40005000-0xceaacfff] [ 0.000000] node 0: [mem 0xcecaf000-0xd660afff] [ 0.000000] node 0: [mem 0xdabff000-0xdabfffff] [ 0.000000] node 0: [mem 0x100000000-0x21e5fffff] [ 0.000000] Initmem setup node 0 [mem 0x00001000-0x21e5fffff] [ 0.000000] p2m virtual area at ffffc90000000000, size is 40000000 [ 0.000000] Remapped 171610 page(s) [ 0.000000] Reserving Intel graphics stolen memory at 0xdba00000-0xdf9fffff [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 [ 0.000000] smpboot: Allowing 8 CPUs, 4 hotplug CPUs [ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009c000-0x0009cfff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x000fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x20000000-0x201fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x40004000-0x40004fff] [ 0.000000] PM: Registered nosave memory: [mem 0xceaad000-0xcecaefff] [ 0.000000] PM: Registered nosave memory: [mem 0xd660b000-0xdaa9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xdaa9f000-0xdab9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xdab9f000-0xdabfefff] [ 0.000000] PM: Registered nosave memory: [mem 0xdac00000-0xdf9fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xdfa00000-0xf80f7fff] [ 0.000000] PM: Registered nosave memory: [mem 0xf80f8000-0xf80f8fff] [ 0.000000] PM: Registered nosave memory: [mem 0xf80f9000-0xfebfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfed1bfff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed91fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed92000-0xfedfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xffffffff] [ 0.000000] e820: [mem 0xdfa00000-0xf80f7fff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.5.1 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 31 pages/cpu @ffff88020f000000 s87040 r8192 d31744 u262144 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 2017903 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: root=/dev/mapper/ubuntu--vg-root ro console=ttyS4,115200 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form [ 0.000000] software IO TLB [mem 0x20b000000-0x20f000000] (64MB) mapped at [ffff88020b000000-ffff88020effffff] [ 0.000000] Memory: 7671056K/8199828K available (8002K kernel code, 1232K rwdata, 3760K rodata, 1408K init, 1300K bss, 528772K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:16640 nr_irqs:456 16 [ 0.000000] xen:events: Using FIFO-based ABI [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-3. [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] tsc: Detected 2594.184 MHz processor [ 7.146988] Calibrating delay loop (skipped), value calculated using timer frequency.. 5188.36 BogoMIPS (lpj=10376736) [ 7.146991] pid_max: default: 32768 minimum: 301 [ 7.146997] ACPI: Core revision 20141107 [ 7.188413] ACPI: All ACPI Tables successfully acquired [ 7.189354] Security Framework initialized [ 7.189374] AppArmor: AppArmor initialized [ 7.189375] Yama: becoming mindful. [ 7.190387] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) [ 7.192568] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 7.193430] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 7.193448] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 7.193703] Initializing cgroup subsys memory [ 7.193709] Initializing cgroup subsys devices [ 7.193711] Initializing cgroup subsys freezer [ 7.193714] Initializing cgroup subsys net_cls [ 7.193717] Initializing cgroup subsys blkio [ 7.193719] Initializing cgroup subsys perf_event [ 7.193721] Initializing cgroup subsys net_prio [ 7.193723] Initializing cgroup subsys hugetlb [ 7.193782] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 7.193782] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 7.193785] CPU: Physical Processor ID: 0 [ 7.193786] CPU: Processor Core ID: 0 [ 7.194130] mce: CPU supports 2 MCE banks [ 7.194145] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [ 7.194145] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [ 7.194256] Freeing SMP alternatives memory: 32K (ffffffff81e96000 - ffffffff81e9e000) [ 7.195562] Ignoring BGRT: invalid version 0 (expected 1) [ 7.195564] ftrace: allocating 30087 entries in 118 pages [ 7.208712] cpu 0 spinlock event irq 25 [ 7.217813] Performance Events: unsupported p6 CPU model 58 no PMU driver, software events only. [ 7.218521] NMI watchdog: disabled (cpu0): hardware events not enabled [ 7.218604] installing Xen timer for CPU 1 [ 7.218611] cpu 1 spinlock event irq 32 [ 7.219244] installing Xen timer for CPU 2 [ 7.219251] cpu 2 spinlock event irq 39 [ 7.219845] installing Xen timer for CPU 3 [ 7.219851] cpu 3 spinlock event irq 46 [ 7.220376] x86: Booted up 1 node, 4 CPUs [ 7.220637] devtmpfs: initialized [ 7.223116] evm: security.selinux [ 7.223117] evm: security.SMACK64 [ 7.223118] evm: security.SMACK64EXEC [ 7.223119] evm: security.SMACK64TRANSMUTE [ 7.223120] evm: security.SMACK64MMAP [ 7.223121] evm: security.ima [ 7.223121] evm: security.capability [ 7.223210] PM: Registering ACPI NVS region [mem 0xdaa9f000-0xdab9efff] (1048576 bytes) [ 7.223406] pinctrl core: initialized pinctrl subsystem [ 7.223519] RTC time: 19:29:27, date: 07/23/15 [ 7.223614] NET: Registered protocol family 16 [ 7.223624] xen:grant_table: Grant tables using version 1 layout [ 7.223634] Grant table initialized [ 7.223890] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 7.223892] ACPI: bus type PCI registered [ 7.223894] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 7.224154] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 7.224156] PCI: not using MMCONFIG [ 7.224158] PCI: Using configuration type 1 for base access [ 7.229414] ACPI: Added _OSI(Module Device) [ 7.229418] ACPI: Added _OSI(Processor Device) [ 7.229420] ACPI: Added _OSI(3.0 _SCP Extensions) [ 7.229421] ACPI: Added _OSI(Processor Aggregator Device) [ 7.229422] ACPI: Deleted _OSI(Windows 2012) [ 7.230902] ACPI : EC: EC description table is found, configuring boot EC [ 7.236808] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 7.239868] ACPI: Dynamic OEM Table Load: [ 7.239880] ACPI: SSDT 0xFFFF8802094B1000 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 7.240532] ACPI: Dynamic OEM Table Load: [ 7.240541] ACPI: SSDT 0xFFFF8802094D8C00 000303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 7.241039] ACPI: Dynamic OEM Table Load: [ 7.241047] ACPI: SSDT 0xFFFF88020946B400 000119 (v01 PmRef ApCst 00003000 INTL 20061109) [ 7.242076] ACPI: Interpreter enabled [ 7.242081] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20141107/hwxface-580) [ 7.242085] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20141107/hwxface-580) [ 7.242097] ACPI: (supports S0 S3 S4 S5) [ 7.242098] ACPI: Using IOAPIC for interrupt routing [ 7.242112] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 7.242549] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources [ 7.248776] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 7.251372] ACPI: Power Resource [PUBS] (on) [ 7.252009] acpi PNP0C0A:01: ACPI dock station (docks/bays count: 1) [ 7.252846] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 2) [ 7.255247] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255336] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255423] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255511] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255598] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255684] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255769] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255855] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255943] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) [ 7.255947] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 7.256090] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability] [ 7.256153] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] [ 7.256156] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability] [ 7.256157] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER] [ 7.256159] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM [ 7.256304] PCI host bridge to bus 0000:00 [ 7.256307] pci_bus 0000:00: root bus resource [bus 00-3f] [ 7.256308] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 7.256310] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 7.256311] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 7.256313] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c3fff] [ 7.256314] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff] [ 7.256316] pci_bus 0000:00: root bus resource [mem 0x000c8000-0x000cbfff] [ 7.256317] pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff] [ 7.256318] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] [ 7.256320] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] [ 7.256321] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] [ 7.256322] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] [ 7.256324] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] [ 7.256325] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff] [ 7.256327] pci_bus 0000:00: root bus resource [mem 0x000e8000-0x000ebfff] [ 7.256328] pci_bus 0000:00: root bus resource [mem 0x000ec000-0x000effff] [ 7.256329] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfebfffff] [ 7.256331] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed4bfff] [ 7.257025] pci 0000:00:14.0: System wakeup disabled by ACPI [ 7.258052] pci 0000:00:19.0: System wakeup disabled by ACPI [ 7.258424] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 7.258782] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 7.259112] pci 0000:00:1c.0: Enabling MPC IRBNCE [ 7.259116] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled [ 7.259454] pci 0000:00:1c.1: Enabling MPC IRBNCE [ 7.259458] pci 0000:00:1c.1: Intel PCH root port ACS workaround enabled [ 7.259861] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 7.261131] pci 0000:02:00.0: MMC controller base frequency changed to 50Mhz. [ 7.268901] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 7.276940] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 7.278264] ACPI: Enabled 4 GPEs in block 00 to 3F [ 7.278319] ACPI : EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 [ 7.278360] xen:balloon: Initialising balloon driver [ 7.279103] xen_balloon: Initialising balloon driver [ 7.279243] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=mem,locks=none [ 7.279247] vgaarb: loaded [ 7.279248] ved traffic allowed by default [ 7.285738] Switched to clocksource xen [ 7.291057] AppArmor: AppArmor Filesystem Enabled [ 7.291124] pnp: PnP ACPI init [ 7.291565] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 7.291568] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved [ 7.291569] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved [ 7.291571] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved [ 7.291573] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved [ 7.291664] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] [ 7.291682] system 00:01: [io 0x0400-0x047f] could not be reserved [ 7.291684] system 00:01: [io 0x0500-0x057f] has been reserved [ 7.291686] system 00:01: [io 0x0800-0x080f] has been reserved [ 7.291687] system 00:01: [io 0x15e0-0x15ef] has been reserved [ 7.291689] system 00:01: [io 0x1600-0x167f] has been reserved [ 7.291691] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved [ 7.291693] system 00:01: [mem 0xfffff000-0xffffffff] has been reserved [ 7.291694] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 7.291696] system 00:01: [mem 0xfed10000-0xfed17fff] has been reserved [ 7.291698] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved [ 7.291699] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved [ 7.291701] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved [ 7.292499] pnp: PnP ACPI: found 6 devices [ 7.299137] PM-Timer failed consistency check (0xffffff) - aborting. [ 7.299185] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 7.299193] pci 0000:00:1c.0: bridge window [io 0x3000-0x3fff] [ 7.299202] pci 0000:00:1c.0: bridge window [mem 0xf0d00000-0xf14fffff] [ 7.299209] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] [ 7.299222] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 7.299231] pci 0000:00:1c.1: bridge window [mem 0xf0c00000-0xf0cfffff] [ 7.299304] NET: Registered protocol family 2 [ 7.299523] TCP established hash table entries: 65536 (order: 7, 524288 bytes) [ 7.299757] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 7.299863] TCP: Hash tables configured (established 65536 bind 65536) [ 7.299881] TCP: reno registered [ 7.299900] UDP hash table entries: 4096 (order: 5, 131072 bytes) [ 7.299935] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes) [ 7.299991] NET: Registered protocol family 1 [ 7.300291] Already setup the GSI :16 [ 7.300662] Trying to unpack rootfs image as initramfs... [ 7.766016] Freeing initrd memory: 31784K (ffff880004000000 - ffff880005f0a000) [ 7.766293] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 7.766341] Scanning for low memory corruption every 60 seconds [ 7.766929] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 7.766949] Initialise system trusted keyring [ 7.766972] audit: initializing netlink subsys (disabled) [ 7.766986] audit: type=2000 audit(1437679767.311:1): initialized [ 7.767393] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 7.768609] zpool: loaded [ 7.768613] zbud: loaded [ 7.768846] VFS: Disk quotas dquot_6.5.2 [ 7.768882] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 7.769439] fuse init (API version 7.23) [ 7.769653] Key type big_key registered [ 7.770230] Key type asymmetric registered [ 7.770233] Asymmetric key parser 'x509' registered [ 7.770268] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.770322] io scheduler noop registered [ 7.770326] io scheduler deadline registered (default) [ 7.770363] io scheduler cfq registered [ 7.770503] Already setup the GSI :16 [ 7.770806] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 7.770823] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 7.770857] efifb: probing for efifb [ 7.771634] efifb: framebuffer at 0xe0000000, mapped to 0xffffc90044f00000, using 8100k, total 8100k [ 7.771636] efifb: mode is 1920x1080x32, linelength=7680, pages=1 [ 7.771636] efifb: scrolling: redraw [ 7.771638] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 7.775355] Console: switching to colour frame buffer device 240x67 [ 7.778971] fb0: EFI VGA frame buffer device [ 7.779658] ACPI: AC Adapter [AC] (on-line) [ 7.780163] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 [ 7.780316] ACPI: Lid Switch [LID] [ 7.780352] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 [ 7.780355] ACPI: Sleep Button [SLPB] [ 7.780393] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 7.780395] ACPI: Power Button [PWRF] [ 7.784040] thermal LNXTHERM:00: registered as thermal_zone0 [ 7.784042] ACPI: Thermal Zone [THM0] (50 C) [ 7.784070] GHES: HEST is not enabled! [ 7.797527] ACPI: Battery Slot [BAT0] (battery present) [ 7.800895] xen_acpi_processor: Uploading Xen processor PM info [ 7.804347] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 7.805995] console [ttyS4] disabled [ 7.826547] 0000:00:16.3: ttyS4 at I/O 0x40b0 (irq = 19, base_baud = 115200) is a 16550A [ 8.593884] console [ttyS4] enabled [ 8.594970] hpet_acpi_add: no address or irqs in _CRS [ 8.596063] Linux agpgart interface v0.103 [ 8.597486] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) [ 8.709809] brd: module loaded [ 8.711980] loop: module loaded [ 8.713253] libphy: Fixed MDIO Bus: probed [ 8.714415] tun: Universal TUN/TAP device driver, 1.6 [ 8.715736] tun: (C) 1999-2004 Max Krasnyansky [ 8.717548] PPP generic driver version 2.4.2 [ 8.718799] xen_netfront: Initialising Xen virtual ethernet driver [ 8.720433] Already setup the GSI :16 [ 8.721232] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 8.722434] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 8.724193] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.725601] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.727105] usb usb1: Product: xHCI Host Controller [ 8.728221] usb usb1: Manufacturer: Linux 3.19.0-23-generic xhci-hcd [ 8.729526] usb usb1: SerialNumber: 0000:00:14.0 [ 8.730653] hub 1-0:1.0: USB hub found [ 8.731444] hub 1-0:1.0: 4 ports detected [ 8.732728] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 8.734487] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 8.736089] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [ 8.738417] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.739917] usb usb2: Product: xHCI Host Controller [ 8.740949] usb usb2: Manufacturer: Linux 3.19.0-23-generic xhci-hcd [ 8.742465] usb usb2: SerialNumber: 0000:00:14.0 [ 8.743574] hub 2-0:1.0: USB hub found [ 8.744365] hub 2-0:1.0: 4 ports detected [ 8.745627] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 8.746995] ehci-pci: EHCI PCI platform driver [ 8.748017] Already setup the GSI :16 [ 8.748814] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 8.749921] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 3 [ 8.751477] ehci-pci 0000:00:1a.0: debug port 2 [ 8.762871] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf153a000 [ 8.773799] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 8.776195] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.777714] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.779216] usb usb3: Product: EHCI Host Controller [ 8.780259] usb usb3: Manufacturer: Linux 3.19.0-23-generic ehci_hcd [ 8.781574] usb usb3: SerialNumber: 0000:00:1a.0 [ 8.782939] hub 3-0:1.0: USB hub found [ 8.783772] hub 3-0:1.0: 3 ports detected [ 8.784838] Already setup the GSI :23 [ 8.785633] ehci-pci 0000:00:1d.0: EHCI Host Controller [ 8.786761] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 4 [ 8.788462] ehci-pci 0000:00:1d.0: debug port 2 [ 8.793457] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf1539000 [ 8.805803] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 8.807098] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.808657] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.810686] usb usb4: Product: EHCI Host Controller [ 8.811782] usb usb4: Manufacturer: Linux 3.19.0-23-generic ehci_hcd [ 8.813318] usb usb4: SerialNumber: 0000:00:1d.0 [ 8.814607] hub 4-0:1.0: USB hub found [ 8.815451] hub 4-0:1.0: 3 ports detected [ 8.816436] ehci-platform: EHCI generic platform driver [ 8.817860] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 8.819255] ohci-pci: OHCI PCI platform driver [ 8.820224] ohci-platform: OHCI generic platform driver [ 8.821394] uhci_hcd: USB Universal Host Controller Interface driver [ 8.822985] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 8.826563] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 8.827732] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 8.829239] mousedev: PS/2 mouse device common for all mice [ 8.831187] rtc_cmos 00:02: RTC can wake from S4 [ 8.832663] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 [ 8.833318] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 8.837015] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram [ 8.838830] i2c /dev entries driver [ 8.839857] device-mapper: uevent: version 1.0.3 [ 8.841343] device-mapper: ioctl: 4.29.0-ioctl (2014-10-28) initialised: dm-devel@redhat.com [ 8.843768] ledtrig-cpu: registered to indicate activity on CPUs [ 8.845208] EFI Variables Facility v0.08 2004-May-17 At this point the machine is completely hung. I've tried switching to Xen master but I get no output to the monitor and I get no output over the SOL so things are actually worse. I plan on bisecting the tree to find the commit that caused that but have not yet. I'm just looking for some ideas on what to try. I've tried in both cases adding acpi=false and acpi=ht but that has not helped. -- Doug Goldstein _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 23 21:55:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 23 Jul 2015 21:55:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIORg-0007l1-4T; Thu, 23 Jul 2015 21:54:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIO17-0004bU-K5 for xen-users@lists.xen.org; Thu, 23 Jul 2015 21:27:01 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id D5/93-29980-42C51B55; Thu, 23 Jul 2015 21:27:00 +0000 X-Env-Sender: cardoe@cardoe.com X-Msg-Ref: server-5.tower-206.messagelabs.com!1437686817!23255292!1 X-Originating-IP: [209.85.223.177] X-SpamReason: No, hits=0.8 required=7.0 tests=BODY_RANDOM_LONG, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25942 invoked from network); 23 Jul 2015 21:26:58 -0000 Received: from mail-ie0-f177.google.com (HELO mail-ie0-f177.google.com) (209.85.223.177) by server-5.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 23 Jul 2015 21:26:58 -0000 Received: by ietj16 with SMTP id j16so4347541iet.0 for ; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=1+6DBy07PN5bvxHscWE1cMnc0sz4SVK3Xk9P4iEGe3w=; b=efTTYql26nyoKaK+m6zGpw3ecttKV7aLO2eTO7Q6+Nld3pxihiZHm3Sm37OYjCtKbn HG/wjpu9Uc7nHkQdwDu4Awl5WQkhojYM7Lde27d+dEIS8Erv2+SkZghSODTmUdvtkyVB 72f1EBwfhQeAm6dvydDsc6RpXI8yfyb7XIQJaUiqSl4ow97isNuWDmNpIeWxK7qI8K5L Do9xPD6fmEdgzIQomP4mmzAkUZcvnvo1SQXJQtlU1sOwFObRF/JrYCjmnnHQEjrr9xRq ECK8R9LN7OwvFH6zIfDa2+KOUEwva61vEBt8jQO7nPno/azHpWsMhnQ67n/58q/aAzaf 30bw== X-Gm-Message-State: ALoCoQmzJZwCjYCLB/XLfqwMIiXjlgtLRRK1UDbeg24CMxgAzOWavx+dD9ByrF1p36NUOKMMy2GJ MIME-Version: 1.0 X-Received: by 10.50.98.3 with SMTP id ee3mr610253igb.10.1437686817416; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) Received: by 10.107.140.143 with HTTP; Thu, 23 Jul 2015 14:26:57 -0700 (PDT) Date: Thu, 23 Jul 2015 16:26:57 -0500 X-Google-Sender-Auth: MIX2Yixyxunpf9UhY-_eqSS34Hs Message-ID: From: Doug Goldstein To: xen-users@lists.xen.org X-Mailman-Approved-At: Thu, 23 Jul 2015 21:54:26 +0000 Subject: [Xen-users] Xen 4.5.x / master ACPI failures X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I have been trying to get Xen to work for me on a Lenovo T430 laptop for a few days now and I'm hoping someone had some better suggestions to try. I know it should work because I actually have two of these machines. They are identical machines except for the BIOS version (UEFI really). The one where everything is working is running 2.05 of Lenovo's BIOS while the one that is failing is 2.68. Unfortunately Lenovo prevents you from reverting versions. Both machines are able to successfully boot Ubuntu 15.04 where everything related to EFI appears to work correctly. I have tried the Ubuntu 15.04 package (Xen 4.5.0) and I've also built the code from source (using master and the RELEASE-4.5.1 tag). Here's the output of booting from the 4.5.1 build (note I had to apply a patch to get it to compile. I got the patch from the xen-devel mailing list for OCaml dependencies). $ sudo xl dmesg Xen 4.5.1 (XEN) Xen version 4.5.1 (doug@) (gcc (Ubuntu 4.9.2-10ubuntu13) 4.9.2) debug=n Wed Jul 22 15:20:53 CDT 2015 (XEN) Latest ChangeSet: Mon Jun 22 14:12:56 2015 +0100 git:6e865a4-dirty (XEN) Bootloader: GRUB 2.02~beta2-22ubuntu1.1 (XEN) Command line: placeholder loglvl=all no-real-mode edd=off (XEN) Video information: (XEN) VGA is text mode 80x25, font 8x16 (XEN) Disc information: (XEN) Found 0 MBR signatures (XEN) Found 0 EDD information structures (XEN) Multiboot-e820 RAM map: (XEN) 0000000000000000 - 000000000009c000 (usable) (XEN) 000000000009c000 - 000000000009d000 (reserved) (XEN) 000000000009d000 - 000000000009e000 (usable) (XEN) 000000000009e000 - 00000000000c0000 (reserved) (XEN) 0000000000100000 - 0000000020000000 (usable) (XEN) 0000000020000000 - 0000000020200000 (reserved) (XEN) 0000000020200000 - 0000000040004000 (usable) (XEN) 0000000040004000 - 0000000040005000 (reserved) (XEN) 0000000040005000 - 00000000cff31000 (usable) (XEN) 00000000cff31000 - 00000000d0133000 (reserved) (XEN) 00000000d0133000 - 00000000d660b000 (usable) (XEN) 00000000d660b000 - 00000000d680b000 type 20 (XEN) 00000000d680b000 - 00000000daa9f000 (reserved) (XEN) 00000000daa9f000 - 00000000dab9f000 (ACPI NVS) (XEN) 00000000dab9f000 - 00000000dabff000 (ACPI data) (XEN) 00000000dabff000 - 00000000dac00000 (usable) (XEN) 00000000dac00000 - 00000000dfa00000 (reserved) (XEN) 00000000f80f8000 - 00000000f80f9000 (reserved) (XEN) 00000000fed1c000 - 00000000fed90000 (reserved) (XEN) 0000000100000000 - 000000021e600000 (usable) (XEN) 000000021e600000 - 000000021f000000 (reserved) (XEN) ACPI Error (tbxfroot-0218): A valid RSDP was not found [20070126] (XEN) System RAM: 8007MB (8199832kB) (XEN) No NUMA configuration found (XEN) Faking a node at 0000000000000000-000000021e600000 (XEN) Domain heap initialised (XEN) DMI not present. (XEN) Using APIC driver default (XEN) ERST table was not found (XEN) SMP: Allowing 1 CPUs (1 hotplug CPUs) (XEN) Found and enabled local APIC! (XEN) IRQ limits: 16 GSI, 192 MSI/MSI-X (XEN) Not enabling x2APIC: depends on iommu_supports_eim. (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Detected 2594.174 MHz processor. (XEN) Initing memory sharing. (XEN) xstate_init: using cntxt_size: 0x340 and states: 0x7 (XEN) mce_intel.c:719: MCA Capability: BCAST 1 SER 0 CMCI 1 firstbank 0 extended MCE MSR 0 (XEN) Intel machine check reporting enabled (XEN) alt table ffff82d0802bcbd0 -> ffff82d0802bdd28 (XEN) I/O virtualisation disabled (XEN) SMP motherboard not detected. (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) TSC deadline timer enabled (XEN) Platform timer is 1.193MHz PIT (XEN) Allocated console ring of 16 KiB. (XEN) mwait-idle: MWAIT substates: 0x21120 (XEN) mwait-idle: v0.4 model 0x3a (XEN) mwait-idle: lapic_timer_reliable_states 0xffffffff (XEN) VMX: Supported advanced features: (XEN) - APIC MMIO access virtualisation (XEN) - APIC TPR shadow (XEN) - Extended Page Tables (EPT) (XEN) - Virtual-Processor Identifiers (VPID) (XEN) - Virtual NMI (XEN) - MSR direct-access bitmap (XEN) - Unrestricted Guest (XEN) HVM: ASIDs enabled. (XEN) HVM: VMX enabled (XEN) HVM: Hardware Assisted Paging (HAP) detected (XEN) HVM: HAP page sizes: 4kB, 2MB (XEN) Brought up 1 CPUs (XEN) ACPI sleep modes: S3 (XEN) mcheck_poll: Machine check polling timer started. (XEN) Dom0 has maximum 208 PIRQs (XEN) *** LOADING DOMAIN 0 *** (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x200b000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 0000000210000000->0000000214000000 (1968568 pages to be allocated) (XEN) Init. ramdisk: 000000021c6fa000->000000021e5ffaf2 (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff8200b000 (XEN) Init. ramdisk: 0000000000000000->0000000000000000 (XEN) Phys-Mach map: ffffffff8200b000->ffffffff82f3f5f0 (XEN) Start info: ffffffff82f40000->ffffffff82f404b4 (XEN) Page tables: ffffffff82f41000->ffffffff82f5c000 (XEN) Boot stack: ffffffff82f5c000->ffffffff82f5d000 (XEN) TOTAL: ffffffff80000000->ffffffff83000000 (XEN) ENTRY ADDRESS: ffffffff81d4c1f0 (XEN) Dom0 has maximum 1 VCPUs (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ....................................................................done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: Nothing (Rate-limited: Errors and warnings) (XEN) Xen is relinquishing VGA console. (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000081 from 0xe023e00800000000 to 0x0023001000000000. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000082 from 0xffff82d0802c3000 to 0xffffffff817cb1d0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802c3080 to 0xffffffff817cd7a0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000174 from 0x000000000000e008 to 0x0000000000000010. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000175 from 0xffff82d0802c7fc0 to 0x0000000000000000. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 0000000000000176 from 0xffff82d080225f00 to 0xffffffff817cdab0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000083 from 0xffff82d0802c3080 to 0xffffffff817cdcf0. (XEN) traps.c:2589:d0v0 Domain attempted WRMSR 00000000c0000084 from 0x0000000000074700 to 0x0000000000047700. (XEN) PCI add device 0000:00:00.0 (XEN) PCI add device 0000:00:02.0 (XEN) PCI add device 0000:00:14.0 (XEN) PCI add device 0000:00:16.0 (XEN) PCI add device 0000:00:16.3 (XEN) PCI add device 0000:00:19.0 (XEN) PCI add device 0000:00:1a.0 (XEN) PCI add device 0000:00:1b.0 (XEN) PCI add device 0000:00:1c.0 (XEN) PCI add device 0000:00:1c.1 (XEN) PCI add device 0000:00:1d.0 (XEN) PCI add device 0000:00:1f.0 (XEN) PCI add device 0000:00:1f.2 (XEN) PCI add device 0000:00:1f.3 (XEN) PCI add device 0000:02:00.0 (XEN) PCI add device 0000:03:00.0 (XEN) traps.c:3161: GPF (0000): ffff82d080190f5d -> ffff82d08022a693 (XEN) traps.c:3161: GPF (0000): ffff82d080190f5d -> ffff82d08022a693 When booting on the working T430, I don't see the error about ACPI RSDP missing and the machine properly sees 4 cores. I figured if I was able to boot Xen via EFI then things would work a little bit better. Unfortunately the screen was completely black when I managed this but I did manage to configure Intel AMT SOL and get output from what appears to be the dom0 kernel. Unfortunately it too hangs. amtterm: INIT_SOL -> RUN_SOL (serial-over-lan active) serial-over-lan redirection ok connected now, use ^] to escape 0] init_memory_mapping: [mem 0x40005000-0xceaacfff] [ 0.000000] init_memory_mapping: [mem 0xcecaf000-0xd660afff] [ 0.000000] init_memory_mapping: [mem 0xdabff000-0xdabfffff] [ 0.000000] init_memory_mapping: [mem 0x100000000-0x1bfffffff] [ 0.000000] init_memory_mapping: [mem 0x1e5200000-0x21e5fffff] [ 0.000000] RAMDISK: [mem 0x04000000-0x05f09fff] [ 0.000000] ACPI: Early table checksum verification disabled [ 0.000000] ACPI: RSDP 0x00000000DABFE014 000024 (v02 LENOVO) [ 0.000000] ACPI: XSDT 0x00000000DABFE170 0000CC (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: FACP 0x00000000DABE6000 00010C (v05 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DSDT 0x00000000DABE8000 0103F7 (v01 LENOVO TP-G1 00002680 INTL 20061109) [ 0.000000] ACPI: FACS 0x00000000DAB5A000 000040 [ 0.000000] ACPI: SLIC 0x00000000DABFD000 000176 (v01 LENOVO TP-G1 00002680 PTL 00000001) [ 0.000000] ACPI: TCPA 0x00000000DABFC000 000032 (v02 PTL LENOVO 06040000 LNVO 00000001) [ 0.000000] ACPI: SSDT 0x00000000DABFB000 000408 (v01 LENOVO TP-SSDT2 00000200 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABFA000 000033 (v01 LENOVO TP-SSDT1 00000100 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABF9000 000797 (v01 LENOVO SataAhci 00001000 INTL 20061109) [ 0.000000] ACPI: HPET 0x00000000DABE4000 000038 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: APIC 0x00000000DABE3000 000098 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: MCFG 0x00000000DABE2000 00003C (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: ECDT 0x00000000DABE1000 000052 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: FPDT 0x00000000DABE0000 000064 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: ASF! 0x00000000DABE7000 0000A5 (v32 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000DABDF000 00003E (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: UEFI 0x00000000DABDE000 000042 (v01 PTL COMBUF 00000001 PTL 00000001) [ 0.000000] ACPI: POAT 0x00000000DABDD000 000055 (v03 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: SSDT 0x00000000DABDC000 000C51 (v01 PmRef Cpu0Ist 00003000 INTL 20061109) [ 0.000000] ACPI: SSDT 0x00000000DABDB000 000A83 (v01 PmRef CpuPm 00003000 INTL 20061109) [ 0.000000] ACPI: XMAR 0x00000000DABDA000 0000B8 (v01 INTEL SNB 00000001 INTL 00000001) [ 0.000000] ACPI: UEFI 0x00000000DABD9000 0002A6 (v01 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DBG2 0x00000000DABD8000 0000E9 (v00 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: BGRT 0x00000000DABD7000 000038 (v00 LENOVO TP-G1 00002680 PTL 00000002) [ 0.000000] ACPI: DMI detected: Lenovo ThinkPad T430 [ 0.000000] NUMA turned off [ 0.000000] Faking a node at [mem 0x0000000000000000-0x000000021e5fffff] [ 0.000000] NODE_DATA(0) allocated [mem 0x1e53bb000-0x1e53bffff] [ 0.000000] Zone ranges: [ 0.000000] DMA [mem 0x00001000-0x00ffffff] [ 0.000000] DMA32 [mem 0x01000000-0xffffffff] [ 0.000000] Normal [mem 0x100000000-0x21e5fffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x00001000-0x0009bfff] [ 0.000000] node 0: [mem 0x0009d000-0x0009dfff] [ 0.000000] node 0: [mem 0x00100000-0x1fffffff] [ 0.000000] node 0: [mem 0x20200000-0x40003fff] [ 0.000000] node 0: [mem 0x40005000-0xceaacfff] [ 0.000000] node 0: [mem 0xcecaf000-0xd660afff] [ 0.000000] node 0: [mem 0xdabff000-0xdabfffff] [ 0.000000] node 0: [mem 0x100000000-0x21e5fffff] [ 0.000000] Initmem setup node 0 [mem 0x00001000-0x21e5fffff] [ 0.000000] p2m virtual area at ffffc90000000000, size is 40000000 [ 0.000000] Remapped 171610 page(s) [ 0.000000] Reserving Intel graphics stolen memory at 0xdba00000-0xdf9fffff [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x05] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x06] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x07] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC (acpi_id[0x08] lapic_id[0x00] disabled) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] ACPI: HPET id: 0x8086a301 base: 0xfed00000 [ 0.000000] smpboot: Allowing 8 CPUs, 4 hotplug CPUs [ 0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009c000-0x0009cfff] [ 0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x000fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x20000000-0x201fffff] [ 0.000000] PM: Registered nosave memory: [mem 0x40004000-0x40004fff] [ 0.000000] PM: Registered nosave memory: [mem 0xceaad000-0xcecaefff] [ 0.000000] PM: Registered nosave memory: [mem 0xd660b000-0xdaa9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xdaa9f000-0xdab9efff] [ 0.000000] PM: Registered nosave memory: [mem 0xdab9f000-0xdabfefff] [ 0.000000] PM: Registered nosave memory: [mem 0xdac00000-0xdf9fffff] [ 0.000000] PM: Registered nosave memory: [mem 0xdfa00000-0xf80f7fff] [ 0.000000] PM: Registered nosave memory: [mem 0xf80f8000-0xf80f8fff] [ 0.000000] PM: Registered nosave memory: [mem 0xf80f9000-0xfebfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec00fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfec01000-0xfed1bfff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed1c000-0xfed91fff] [ 0.000000] PM: Registered nosave memory: [mem 0xfed92000-0xfedfffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfeefffff] [ 0.000000] PM: Registered nosave memory: [mem 0xfef00000-0xffffffff] [ 0.000000] e820: [mem 0xdfa00000-0xf80f7fff] available for PCI devices [ 0.000000] Booting paravirtualized kernel on Xen [ 0.000000] Xen version: 4.5.1 (preserve-AD) [ 0.000000] setup_percpu: NR_CPUS:256 nr_cpumask_bits:256 nr_cpu_ids:8 nr_node_ids:1 [ 0.000000] PERCPU: Embedded 31 pages/cpu @ffff88020f000000 s87040 r8192 d31744 u262144 [ 0.000000] Built 1 zonelists in Node order, mobility grouping on. Total pages: 2017903 [ 0.000000] Policy zone: Normal [ 0.000000] Kernel command line: root=/dev/mapper/ubuntu--vg-root ro console=ttyS4,115200 [ 0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes) [ 0.000000] xsave: enabled xstate_bv 0x7, cntxt size 0x340 using standard form [ 0.000000] software IO TLB [mem 0x20b000000-0x20f000000] (64MB) mapped at [ffff88020b000000-ffff88020effffff] [ 0.000000] Memory: 7671056K/8199828K available (8002K kernel code, 1232K rwdata, 3760K rodata, 1408K init, 1300K bss, 528772K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1 [ 0.000000] Hierarchical RCU implementation. [ 0.000000] RCU dyntick-idle grace-period acceleration is enabled. [ 0.000000] RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=4. [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4 [ 0.000000] NR_IRQS:16640 nr_irqs:456 16 [ 0.000000] xen:events: Using FIFO-based ABI [ 0.000000] Offload RCU callbacks from all CPUs [ 0.000000] Offload RCU callbacks from CPUs: 0-3. [ 0.000000] Console: colour dummy device 80x25 [ 0.000000] installing Xen timer for CPU 0 [ 0.000000] tsc: Detected 2594.184 MHz processor [ 7.146988] Calibrating delay loop (skipped), value calculated using timer frequency.. 5188.36 BogoMIPS (lpj=10376736) [ 7.146991] pid_max: default: 32768 minimum: 301 [ 7.146997] ACPI: Core revision 20141107 [ 7.188413] ACPI: All ACPI Tables successfully acquired [ 7.189354] Security Framework initialized [ 7.189374] AppArmor: AppArmor initialized [ 7.189375] Yama: becoming mindful. [ 7.190387] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) [ 7.192568] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 7.193430] Mount-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 7.193448] Mountpoint-cache hash table entries: 16384 (order: 5, 131072 bytes) [ 7.193703] Initializing cgroup subsys memory [ 7.193709] Initializing cgroup subsys devices [ 7.193711] Initializing cgroup subsys freezer [ 7.193714] Initializing cgroup subsys net_cls [ 7.193717] Initializing cgroup subsys blkio [ 7.193719] Initializing cgroup subsys perf_event [ 7.193721] Initializing cgroup subsys net_prio [ 7.193723] Initializing cgroup subsys hugetlb [ 7.193782] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [ 7.193782] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [ 7.193785] CPU: Physical Processor ID: 0 [ 7.193786] CPU: Processor Core ID: 0 [ 7.194130] mce: CPU supports 2 MCE banks [ 7.194145] Last level iTLB entries: 4KB 512, 2MB 8, 4MB 8 [ 7.194145] Last level dTLB entries: 4KB 512, 2MB 32, 4MB 32, 1GB 0 [ 7.194256] Freeing SMP alternatives memory: 32K (ffffffff81e96000 - ffffffff81e9e000) [ 7.195562] Ignoring BGRT: invalid version 0 (expected 1) [ 7.195564] ftrace: allocating 30087 entries in 118 pages [ 7.208712] cpu 0 spinlock event irq 25 [ 7.217813] Performance Events: unsupported p6 CPU model 58 no PMU driver, software events only. [ 7.218521] NMI watchdog: disabled (cpu0): hardware events not enabled [ 7.218604] installing Xen timer for CPU 1 [ 7.218611] cpu 1 spinlock event irq 32 [ 7.219244] installing Xen timer for CPU 2 [ 7.219251] cpu 2 spinlock event irq 39 [ 7.219845] installing Xen timer for CPU 3 [ 7.219851] cpu 3 spinlock event irq 46 [ 7.220376] x86: Booted up 1 node, 4 CPUs [ 7.220637] devtmpfs: initialized [ 7.223116] evm: security.selinux [ 7.223117] evm: security.SMACK64 [ 7.223118] evm: security.SMACK64EXEC [ 7.223119] evm: security.SMACK64TRANSMUTE [ 7.223120] evm: security.SMACK64MMAP [ 7.223121] evm: security.ima [ 7.223121] evm: security.capability [ 7.223210] PM: Registering ACPI NVS region [mem 0xdaa9f000-0xdab9efff] (1048576 bytes) [ 7.223406] pinctrl core: initialized pinctrl subsystem [ 7.223519] RTC time: 19:29:27, date: 07/23/15 [ 7.223614] NET: Registered protocol family 16 [ 7.223624] xen:grant_table: Grant tables using version 1 layout [ 7.223634] Grant table initialized [ 7.223890] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it [ 7.223892] ACPI: bus type PCI registered [ 7.223894] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 [ 7.224154] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 7.224156] PCI: not using MMCONFIG [ 7.224158] PCI: Using configuration type 1 for base access [ 7.229414] ACPI: Added _OSI(Module Device) [ 7.229418] ACPI: Added _OSI(Processor Device) [ 7.229420] ACPI: Added _OSI(3.0 _SCP Extensions) [ 7.229421] ACPI: Added _OSI(Processor Aggregator Device) [ 7.229422] ACPI: Deleted _OSI(Windows 2012) [ 7.230902] ACPI : EC: EC description table is found, configuring boot EC [ 7.236808] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored [ 7.239868] ACPI: Dynamic OEM Table Load: [ 7.239880] ACPI: SSDT 0xFFFF8802094B1000 000A01 (v01 PmRef Cpu0Cst 00003001 INTL 20061109) [ 7.240532] ACPI: Dynamic OEM Table Load: [ 7.240541] ACPI: SSDT 0xFFFF8802094D8C00 000303 (v01 PmRef ApIst 00003000 INTL 20061109) [ 7.241039] ACPI: Dynamic OEM Table Load: [ 7.241047] ACPI: SSDT 0xFFFF88020946B400 000119 (v01 PmRef ApCst 00003000 INTL 20061109) [ 7.242076] ACPI: Interpreter enabled [ 7.242081] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S1_] (20141107/hwxface-580) [ 7.242085] ACPI Exception: AE_NOT_FOUND, While evaluating Sleep State [\_S2_] (20141107/hwxface-580) [ 7.242097] ACPI: (supports S0 S3 S4 S5) [ 7.242098] ACPI: Using IOAPIC for interrupt routing [ 7.242112] PCI: MMCONFIG for domain 0000 [bus 00-3f] at [mem 0xf8000000-0xfbffffff] (base 0xf8000000) [ 7.242549] PCI: MMCONFIG at [mem 0xf8000000-0xfbffffff] reserved in ACPI motherboard resources [ 7.248776] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug [ 7.251372] ACPI: Power Resource [PUBS] (on) [ 7.252009] acpi PNP0C0A:01: ACPI dock station (docks/bays count: 1) [ 7.252846] acpi LNXIOBAY:00: ACPI dock station (docks/bays count: 2) [ 7.255247] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255336] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255423] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255511] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255598] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255684] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255769] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255855] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 11) *0, disabled. [ 7.255943] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-3f]) [ 7.255947] acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI] [ 7.256090] acpi PNP0A08:00: _OSC: platform does not support [PCIeCapability] [ 7.256153] acpi PNP0A08:00: _OSC: not requesting control; platform does not support [PCIeCapability] [ 7.256156] acpi PNP0A08:00: _OSC: OS requested [PCIeHotplug PME AER PCIeCapability] [ 7.256157] acpi PNP0A08:00: _OSC: platform willing to grant [PCIeHotplug PME AER] [ 7.256159] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM [ 7.256304] PCI host bridge to bus 0000:00 [ 7.256307] pci_bus 0000:00: root bus resource [bus 00-3f] [ 7.256308] pci_bus 0000:00: root bus resource [io 0x0000-0x0cf7] [ 7.256310] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] [ 7.256311] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] [ 7.256313] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000c3fff] [ 7.256314] pci_bus 0000:00: root bus resource [mem 0x000c4000-0x000c7fff] [ 7.256316] pci_bus 0000:00: root bus resource [mem 0x000c8000-0x000cbfff] [ 7.256317] pci_bus 0000:00: root bus resource [mem 0x000cc000-0x000cffff] [ 7.256318] pci_bus 0000:00: root bus resource [mem 0x000d0000-0x000d3fff] [ 7.256320] pci_bus 0000:00: root bus resource [mem 0x000d4000-0x000d7fff] [ 7.256321] pci_bus 0000:00: root bus resource [mem 0x000d8000-0x000dbfff] [ 7.256322] pci_bus 0000:00: root bus resource [mem 0x000dc000-0x000dffff] [ 7.256324] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000e3fff] [ 7.256325] pci_bus 0000:00: root bus resource [mem 0x000e4000-0x000e7fff] [ 7.256327] pci_bus 0000:00: root bus resource [mem 0x000e8000-0x000ebfff] [ 7.256328] pci_bus 0000:00: root bus resource [mem 0x000ec000-0x000effff] [ 7.256329] pci_bus 0000:00: root bus resource [mem 0xdfa00000-0xfebfffff] [ 7.256331] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed4bfff] [ 7.257025] pci 0000:00:14.0: System wakeup disabled by ACPI [ 7.258052] pci 0000:00:19.0: System wakeup disabled by ACPI [ 7.258424] pci 0000:00:1a.0: System wakeup disabled by ACPI [ 7.258782] pci 0000:00:1b.0: System wakeup disabled by ACPI [ 7.259112] pci 0000:00:1c.0: Enabling MPC IRBNCE [ 7.259116] pci 0000:00:1c.0: Intel PCH root port ACS workaround enabled [ 7.259454] pci 0000:00:1c.1: Enabling MPC IRBNCE [ 7.259458] pci 0000:00:1c.1: Intel PCH root port ACS workaround enabled [ 7.259861] pci 0000:00:1d.0: System wakeup disabled by ACPI [ 7.261131] pci 0000:02:00.0: MMC controller base frequency changed to 50Mhz. [ 7.268901] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 7.276940] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 7.278264] ACPI: Enabled 4 GPEs in block 00 to 3F [ 7.278319] ACPI : EC: GPE = 0x11, I/O: command/status = 0x66, data = 0x62 [ 7.278360] xen:balloon: Initialising balloon driver [ 7.279103] xen_balloon: Initialising balloon driver [ 7.279243] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=mem,locks=none [ 7.279247] vgaarb: loaded [ 7.279248] ved traffic allowed by default [ 7.285738] Switched to clocksource xen [ 7.291057] AppArmor: AppArmor Filesystem Enabled [ 7.291124] pnp: PnP ACPI init [ 7.291565] system 00:00: [mem 0x00000000-0x0009ffff] could not be reserved [ 7.291568] system 00:00: [mem 0x000f0000-0x000fffff] could not be reserved [ 7.291569] system 00:00: [mem 0x00100000-0xdf9fffff] could not be reserved [ 7.291571] system 00:00: [mem 0xfec00000-0xfed3ffff] could not be reserved [ 7.291573] system 00:00: [mem 0xfed4c000-0xffffffff] could not be reserved [ 7.291664] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff] [ 7.291682] system 00:01: [io 0x0400-0x047f] could not be reserved [ 7.291684] system 00:01: [io 0x0500-0x057f] has been reserved [ 7.291686] system 00:01: [io 0x0800-0x080f] has been reserved [ 7.291687] system 00:01: [io 0x15e0-0x15ef] has been reserved [ 7.291689] system 00:01: [io 0x1600-0x167f] has been reserved [ 7.291691] system 00:01: [mem 0xf8000000-0xfbffffff] could not be reserved [ 7.291693] system 00:01: [mem 0xfffff000-0xffffffff] has been reserved [ 7.291694] system 00:01: [mem 0xfed1c000-0xfed1ffff] has been reserved [ 7.291696] system 00:01: [mem 0xfed10000-0xfed17fff] has been reserved [ 7.291698] system 00:01: [mem 0xfed18000-0xfed18fff] has been reserved [ 7.291699] system 00:01: [mem 0xfed19000-0xfed19fff] has been reserved [ 7.291701] system 00:01: [mem 0xfed45000-0xfed4bfff] has been reserved [ 7.292499] pnp: PnP ACPI: found 6 devices [ 7.299137] PM-Timer failed consistency check (0xffffff) - aborting. [ 7.299185] pci 0000:00:1c.0: PCI bridge to [bus 02] [ 7.299193] pci 0000:00:1c.0: bridge window [io 0x3000-0x3fff] [ 7.299202] pci 0000:00:1c.0: bridge window [mem 0xf0d00000-0xf14fffff] [ 7.299209] pci 0000:00:1c.0: bridge window [mem 0xf0400000-0xf0bfffff 64bit pref] [ 7.299222] pci 0000:00:1c.1: PCI bridge to [bus 03] [ 7.299231] pci 0000:00:1c.1: bridge window [mem 0xf0c00000-0xf0cfffff] [ 7.299304] NET: Registered protocol family 2 [ 7.299523] TCP established hash table entries: 65536 (order: 7, 524288 bytes) [ 7.299757] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 7.299863] TCP: Hash tables configured (established 65536 bind 65536) [ 7.299881] TCP: reno registered [ 7.299900] UDP hash table entries: 4096 (order: 5, 131072 bytes) [ 7.299935] UDP-Lite hash table entries: 4096 (order: 5, 131072 bytes) [ 7.299991] NET: Registered protocol family 1 [ 7.300291] Already setup the GSI :16 [ 7.300662] Trying to unpack rootfs image as initramfs... [ 7.766016] Freeing initrd memory: 31784K (ffff880004000000 - ffff880005f0a000) [ 7.766293] RAPL PMU detected, hw unit 2^-16 Joules, API unit is 2^-32 Joules, 3 fixed counters 163840 ms ovfl timer [ 7.766341] Scanning for low memory corruption every 60 seconds [ 7.766929] futex hash table entries: 1024 (order: 4, 65536 bytes) [ 7.766949] Initialise system trusted keyring [ 7.766972] audit: initializing netlink subsys (disabled) [ 7.766986] audit: type=2000 audit(1437679767.311:1): initialized [ 7.767393] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 7.768609] zpool: loaded [ 7.768613] zbud: loaded [ 7.768846] VFS: Disk quotas dquot_6.5.2 [ 7.768882] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 7.769439] fuse init (API version 7.23) [ 7.769653] Key type big_key registered [ 7.770230] Key type asymmetric registered [ 7.770233] Asymmetric key parser 'x509' registered [ 7.770268] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 252) [ 7.770322] io scheduler noop registered [ 7.770326] io scheduler deadline registered (default) [ 7.770363] io scheduler cfq registered [ 7.770503] Already setup the GSI :16 [ 7.770806] pci_hotplug: PCI Hot Plug PCI Core version: 0.5 [ 7.770823] pciehp: PCI Express Hot Plug Controller Driver version: 0.4 [ 7.770857] efifb: probing for efifb [ 7.771634] efifb: framebuffer at 0xe0000000, mapped to 0xffffc90044f00000, using 8100k, total 8100k [ 7.771636] efifb: mode is 1920x1080x32, linelength=7680, pages=1 [ 7.771636] efifb: scrolling: redraw [ 7.771638] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [ 7.775355] Console: switching to colour frame buffer device 240x67 [ 7.778971] fb0: EFI VGA frame buffer device [ 7.779658] ACPI: AC Adapter [AC] (on-line) [ 7.780163] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input0 [ 7.780316] ACPI: Lid Switch [LID] [ 7.780352] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input1 [ 7.780355] ACPI: Sleep Button [SLPB] [ 7.780393] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input2 [ 7.780395] ACPI: Power Button [PWRF] [ 7.784040] thermal LNXTHERM:00: registered as thermal_zone0 [ 7.784042] ACPI: Thermal Zone [THM0] (50 C) [ 7.784070] GHES: HEST is not enabled! [ 7.797527] ACPI: Battery Slot [BAT0] (battery present) [ 7.800895] xen_acpi_processor: Uploading Xen processor PM info [ 7.804347] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled [ 7.805995] console [ttyS4] disabled [ 7.826547] 0000:00:16.3: ttyS4 at I/O 0x40b0 (irq = 19, base_baud = 115200) is a 16550A [ 8.593884] console [ttyS4] enabled [ 8.594970] hpet_acpi_add: no address or irqs in _CRS [ 8.596063] Linux agpgart interface v0.103 [ 8.597486] tpm_tis 00:05: 1.2 TPM (device-id 0x0, rev-id 78) [ 8.709809] brd: module loaded [ 8.711980] loop: module loaded [ 8.713253] libphy: Fixed MDIO Bus: probed [ 8.714415] tun: Universal TUN/TAP device driver, 1.6 [ 8.715736] tun: (C) 1999-2004 Max Krasnyansky [ 8.717548] PPP generic driver version 2.4.2 [ 8.718799] xen_netfront: Initialising Xen virtual ethernet driver [ 8.720433] Already setup the GSI :16 [ 8.721232] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 8.722434] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 1 [ 8.724193] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.725601] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.727105] usb usb1: Product: xHCI Host Controller [ 8.728221] usb usb1: Manufacturer: Linux 3.19.0-23-generic xhci-hcd [ 8.729526] usb usb1: SerialNumber: 0000:00:14.0 [ 8.730653] hub 1-0:1.0: USB hub found [ 8.731444] hub 1-0:1.0: 4 ports detected [ 8.732728] xhci_hcd 0000:00:14.0: xHCI Host Controller [ 8.734487] xhci_hcd 0000:00:14.0: new USB bus registered, assigned bus number 2 [ 8.736089] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003 [ 8.738417] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.739917] usb usb2: Product: xHCI Host Controller [ 8.740949] usb usb2: Manufacturer: Linux 3.19.0-23-generic xhci-hcd [ 8.742465] usb usb2: SerialNumber: 0000:00:14.0 [ 8.743574] hub 2-0:1.0: USB hub found [ 8.744365] hub 2-0:1.0: 4 ports detected [ 8.745627] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 8.746995] ehci-pci: EHCI PCI platform driver [ 8.748017] Already setup the GSI :16 [ 8.748814] ehci-pci 0000:00:1a.0: EHCI Host Controller [ 8.749921] ehci-pci 0000:00:1a.0: new USB bus registered, assigned bus number 3 [ 8.751477] ehci-pci 0000:00:1a.0: debug port 2 [ 8.762871] ehci-pci 0000:00:1a.0: irq 16, io mem 0xf153a000 [ 8.773799] ehci-pci 0000:00:1a.0: USB 2.0 started, EHCI 1.00 [ 8.776195] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.777714] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.779216] usb usb3: Product: EHCI Host Controller [ 8.780259] usb usb3: Manufacturer: Linux 3.19.0-23-generic ehci_hcd [ 8.781574] usb usb3: SerialNumber: 0000:00:1a.0 [ 8.782939] hub 3-0:1.0: USB hub found [ 8.783772] hub 3-0:1.0: 3 ports detected [ 8.784838] Already setup the GSI :23 [ 8.785633] ehci-pci 0000:00:1d.0: EHCI Host Controller [ 8.786761] ehci-pci 0000:00:1d.0: new USB bus registered, assigned bus number 4 [ 8.788462] ehci-pci 0000:00:1d.0: debug port 2 [ 8.793457] ehci-pci 0000:00:1d.0: irq 23, io mem 0xf1539000 [ 8.805803] ehci-pci 0000:00:1d.0: USB 2.0 started, EHCI 1.00 [ 8.807098] usb usb4: New USB device found, idVendor=1d6b, idProduct=0002 [ 8.808657] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 8.810686] usb usb4: Product: EHCI Host Controller [ 8.811782] usb usb4: Manufacturer: Linux 3.19.0-23-generic ehci_hcd [ 8.813318] usb usb4: SerialNumber: 0000:00:1d.0 [ 8.814607] hub 4-0:1.0: USB hub found [ 8.815451] hub 4-0:1.0: 3 ports detected [ 8.816436] ehci-platform: EHCI generic platform driver [ 8.817860] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 8.819255] ohci-pci: OHCI PCI platform driver [ 8.820224] ohci-platform: OHCI generic platform driver [ 8.821394] uhci_hcd: USB Universal Host Controller Interface driver [ 8.822985] i8042: PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12 [ 8.826563] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 8.827732] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 8.829239] mousedev: PS/2 mouse device common for all mice [ 8.831187] rtc_cmos 00:02: RTC can wake from S4 [ 8.832663] rtc_cmos 00:02: rtc core: registered rtc_cmos as rtc0 [ 8.833318] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input3 [ 8.837015] rtc_cmos 00:02: alarms up to one month, y3k, 114 bytes nvram [ 8.838830] i2c /dev entries driver [ 8.839857] device-mapper: uevent: version 1.0.3 [ 8.841343] device-mapper: ioctl: 4.29.0-ioctl (2014-10-28) initialised: dm-devel@redhat.com [ 8.843768] ledtrig-cpu: registered to indicate activity on CPUs [ 8.845208] EFI Variables Facility v0.08 2004-May-17 At this point the machine is completely hung. I've tried switching to Xen master but I get no output to the monitor and I get no output over the SOL so things are actually worse. I plan on bisecting the tree to find the commit that caused that but have not yet. I'm just looking for some ideas on what to try. I've tried in both cases adding acpi=false and acpi=ht but that has not helped. -- Doug Goldstein _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 24 11:53:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 11:53:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbWU-0001Id-9Z; Fri, 24 Jul 2015 11:52:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbWT-0001IT-4G for xen-users@lists.xen.org; Fri, 24 Jul 2015 11:52:17 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id C5/8B-12200-0F622B55; Fri, 24 Jul 2015 11:52:16 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1437738734!23397386!1 X-Originating-IP: [209.85.213.182] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8296 invoked from network); 24 Jul 2015 11:52:15 -0000 Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com) (209.85.213.182) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 11:52:15 -0000 Received: by igk11 with SMTP id 11so3650910igk.1 for ; Fri, 24 Jul 2015 04:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=mWaNUf/Wxr3qJsr7hYOeE1jrJ2aLnhqcVMMtpPXHBNE=; b=WCp12HDsaZrGd1uEvpZYDmnFK5SG1usfgqI9sMau+Go2oMblSkpBlOOhnNbL4xTxEO 9E+aS5LVrVCp1nAAirMnerwed4/sfwsNgqpiq97rrylzjZ8gRgeQjEjjQ43GxLAe6zNP YXCmxNRLatsJ5ufHuIlIaOOzxFS+Qa8+Iw11HZBGChljkknW0+2wTg/E/2RMUI3qOUzM O10bMN90TK0Km56r6+cuPs5aR2snvzHhSTXgL9b1fifXms3bU1WEFL+UuQnuEW1DBR0B 5NjHqNqSt22FUmcsPSfkYCtnSAG2nR0v9y7WtoIEmTFqaIH3z08Hoe9rIRuu2bEibuJ1 NGQQ== X-Gm-Message-State: ALoCoQns3Ql3N9fwomljnrR+P1O+0aFAccUtqMtst4kA0XNmoPpsExJhkZ4ucdrZ0zk+wiyewFvC X-Received: by 10.107.11.149 with SMTP id 21mr22505072iol.103.1437738734197; Fri, 24 Jul 2015 04:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Fri, 24 Jul 2015 04:51:54 -0700 (PDT) In-Reply-To: References: <1437558204.8383.68.camel@citrix.com> <1437561546.12884.19.camel@citrix.com> From: Gabriel Queiroz Silva Date: Fri, 24 Jul 2015 08:51:54 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2373801094052302979==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2373801094052302979== Content-Type: multipart/alternative; boundary=001a113ede9288280b051b9da26e --001a113ede9288280b051b9da26e Content-Type: text/plain; charset=UTF-8 Just in case anyone bumps on this thread: I've gone through the upgrade and it was as simple as promised. Boot up the Xen Server 6.2 disk, upgrade from there. Took me half an hour. Cheers, *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 8:55 GMT-03:00 Gabriel Queiroz Silva : > Thanks Ian. Will try there again. > > > *Gabriel Queiroz* > > *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 > <%2B55%2061%208117-8050>* > gabriel@flowecommerce.com . www.flowecommerce.com > > > > 2015-07-22 7:39 GMT-03:00 Ian Campbell : > >> On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: >> > I have already asked XCP questions there before and have been >> > recommended to try these lists instead. >> >> For a pure XCP question that is probably correct, however for an >> upgrade to XenServer I think the xenserver.org resources are going to >> be the most likely place you will find help. >> >> > Anyway, if by any chance someone could point me to any material >> > regarding this migration I would be extremely thankful. >> >> I don't have anything myself. >> >> Ian. >> > > --001a113ede9288280b051b9da26e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just in case anyone bumps on this thread: I've gone th= rough the upgrade and it was as simple as promised. Boot up the Xen Server = 6.2 disk, upgrade from there. Took me half an hour.

Chee= rs,
 ------=_Part_2317774_1210723736.1437786105532-- --===============4110564550285854196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4110564550285854196==-- From xen-users-bounces@lists.xen.org Sat Jul 25 08:26:47 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 08:26:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIum1-00052A-Ka; Sat, 25 Jul 2015 08:25:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIulz-00051m-RV for xen-users@lists.xen.org; Sat, 25 Jul 2015 08:25:35 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 82/A9-03895-FF743B55; Sat, 25 Jul 2015 08:25:35 +0000 X-Env-Sender: prvs=641bf62ed=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1437812733!29207722!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18356 invoked from network); 25 Jul 2015 08:25:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 25 Jul 2015 08:25:34 -0000 X-IronPort-AV: E=Sophos;i="5.15,542,1432598400"; d="scan'208";a="284326304" Message-ID: <1437812729.28924.5.camel@citrix.com> From: Ian Campbell To: Mark Pryor , Xen-users Date: Sat, 25 Jul 2015 09:25:29 +0100 In-Reply-To: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> References: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Request backport from staging to stable-4.5 2d70c9ce79d0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-25 at 01:01 +0000, Mark Pryor wrote: > Xen, > > git checkout staging > git show 2d70c9ce79d0 --format=fuller > > the above patch will fix the linking errors when building xen-4.5.x > in Vivid 15.04 with > systemd & ocamltools support. > > Please backport this patch to stable-4.5 Backport requests should be made on the xen-devel list and should copy the stable release managers, they are listed in the second section of the MAINTAINERS file in the source tree for a given stable branch. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 25 08:26:47 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 08:26:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIum1-00052A-Ka; Sat, 25 Jul 2015 08:25:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIulz-00051m-RV for xen-users@lists.xen.org; Sat, 25 Jul 2015 08:25:35 +0000 Received: from [85.158.137.68] by server-10.bemta-3.messagelabs.com id 82/A9-03895-FF743B55; Sat, 25 Jul 2015 08:25:35 +0000 X-Env-Sender: prvs=641bf62ed=Ian.Campbell@citrix.com X-Msg-Ref: server-3.tower-31.messagelabs.com!1437812733!29207722!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 18356 invoked from network); 25 Jul 2015 08:25:34 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-3.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 25 Jul 2015 08:25:34 -0000 X-IronPort-AV: E=Sophos;i="5.15,542,1432598400"; d="scan'208";a="284326304" Message-ID: <1437812729.28924.5.camel@citrix.com> From: Ian Campbell To: Mark Pryor , Xen-users Date: Sat, 25 Jul 2015 09:25:29 +0100 In-Reply-To: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> References: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Request backport from staging to stable-4.5 2d70c9ce79d0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Sat, 2015-07-25 at 01:01 +0000, Mark Pryor wrote: > Xen, > > git checkout staging > git show 2d70c9ce79d0 --format=fuller > > the above patch will fix the linking errors when building xen-4.5.x > in Vivid 15.04 with > systemd & ocamltools support. > > Please backport this patch to stable-4.5 Backport requests should be made on the xen-devel list and should copy the stable release managers, they are listed in the second section of the MAINTAINERS file in the source tree for a given stable branch. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Sat Jul 25 11:05:36 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 11:05:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIxFk-00026x-S9; Sat, 25 Jul 2015 11:04:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIvPM-0000VB-J3 for xen-users@lists.xen.org; Sat, 25 Jul 2015 09:06:17 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 0E/50-20308-78153B55; Sat, 25 Jul 2015 09:06:15 +0000 X-Env-Sender: graham@crowie.net X-Msg-Ref: server-15.tower-206.messagelabs.com!1437815160!7836017!1 X-Originating-IP: [115.70.75.133] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6902 invoked from network); 25 Jul 2015 09:06:04 -0000 Received: from 133.75.70.115.static.exetel.com.au (HELO ext.crowie.net) (115.70.75.133) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Jul 2015 09:06:04 -0000 Received: from [192.168.131.55] (studyL.crowie.net [192.168.131.55]) by ext.crowie.net (8.14.7/8.14.7) with ESMTP id t6P95iD5014367; Sat, 25 Jul 2015 19:05:46 +1000 Message-ID: <55B3515F.20304@crowie.net> Date: Sat, 25 Jul 2015 19:05:35 +1000 From: Graham Crowe User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Campbell , gcxenlist@crowie.net, Alan Lam , "xen-users@lists.xen.org" References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> In-Reply-To: <1437744928.24746.96.camel@citrix.com> Content-Type: multipart/mixed; boundary="------------080608020509070909010404" X-Mailman-Approved-At: Sat, 25 Jul 2015 11:04:27 +0000 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --------------080608020509070909010404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit My config and qemu logs are attached. There is one rather telling line in the qemu log... "Unknown PV product 2 loaded in guest" I suspect it may be because I am using an old version of the PV drivers (the most recent sites are offline, so I used an older one) Is anyone able to point me to the latest PV drivers to try (WinXP, Win7 32 bit and Win7 64 bit)? As for the suggestion that I roll back to a snapshot. This is basically a fresh Windows install (I am just only starting a trial of Windows VMs - I already have a number of Linux VMs) so a snapshot won't help me much. Thanks On 24/07/2015 11:35 PM, Ian Campbell wrote: > On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: >> I installed the PV drivers in some windows PVs as I thought it would >> improve performance, but the systems then became painfully slow to use. >> >> I ran some tests on hard disc performance on a newly installed Win7 32 >> bit system before and after installing the PV drivers from univention.de >> (version 0.11.0.373) as the other sites appear to be offline. The host >> machine is running Fedora 21 with kernel 3.19.3. >> Without the PV drivers (with QEMU hardware) hard disc performance was >> 4409 I/O per second and 9.03Mbps. >> With the PV drivers installed this dropped to 207 I/O per second and >> 0.43Mbps. >> >> Without the PV drivers, the remote desktop screen would refresh almost >> instantly, but with the PV drivers it could take up to 10 seconds just >> to refresh the screen. >> >> I don't understand this, as I though that the sole purpose of the PV >> drivers was to improve I/O performance, > Your expectation here is correct. > >> yet they have made the system so >> slow that it is virtually unusable. >> >> Am I doing something wrong here? > It seems unlikely, I don't think there is much you can have done wrong, > it's supposed to just work ;-) more likely some sort of bad interaction > between some (possibly buggy) component and another. > > I don't know much about the Windows PV drivers, so hopefully someone else > can chip in with some tips/knowledge. > > Seeing your guest cfg file and any relevant logs from /var/log/xen might > have some sort of clue. > > Ian. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------080608020509070909010404 Content-Type: text/plain; charset=windows-1252; name="qemu-dm-clientw3.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-dm-clientw3.log" domid: 64 Using file /dev/array1/clientw3_root in read-write mode Strip off blktap sub-type prefix to /root/Win732.iso (drv 'aio') Using file /root/Win732.iso in read-only mode Watching /local/domain/0/device-model/64/logdirty/cmd Watching /local/domain/0/device-model/64/command Watching /local/domain/64/cpu char device redirected to /dev/pts/10 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 990b1100-3f5b-4ec6-b030-624f34384fb4 populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/64/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/990b1100-3f5b-4ec6-b030-624f34384fb4/vncpasswd. medium change watch on `hdc' (index: 1): aio:/root/Win732.iso I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. [xenstore_process_vcpu_set_event]: /local/domain/64/cpu has no CPU! I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/64/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/64/log-throttling' medium change watch on `/local/domain/64/log-throttling' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. Unknown PV product 2 loaded in guest PV driver build 1 region type 1 at [c100,c200). region type 0 at [f3001000,f3001100). squash iomem [f3001000, f3001100). ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. --------------080608020509070909010404 Content-Type: text/xml; name="clientw3.dump.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clientw3.dump.xml" clientw3 990b1100-3f5b-4ec6-b030-624f34384fb4 2097152 2097152 4 hvm /usr/lib/xen/boot/hvmloader destroy restart restart
--------------080608020509070909010404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------080608020509070909010404-- From xen-users-bounces@lists.xen.org Sat Jul 25 11:05:36 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 11:05:36 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIxFk-00026x-S9; Sat, 25 Jul 2015 11:04:28 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIvPM-0000VB-J3 for xen-users@lists.xen.org; Sat, 25 Jul 2015 09:06:17 +0000 Received: from [85.158.139.211] by server-4.bemta-5.messagelabs.com id 0E/50-20308-78153B55; Sat, 25 Jul 2015 09:06:15 +0000 X-Env-Sender: graham@crowie.net X-Msg-Ref: server-15.tower-206.messagelabs.com!1437815160!7836017!1 X-Originating-IP: [115.70.75.133] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6902 invoked from network); 25 Jul 2015 09:06:04 -0000 Received: from 133.75.70.115.static.exetel.com.au (HELO ext.crowie.net) (115.70.75.133) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 25 Jul 2015 09:06:04 -0000 Received: from [192.168.131.55] (studyL.crowie.net [192.168.131.55]) by ext.crowie.net (8.14.7/8.14.7) with ESMTP id t6P95iD5014367; Sat, 25 Jul 2015 19:05:46 +1000 Message-ID: <55B3515F.20304@crowie.net> Date: Sat, 25 Jul 2015 19:05:35 +1000 From: Graham Crowe User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Campbell , gcxenlist@crowie.net, Alan Lam , "xen-users@lists.xen.org" References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> In-Reply-To: <1437744928.24746.96.camel@citrix.com> Content-Type: multipart/mixed; boundary="------------080608020509070909010404" X-Mailman-Approved-At: Sat, 25 Jul 2015 11:04:27 +0000 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org This is a multi-part message in MIME format. --------------080608020509070909010404 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit My config and qemu logs are attached. There is one rather telling line in the qemu log... "Unknown PV product 2 loaded in guest" I suspect it may be because I am using an old version of the PV drivers (the most recent sites are offline, so I used an older one) Is anyone able to point me to the latest PV drivers to try (WinXP, Win7 32 bit and Win7 64 bit)? As for the suggestion that I roll back to a snapshot. This is basically a fresh Windows install (I am just only starting a trial of Windows VMs - I already have a number of Linux VMs) so a snapshot won't help me much. Thanks On 24/07/2015 11:35 PM, Ian Campbell wrote: > On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: >> I installed the PV drivers in some windows PVs as I thought it would >> improve performance, but the systems then became painfully slow to use. >> >> I ran some tests on hard disc performance on a newly installed Win7 32 >> bit system before and after installing the PV drivers from univention.de >> (version 0.11.0.373) as the other sites appear to be offline. The host >> machine is running Fedora 21 with kernel 3.19.3. >> Without the PV drivers (with QEMU hardware) hard disc performance was >> 4409 I/O per second and 9.03Mbps. >> With the PV drivers installed this dropped to 207 I/O per second and >> 0.43Mbps. >> >> Without the PV drivers, the remote desktop screen would refresh almost >> instantly, but with the PV drivers it could take up to 10 seconds just >> to refresh the screen. >> >> I don't understand this, as I though that the sole purpose of the PV >> drivers was to improve I/O performance, > Your expectation here is correct. > >> yet they have made the system so >> slow that it is virtually unusable. >> >> Am I doing something wrong here? > It seems unlikely, I don't think there is much you can have done wrong, > it's supposed to just work ;-) more likely some sort of bad interaction > between some (possibly buggy) component and another. > > I don't know much about the Windows PV drivers, so hopefully someone else > can chip in with some tips/knowledge. > > Seeing your guest cfg file and any relevant logs from /var/log/xen might > have some sort of clue. > > Ian. > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users --------------080608020509070909010404 Content-Type: text/plain; charset=windows-1252; name="qemu-dm-clientw3.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="qemu-dm-clientw3.log" domid: 64 Using file /dev/array1/clientw3_root in read-write mode Strip off blktap sub-type prefix to /root/Win732.iso (drv 'aio') Using file /root/Win732.iso in read-only mode Watching /local/domain/0/device-model/64/logdirty/cmd Watching /local/domain/0/device-model/64/command Watching /local/domain/64/cpu char device redirected to /dev/pts/10 qemu_map_cache_init nr_buckets = 10000 size 4194304 shared page at pfn feffd buffered io page at pfn feffb Guest uuid = 990b1100-3f5b-4ec6-b030-624f34384fb4 populating video RAM at ff000000 mapping video RAM from ff000000 Register xen platform. Done register platform. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. xs_read(/local/domain/0/device-model/64/xen_extended_power_mgmt): read error xs_read(): vncpasswd get error. /vm/990b1100-3f5b-4ec6-b030-624f34384fb4/vncpasswd. medium change watch on `hdc' (index: 1): aio:/root/Win732.iso I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 Log-dirty: no command yet. I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 vcpu-set: watch node error. [xenstore_process_vcpu_set_event]: /local/domain/64/cpu has no CPU! I/O request not ready: 0, ptr: 0, port: 0, data: 0, count: 0, size: 0 xs_read(/local/domain/64/log-throttling): read error qemu: ignoring not-understood drive `/local/domain/64/log-throttling' medium change watch on `/local/domain/64/log-throttling' - unknown device, ignored cirrus vga map change while on lfb mode mapping vram to f0000000 - f0400000 platform_fixed_ioport: changed ro/rw state of ROM memory area. now is rw state. platform_fixed_ioport: changed ro/rw state of ROM memory area. now is ro state. Unknown PV product 2 loaded in guest PV driver build 1 region type 1 at [c100,c200). region type 0 at [f3001000,f3001100). squash iomem [f3001000, f3001100). ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x10. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x11. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x12. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x13. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x14. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x15. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x16. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x17. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x18. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x19. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x1f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x20. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x21. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x22. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x23. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x24. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x25. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x26. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x27. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x28. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x29. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x2f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x30. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x31. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x32. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x33. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x34. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x35. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x36. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x37. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x38. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x39. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x3f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x40. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x41. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x42. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x43. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x44. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x45. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x46. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x47. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x48. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x49. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x4f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x50. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x51. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x52. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x53. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x54. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x55. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x56. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x57. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x58. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x59. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x5f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x60. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x61. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x62. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x63. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x64. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x65. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x66. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x67. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x68. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x69. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x6f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x70. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x71. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x72. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x73. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x74. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x75. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x76. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x77. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x78. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x79. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x7f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x80. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x81. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x82. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x83. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x84. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x85. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x86. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x87. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x88. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x89. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x8f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x90. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x91. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x92. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x93. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x94. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x95. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x96. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x97. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x98. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x99. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9a. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9b. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9c. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9d. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9e. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0x9f. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xa9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xab. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xac. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xad. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xae. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xaf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xb9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xba. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xbf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xc9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xca. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xce. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xcf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xd9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xda. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xde. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xdf. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xe9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xea. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xeb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xec. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xed. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xee. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xef. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf0. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf1. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf2. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf3. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf4. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf5. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf6. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf7. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf8. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xf9. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfa. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfb. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfc. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfd. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xfe. ACPI:debug: write addr=0xb045, val=0x89. ACPI:debug: write addr=0xb044, val=0xff. ACPI:debug: write addr=0xb045, val=0x89. --------------080608020509070909010404 Content-Type: text/xml; name="clientw3.dump.xml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="clientw3.dump.xml" clientw3 990b1100-3f5b-4ec6-b030-624f34384fb4 2097152 2097152 4 hvm /usr/lib/xen/boot/hvmloader destroy restart restart
--------------080608020509070909010404 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------080608020509070909010404-- From xen-users-bounces@lists.xen.org Mon Jul 27 10:47:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 10:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJfvD-0000Vw-ST; Mon, 27 Jul 2015 10:46:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJfvC-0000Vp-8C for xen-users@lists.xen.org; Mon, 27 Jul 2015 10:46:14 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id E5/24-30658-5FB06B55; Mon, 27 Jul 2015 10:46:13 +0000 X-Env-Sender: prvs=643792544=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1437993971!35527345!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5977 invoked from network); 27 Jul 2015 10:46:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Jul 2015 10:46:12 -0000 X-IronPort-AV: E=Sophos;i="5.15,553,1432598400"; d="scan'208";a="284648076" Message-ID: <1437993940.6230.18.camel@citrix.com> From: Ian Campbell To: Graham Crowe , , Alan Lam , "xen-users@lists.xen.org" Date: Mon, 27 Jul 2015 11:45:40 +0100 In-Reply-To: <55B3515F.20304@crowie.net> References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> <55B3515F.20304@crowie.net> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I think the unknown product warning is benign. It is part of the unplug protocol which removes the non-PV devices after boot, in the bit which allows us to blacklist known bad versions, but a) we've never actually had to do that and b) it won't blacklist an unknown set of drivers. The "ACPI:debug:" messages are interesting, since there are lots, but unless they are continuing to appear once the system is up and running I'm inclined to suggest they are not the issue. I don't know too much enough about the libvirt XML configuration format, but nothing is jumping out at me. With the GPL PV drivers apparently still being offline perhaps the alternative ones which came out of the xenserver project but are now part of xenproject are worth trying?See http://www.xenproject.org/developers/teams/windows-pv-drivers.html ? Ian. On Sat, 2015-07-25 at 19:05 +1000, Graham Crowe wrote: > My config and qemu logs are attached. There is one rather telling line > in the qemu log... > "Unknown PV product 2 loaded in guest" > > I suspect it may be because I am using an old version of the PV drivers > (the most recent sites are offline, so I used an older one) > > Is anyone able to point me to the latest PV drivers to try (WinXP, Win7 > 32 bit and Win7 64 bit)? > > As for the suggestion that I roll back to a snapshot. This is basically > a fresh Windows install (I am just only starting a trial of Windows VMs > - I already have a number of Linux VMs) so a snapshot won't help me much. > > Thanks > > > > On 24/07/2015 11:35 PM, Ian Campbell wrote: > > On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: > > > I installed the PV drivers in some windows PVs as I thought it would > > > improve performance, but the systems then became painfully slow to > > > use. > > > > > > I ran some tests on hard disc performance on a newly installed Win7 > > > 32 > > > bit system before and after installing the PV drivers from > > > univention.de > > > (version 0.11.0.373) as the other sites appear to be offline. The > > > host > > > machine is running Fedora 21 with kernel 3.19.3. > > > Without the PV drivers (with QEMU hardware) hard disc performance was > > > 4409 I/O per second and 9.03Mbps. > > > With the PV drivers installed this dropped to 207 I/O per second and > > > 0.43Mbps. > > > > > > Without the PV drivers, the remote desktop screen would refresh > > > almost > > > instantly, but with the PV drivers it could take up to 10 seconds > > > just > > > to refresh the screen. > > > > > > I don't understand this, as I though that the sole purpose of the PV > > > drivers was to improve I/O performance, > > Your expectation here is correct. > > > > > yet they have made the system so > > > slow that it is virtually unusable. > > > > > > Am I doing something wrong here? > > It seems unlikely, I don't think there is much you can have done wrong, > > it's supposed to just work ;-) more likely some sort of bad interaction > > between some (possibly buggy) component and another. > > > > I don't know much about the Windows PV drivers, so hopefully someone > > else > > can chip in with some tips/knowledge. > > > > Seeing your guest cfg file and any relevant logs from /var/log/xen > > might > > have some sort of clue. > > > > Ian. > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 10:47:19 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 10:47:19 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJfvD-0000Vw-ST; Mon, 27 Jul 2015 10:46:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJfvC-0000Vp-8C for xen-users@lists.xen.org; Mon, 27 Jul 2015 10:46:14 +0000 Received: from [193.109.254.147] by server-11.bemta-14.messagelabs.com id E5/24-30658-5FB06B55; Mon, 27 Jul 2015 10:46:13 +0000 X-Env-Sender: prvs=643792544=Ian.Campbell@citrix.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1437993971!35527345!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5977 invoked from network); 27 Jul 2015 10:46:12 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-15.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 27 Jul 2015 10:46:12 -0000 X-IronPort-AV: E=Sophos;i="5.15,553,1432598400"; d="scan'208";a="284648076" Message-ID: <1437993940.6230.18.camel@citrix.com> From: Ian Campbell To: Graham Crowe , , Alan Lam , "xen-users@lists.xen.org" Date: Mon, 27 Jul 2015 11:45:40 +0100 In-Reply-To: <55B3515F.20304@crowie.net> References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> <55B3515F.20304@crowie.net> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I think the unknown product warning is benign. It is part of the unplug protocol which removes the non-PV devices after boot, in the bit which allows us to blacklist known bad versions, but a) we've never actually had to do that and b) it won't blacklist an unknown set of drivers. The "ACPI:debug:" messages are interesting, since there are lots, but unless they are continuing to appear once the system is up and running I'm inclined to suggest they are not the issue. I don't know too much enough about the libvirt XML configuration format, but nothing is jumping out at me. With the GPL PV drivers apparently still being offline perhaps the alternative ones which came out of the xenserver project but are now part of xenproject are worth trying?See http://www.xenproject.org/developers/teams/windows-pv-drivers.html ? Ian. On Sat, 2015-07-25 at 19:05 +1000, Graham Crowe wrote: > My config and qemu logs are attached. There is one rather telling line > in the qemu log... > "Unknown PV product 2 loaded in guest" > > I suspect it may be because I am using an old version of the PV drivers > (the most recent sites are offline, so I used an older one) > > Is anyone able to point me to the latest PV drivers to try (WinXP, Win7 > 32 bit and Win7 64 bit)? > > As for the suggestion that I roll back to a snapshot. This is basically > a fresh Windows install (I am just only starting a trial of Windows VMs > - I already have a number of Linux VMs) so a snapshot won't help me much. > > Thanks > > > > On 24/07/2015 11:35 PM, Ian Campbell wrote: > > On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: > > > I installed the PV drivers in some windows PVs as I thought it would > > > improve performance, but the systems then became painfully slow to > > > use. > > > > > > I ran some tests on hard disc performance on a newly installed Win7 > > > 32 > > > bit system before and after installing the PV drivers from > > > univention.de > > > (version 0.11.0.373) as the other sites appear to be offline. The > > > host > > > machine is running Fedora 21 with kernel 3.19.3. > > > Without the PV drivers (with QEMU hardware) hard disc performance was > > > 4409 I/O per second and 9.03Mbps. > > > With the PV drivers installed this dropped to 207 I/O per second and > > > 0.43Mbps. > > > > > > Without the PV drivers, the remote desktop screen would refresh > > > almost > > > instantly, but with the PV drivers it could take up to 10 seconds > > > just > > > to refresh the screen. > > > > > > I don't understand this, as I though that the sole purpose of the PV > > > drivers was to improve I/O performance, > > Your expectation here is correct. > > > > > yet they have made the system so > > > slow that it is virtually unusable. > > > > > > Am I doing something wrong here? > > It seems unlikely, I don't think there is much you can have done wrong, > > it's supposed to just work ;-) more likely some sort of bad interaction > > between some (possibly buggy) component and another. > > > > I don't know much about the Windows PV drivers, so hopefully someone > > else > > can chip in with some tips/knowledge. > > > > Seeing your guest cfg file and any relevant logs from /var/log/xen > > might > > have some sort of clue. > > > > Ian. > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 11:47:42 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 11:47:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJgrb-0008Dm-3l; Mon, 27 Jul 2015 11:46:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJgrZ-0008Ba-IN for xen-users@lists.xen.org; Mon, 27 Jul 2015 11:46:33 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 7E/CF-14422-81A16B55; Mon, 27 Jul 2015 11:46:32 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1437997591!23854475!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1016 invoked from network); 27 Jul 2015 11:46:32 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-6.tower-206.messagelabs.com with SMTP; 27 Jul 2015 11:46:32 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id B240924526B; Mon, 27 Jul 2015 13:46:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7kUbp0IcLtR; Mon, 27 Jul 2015 13:46:28 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 5AD2924514C; Mon, 27 Jul 2015 13:46:28 +0200 (CEST) To: pietrop , xen-users@lists.xen.org References: <1434722648.6996.37.camel@aol.com> From: Wolf Grossi Message-ID: <55B61A12.4080200@magro-soft.com> Date: Mon, 27 Jul 2015 13:46:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1434722648.6996.37.camel@aol.com> Subject: Re: [Xen-users] USB Passthrough XEN 4.4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 19.06.2015 16:04, pietrop wrote: > Hi all, > > I am running XEN 4.4 and I am using the tool 'xl' to do all the needed > common operations like start/stop/reboot virtual machines; I'd need to > setup an USB passthrough and I am reading the related instructions from > the page : > > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough > > Following the chapter 'Host USB in xl' it looks like the only support > available is 'emulated USB', which as stated earlier in the same page is > available only for HVM guest, I am pretty sure I am running a PV guest. > > Does that mean I can't configure USB passthrough on my system ? > > I have given those instructions a go but I can't see any USB > devices/controller on my guest system. > > Instead I get an unable to initialize libusb: -99 > > am I obliged to go for a PCI passthrough ? > > Thanks, > Pietro > > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > Pietro, I'm in the same situation; have you found a solution already or is the PCI-passthru the only option? Cheers, Wolf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 11:47:42 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 11:47:42 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJgrb-0008Dm-3l; Mon, 27 Jul 2015 11:46:35 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJgrZ-0008Ba-IN for xen-users@lists.xen.org; Mon, 27 Jul 2015 11:46:33 +0000 Received: from [85.158.139.211] by server-16.bemta-5.messagelabs.com id 7E/CF-14422-81A16B55; Mon, 27 Jul 2015 11:46:32 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1437997591!23854475!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1016 invoked from network); 27 Jul 2015 11:46:32 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-6.tower-206.messagelabs.com with SMTP; 27 Jul 2015 11:46:32 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id B240924526B; Mon, 27 Jul 2015 13:46:30 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7kUbp0IcLtR; Mon, 27 Jul 2015 13:46:28 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 5AD2924514C; Mon, 27 Jul 2015 13:46:28 +0200 (CEST) To: pietrop , xen-users@lists.xen.org References: <1434722648.6996.37.camel@aol.com> From: Wolf Grossi Message-ID: <55B61A12.4080200@magro-soft.com> Date: Mon, 27 Jul 2015 13:46:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1434722648.6996.37.camel@aol.com> Subject: Re: [Xen-users] USB Passthrough XEN 4.4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 19.06.2015 16:04, pietrop wrote: > Hi all, > > I am running XEN 4.4 and I am using the tool 'xl' to do all the needed > common operations like start/stop/reboot virtual machines; I'd need to > setup an USB passthrough and I am reading the related instructions from > the page : > > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough > > Following the chapter 'Host USB in xl' it looks like the only support > available is 'emulated USB', which as stated earlier in the same page is > available only for HVM guest, I am pretty sure I am running a PV guest. > > Does that mean I can't configure USB passthrough on my system ? > > I have given those instructions a go but I can't see any USB > devices/controller on my guest system. > > Instead I get an unable to initialize libusb: -99 > > am I obliged to go for a PCI passthrough ? > > Thanks, > Pietro > > > > > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > Pietro, I'm in the same situation; have you found a solution already or is the PCI-passthru the only option? Cheers, Wolf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 12:04:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 12:04:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7n-0000ys-0W; Mon, 27 Jul 2015 12:03:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7l-0000yQ-06; Mon, 27 Jul 2015 12:03:17 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id DA/07-27764-40E16B55; Mon, 27 Jul 2015 12:03:16 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1437998593!27957156!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9637 invoked from network); 27 Jul 2015 12:03:14 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 27 Jul 2015 12:03:14 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7b-0001MM-5u; Mon, 27 Jul 2015 12:03:07 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1ZJh7a-0007Mm-P4; Mon, 27 Jul 2015 12:03:07 +0000 Date: Mon, 27 Jul 2015 12:03:06 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 138 (CVE-2015-5154) - QEMU heap overflow flaw while processing certain ATAPI commands. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-5154 / XSA-138 version 2 QEMU heap overflow flaw while processing certain ATAPI commands. UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The QEMU security team has predisclosed the following advisory: A heap overflow flaw was found in the way QEMU's IDE subsystem handled I/O buffer access while processing certain ATAPI commands. A privileged guest user in a guest with CDROM drive enabled could potentially use this flaw to execute arbitrary code on the host with the privileges of the host's QEMU process corresponding to the guest. IMPACT ====== An HVM guest which has access to an emulated IDE CDROM device (e.g. with a device with "devtype=cdrom", or the "cdrom" convenience alias, in the VBD configuration) can exploit this vulnerability to take over the qemu process elevating its privilege to that of the qemu process. VULNERABLE SYSTEMS ================== All Xen systems running x86 HVM guests without stubdomains which have been configured with an emulated CD-ROM driver model are vulnerable. Systems using qemu-dm stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Both the traditional ("qemu-xen-traditional") or upstream-based ("qemu-xen") qemu device models are potentially vulnerable. Systems running only PV guests are NOT vulnerable. ARM systems are NOT vulnerable. MITIGATION ========== Avoiding the use of emulated CD-ROM devices altogether, by not specifying such devices in the domain configuration, will avoid this issue. Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. qemu-dm stubdomains are only available with "qemu-xen-traditional". CREDITS ======= This issue was discovered by Kevin Wolf of Red Hat. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa138-qemut-{1,2}.patch qemu-xen-traditional, Xen unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa138-qemuu-{1,2,3}.patch qemu-upstream, xen unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x xsa138-qemuu-{1,3}.patch qemu-upstream, Xen 4.2.x NOTE: xsa138-qemuu-2.patch is not required for Xen 4.2.x. $ sha256sum xsa138*.patch 7e385455379d88658b8ab0d4c1effffe9af21fff2e1dc0fe51cacc779afc83a4 xsa138-qemut-1.patch c9a89082e36a0646a6fe002c6892d966d415d11ad5cfdcfea7e9c8d7a3f1316c xsa138-qemut-2.patch a076808f543c82aeac2f0239a4a46d9baadcd4e4b0a2f9ae7ded99cf59cffde6 xsa138-qemuu-1.patch ed16dca7d2c179d0931d6e2503264d6593547a803eb3f08f6db7fff2127509a9 xsa138-qemuu-2.patch 090bdec00ede1f0ace1af52833038a74971e060d0c176b42bfca08511d36c644 xsa138-qemuu-3.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except on systems used and administered only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVth2LAAoJEIP+FMlX6CvZcd4IAJYWZrj86FDn9L5SqeTq8cLX 6tnptNaQb+uDQ/thV2R+nUVdJNaJt1UIhRhO2tD2g0dEqj/I7Vx/Hh95ncPCQ3fS ec7ph9lcsdAy8E+7abNlhJnPsOVOazEwI0we2deKjdn3CqyfVXqA47rSDY4VChtc kTV7lEIEebBlo1igz05/poUEhjkCP8UvSfpgpQY60N2y+C0OyIXPIog4q2LiEbeO cq/deACYN3jOVwPTozkQNAAOq0++UfnGfDredOIYCbvqA5OtMf1DGlWyTQLIEuKJ zCiatGudJI2klVYkHSVYfXr54WjreiRCOfLB9ilhBW7Yr2juWFQIAc+0Kf09uFo= =I0Tz -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa138-qemut-1.patch" Content-Disposition: attachment; filename="xsa138-qemut-1.patch" Content-Transfer-Encoding: base64 RnJvbSA1MTA5NTJkNGMzM2VlNjk1NzQxNjdjZTMwODI5YjIxYzgxNWExNjVi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTM6 MzEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEvMl0gaWRlOiBDaGVjayBhcnJh eSBib3VuZHMgYmVmb3JlIHdyaXRpbmcgdG8gaW9fYnVmZmVyCiAoQ1ZFLTIw MTUtNTE1NCkKCklmIHRoZSBlbmRfdHJhbnNmZXJfZnVuYyBvZiBhIGNvbW1h bmQgaXMgY2FsbGVkIGJlY2F1c2UgZW5vdWdoIGRhdGEgaGFzCmJlZW4gcmVh ZCBvciB3cml0dGVuIGZvciB0aGUgY3VycmVudCBQSU8gdHJhbnNmZXIsIGFu ZCBpdCBmYWlscyB0bwpjb3JyZWN0bHkgY2FsbCB0aGUgY29tbWFuZCBjb21w bGV0aW9uIGZ1bmN0aW9ucywgdGhlIERSUSBiaXQgaW4gdGhlCnN0YXR1cyBy ZWdpc3RlciBhbmQgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMgbWF5IHJlbWFpbiBz ZXQuIFRoaXMgYWxsb3dzIHRoZQpndWVzdCB0byBhY2Nlc3MgZnVydGhlciBi eXRlcyBpbiBzLT5pb19idWZmZXIgYmV5b25kIHMtPmRhdGFfZW5kLCBhbmQK ZXZlbnR1YWxseSBvdmVyZmxvd2luZyB0aGUgaW9fYnVmZmVyLgoKT25lIGNh c2Ugd2hlcmUgdGhpcyBjdXJyZW50bHkgaGFwcGVucyBpcyBlbXVsYXRpb24g b2YgdGhlIEFUQVBJIGNvbW1hbmQKU1RBUlQgU1RPUCBVTklULgoKVGhpcyBw YXRjaCBmaXhlcyB0aGUgcHJvYmxlbSBieSBhZGRpbmcgZXhwbGljaXQgYXJy YXkgYm91bmRzIGNoZWNrcwpiZWZvcmUgYWNjZXNzaW5nIHRoZSBidWZmZXIg aW5zdGVhZCBvZiByZWx5aW5nIG9uIGVuZF90cmFuc2Zlcl9mdW5jIHRvCmZ1 bmN0aW9uIGNvcnJlY3RseS4KCkNjOiBxZW11LXN0YWJsZUBub25nbnUub3Jn ClNpZ25lZC1vZmYtYnk6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+ Ci0tLQogaHcvaWRlLmMgfCAxNiArKysrKysrKysrKysrKysrCiAxIGZpbGUg Y2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2h3L2lk ZS5jIGIvaHcvaWRlLmMKaW5kZXggNzkxNjY2Yi4uMjExZWM4OCAxMDA2NDQK LS0tIGEvaHcvaWRlLmMKKysrIGIvaHcvaWRlLmMKQEAgLTMwMDIsNiArMzAw MiwxMCBAQCBzdGF0aWMgdm9pZCBpZGVfZGF0YV93cml0ZXcodm9pZCAqb3Bh cXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCiAgICAgYnVmZmVy ZWRfcGlvX3dyaXRlKHMsIGFkZHIsIDIpOwogCiAgICAgcCA9IHMtPmRhdGFf cHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAgICAg IHJldHVybjsKKyAgICB9CisKICAgICAqKHVpbnQxNl90ICopcCA9IGxlMTZf dG9fY3B1KHZhbCk7CiAgICAgcCArPSAyOwogICAgIHMtPmRhdGFfcHRyID0g cDsKQEAgLTMwMjEsNiArMzAyNSwxMCBAQCBzdGF0aWMgdWludDMyX3QgaWRl X2RhdGFfcmVhZHcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQogICAg IGJ1ZmZlcmVkX3Bpb19yZWFkKHMsIGFkZHIsIDIpOwogCiAgICAgcCA9IHMt PmRhdGFfcHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7Cisg ICAgICAgIHJldHVybiAwOworICAgIH0KKwogICAgIHJldCA9IGNwdV90b19s ZTE2KCoodWludDE2X3QgKilwKTsKICAgICBwICs9IDI7CiAgICAgcy0+ZGF0 YV9wdHIgPSBwOwpAQCAtMzA0MCw2ICszMDQ4LDEwIEBAIHN0YXRpYyB2b2lk IGlkZV9kYXRhX3dyaXRlbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90IGFkZHIs IHVpbnQzMl90IHZhbCkKICAgICBidWZmZXJlZF9waW9fd3JpdGUocywgYWRk ciwgNCk7CiAKICAgICBwID0gcy0+ZGF0YV9wdHI7CisgICAgaWYgKHAgKyA0 ID4gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwog ICAgICoodWludDMyX3QgKilwID0gbGUzMl90b19jcHUodmFsKTsKICAgICBw ICs9IDQ7CiAgICAgcy0+ZGF0YV9wdHIgPSBwOwpAQCAtMzA1OSw2ICszMDcx LDEwIEBAIHN0YXRpYyB1aW50MzJfdCBpZGVfZGF0YV9yZWFkbCh2b2lkICpv cGFxdWUsIHVpbnQzMl90IGFkZHIpCiAgICAgYnVmZmVyZWRfcGlvX3JlYWQo cywgYWRkciwgNCk7CiAKICAgICBwID0gcy0+ZGF0YV9wdHI7CisgICAgaWYg KHAgKyA0ID4gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcmV0dXJuIDA7Cisg ICAgfQorCiAgICAgcmV0ID0gY3B1X3RvX2xlMzIoKih1aW50MzJfdCAqKXAp OwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0tIAoyLjEu NAoK --=separator Content-Type: application/octet-stream; name="xsa138-qemut-2.patch" Content-Disposition: attachment; filename="xsa138-qemut-2.patch" Content-Transfer-Encoding: base64 RnJvbSAxYWMwZjYwZDU1OGI3ZmNhNTVjNjlhNjFhYjRjNDUzOGFmMWYwMmY5 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6NDE6 MjcgKzAyMDAKU3ViamVjdDogW1BBVENIIDIvMl0gaWRlOiBDbGVhciBEUlEg YWZ0ZXIgaGFuZGxpbmcgYWxsIGV4cGVjdGVkIGFjY2Vzc2VzCgpUaGlzIGlz IGFkZGl0aW9uYWwgaGFyZGVuaW5nIGFnYWluc3QgYW4gZW5kX3RyYW5zZmVy X2Z1bmMgdGhhdCBmYWlscyB0bwpjbGVhciB0aGUgRFJRIHN0YXR1cyBiaXQu IFRoZSBiaXQgbXVzdCBiZSB1bnNldCBhcyBzb29uIGFzIHRoZSBQSU8KdHJh bnNmZXIgaGFzIGNvbXBsZXRlZCwgc28gaXQncyBiZXR0ZXIgdG8gZG8gdGhp cyBpbiBhIGNlbnRyYWwgcGxhY2UKaW5zdGVhZCBvZiBkdXBsaWNhdGluZyB0 aGUgY29kZSBpbiBhbGwgY29tbWFuZHMgKGFuZCBmb3JnZXR0aW5nIGl0IGlu CnNvbWUpLgoKU2lnbmVkLW9mZi1ieTogS2V2aW4gV29sZiA8a3dvbGZAcmVk aGF0LmNvbT4KLS0tCiBody9pZGUuYyB8IDE2ICsrKysrKysrKysrKy0tLS0K IDEgZmlsZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL2h3L2lkZS5jIGIvaHcvaWRlLmMKaW5kZXgg MjExZWM4OC4uN2I4NGQxYiAxMDA2NDQKLS0tIGEvaHcvaWRlLmMKKysrIGIv aHcvaWRlLmMKQEAgLTMwMDksOCArMzAwOSwxMCBAQCBzdGF0aWMgdm9pZCBp ZGVfZGF0YV93cml0ZXcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1 aW50MzJfdCB2YWwpCiAgICAgKih1aW50MTZfdCAqKXAgPSBsZTE2X3RvX2Nw dSh2YWwpOwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0g ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0 YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAg ICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogfQogCiBz dGF0aWMgdWludDMyX3QgaWRlX2RhdGFfcmVhZHcodm9pZCAqb3BhcXVlLCB1 aW50MzJfdCBhZGRyKQpAQCAtMzAzMiw4ICszMDM0LDEwIEBAIHN0YXRpYyB1 aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpvcGFxdWUsIHVpbnQzMl90 IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMTYoKih1aW50MTZfdCAqKXAp OwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYg KHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQp IHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAgICAg cy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVybiBy ZXQ7CiB9CiAKQEAgLTMwNTUsOCArMzA1OSwxMCBAQCBzdGF0aWMgdm9pZCBp ZGVfZGF0YV93cml0ZWwodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1 aW50MzJfdCB2YWwpCiAgICAgKih1aW50MzJfdCAqKXAgPSBsZTMyX3RvX2Nw dSh2YWwpOwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0g ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0 YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAg ICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogfQogCiBz dGF0aWMgdWludDMyX3QgaWRlX2RhdGFfcmVhZGwodm9pZCAqb3BhcXVlLCB1 aW50MzJfdCBhZGRyKQpAQCAtMzA3OCw4ICszMDg0LDEwIEBAIHN0YXRpYyB1 aW50MzJfdCBpZGVfZGF0YV9yZWFkbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90 IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMzIoKih1aW50MzJfdCAqKXAp OwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYg KHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQp IHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAgICAg cy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVybiBy ZXQ7CiB9CiAKLS0gCjIuMS40Cgo= --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-1.patch" Content-Disposition: attachment; filename="xsa138-qemuu-1.patch" Content-Transfer-Encoding: base64 RnJvbSBhOWRlMTQxNzU1NDhjMDRlMGY4YmU3ZmFlMjE5MjQ2NTA5YmE0NmE5 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTM6 MzEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEvM10gaWRlOiBDaGVjayBhcnJh eSBib3VuZHMgYmVmb3JlIHdyaXRpbmcgdG8gaW9fYnVmZmVyCiAoQ1ZFLTIw MTUtNTE1NCkKCklmIHRoZSBlbmRfdHJhbnNmZXJfZnVuYyBvZiBhIGNvbW1h bmQgaXMgY2FsbGVkIGJlY2F1c2UgZW5vdWdoIGRhdGEgaGFzCmJlZW4gcmVh ZCBvciB3cml0dGVuIGZvciB0aGUgY3VycmVudCBQSU8gdHJhbnNmZXIsIGFu ZCBpdCBmYWlscyB0bwpjb3JyZWN0bHkgY2FsbCB0aGUgY29tbWFuZCBjb21w bGV0aW9uIGZ1bmN0aW9ucywgdGhlIERSUSBiaXQgaW4gdGhlCnN0YXR1cyBy ZWdpc3RlciBhbmQgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMgbWF5IHJlbWFpbiBz ZXQuIFRoaXMgYWxsb3dzIHRoZQpndWVzdCB0byBhY2Nlc3MgZnVydGhlciBi eXRlcyBpbiBzLT5pb19idWZmZXIgYmV5b25kIHMtPmRhdGFfZW5kLCBhbmQK ZXZlbnR1YWxseSBvdmVyZmxvd2luZyB0aGUgaW9fYnVmZmVyLgoKT25lIGNh c2Ugd2hlcmUgdGhpcyBjdXJyZW50bHkgaGFwcGVucyBpcyBlbXVsYXRpb24g b2YgdGhlIEFUQVBJIGNvbW1hbmQKU1RBUlQgU1RPUCBVTklULgoKVGhpcyBw YXRjaCBmaXhlcyB0aGUgcHJvYmxlbSBieSBhZGRpbmcgZXhwbGljaXQgYXJy YXkgYm91bmRzIGNoZWNrcwpiZWZvcmUgYWNjZXNzaW5nIHRoZSBidWZmZXIg aW5zdGVhZCBvZiByZWx5aW5nIG9uIGVuZF90cmFuc2Zlcl9mdW5jIHRvCmZ1 bmN0aW9uIGNvcnJlY3RseS4KCkNjOiBxZW11LXN0YWJsZUBub25nbnUub3Jn ClNpZ25lZC1vZmYtYnk6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+ Ci0tLQogaHcvaWRlL2NvcmUuYyB8IDE2ICsrKysrKysrKysrKysrKysKIDEg ZmlsZSBjaGFuZ2VkLCAxNiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEv aHcvaWRlL2NvcmUuYyBiL2h3L2lkZS9jb3JlLmMKaW5kZXggMTIyZTk1NS4u NDRmY2MyMyAxMDA2NDQKLS0tIGEvaHcvaWRlL2NvcmUuYworKysgYi9ody9p ZGUvY29yZS5jCkBAIC0yMDIxLDYgKzIwMjEsMTAgQEAgdm9pZCBpZGVfZGF0 YV93cml0ZXcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJf dCB2YWwpCiAgICAgfQogCiAgICAgcCA9IHMtPmRhdGFfcHRyOworICAgIGlm IChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAgICAgIHJldHVybjsKKyAg ICB9CisKICAgICAqKHVpbnQxNl90ICopcCA9IGxlMTZfdG9fY3B1KHZhbCk7 CiAgICAgcCArPSAyOwogICAgIHMtPmRhdGFfcHRyID0gcDsKQEAgLTIwNDIs NiArMjA0NiwxMCBAQCB1aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpv cGFxdWUsIHVpbnQzMl90IGFkZHIpCiAgICAgfQogCiAgICAgcCA9IHMtPmRh dGFfcHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAg ICAgIHJldHVybiAwOworICAgIH0KKwogICAgIHJldCA9IGNwdV90b19sZTE2 KCoodWludDE2X3QgKilwKTsKICAgICBwICs9IDI7CiAgICAgcy0+ZGF0YV9w dHIgPSBwOwpAQCAtMjA2Myw2ICsyMDcxLDEwIEBAIHZvaWQgaWRlX2RhdGFf d3JpdGVsKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMyX3Qg dmFsKQogICAgIH0KIAogICAgIHAgPSBzLT5kYXRhX3B0cjsKKyAgICBpZiAo cCArIDQgPiBzLT5kYXRhX2VuZCkgeworICAgICAgICByZXR1cm47CisgICAg fQorCiAgICAgKih1aW50MzJfdCAqKXAgPSBsZTMyX3RvX2NwdSh2YWwpOwog ICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7CkBAIC0yMDg0LDYg KzIwOTYsMTAgQEAgdWludDMyX3QgaWRlX2RhdGFfcmVhZGwodm9pZCAqb3Bh cXVlLCB1aW50MzJfdCBhZGRyKQogICAgIH0KIAogICAgIHAgPSBzLT5kYXRh X3B0cjsKKyAgICBpZiAocCArIDQgPiBzLT5kYXRhX2VuZCkgeworICAgICAg ICByZXR1cm4gMDsKKyAgICB9CisKICAgICByZXQgPSBjcHVfdG9fbGUzMigq KHVpbnQzMl90ICopcCk7CiAgICAgcCArPSA0OwogICAgIHMtPmRhdGFfcHRy ID0gcDsKLS0gCjEuOC4zLjEK --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-2.patch" Content-Disposition: attachment; filename="xsa138-qemuu-2.patch" Content-Transfer-Encoding: base64 RnJvbSBhYTg1MWQzMGFjZmJiOTU4MDA5OGFjMWRjODI4ODU1MzBjYjhiM2Mx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTc6 NDYgKzAyMDAKU3ViamVjdDogW1BBVENIIDIvM10gaWRlL2F0YXBpOiBGaXgg U1RBUlQgU1RPUCBVTklUIGNvbW1hbmQgY29tcGxldGlvbgoKVGhlIGNvbW1h bmQgbXVzdCBiZSBjb21wbGV0ZWQgb24gYWxsIGNvZGUgcGF0aHMuIFNUQVJU IFNUT1AgVU5JVCB3aXRoCnB3cmNuZCBzZXQgc2hvdWxkIHN1Y2NlZWQgd2l0 aG91dCBkb2luZyBhbnl0aGluZy4KClNpZ25lZC1vZmYtYnk6IEtldmluIFdv bGYgPGt3b2xmQHJlZGhhdC5jb20+Ci0tLQogaHcvaWRlL2F0YXBpLmMgfCAx ICsKIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKQoKZGlmZiAtLWdp dCBhL2h3L2lkZS9hdGFwaS5jIGIvaHcvaWRlL2F0YXBpLmMKaW5kZXggOTUw ZTMxMS4uNzlkZDE2NyAxMDA2NDQKLS0tIGEvaHcvaWRlL2F0YXBpLmMKKysr IGIvaHcvaWRlL2F0YXBpLmMKQEAgLTk4Myw2ICs5ODMsNyBAQCBzdGF0aWMg dm9pZCBjbWRfc3RhcnRfc3RvcF91bml0KElERVN0YXRlICpzLCB1aW50OF90 KiBidWYpCgogICAgIGlmIChwd3JjbmQpIHsKICAgICAgICAgLyogZWplY3Qv bG9hZCBvbmx5IGhhcHBlbnMgZm9yIHBvd2VyIGNvbmRpdGlvbiA9PSAwICov CisgICAgICAgIGlkZV9hdGFwaV9jbWRfb2socyk7CiAgICAgICAgIHJldHVy bjsKICAgICB9CgotLQoxLjguMy4xCgo= --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-3.patch" Content-Disposition: attachment; filename="xsa138-qemuu-3.patch" Content-Transfer-Encoding: base64 RnJvbSAxZDNjMjI2OGY4NzA4MTI2YTM0MDY0YzJlMGMxMDAwYjQwZTZmM2U1 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6NDE6 MjcgKzAyMDAKU3ViamVjdDogW1BBVENIIDMvM10gaWRlOiBDbGVhciBEUlEg YWZ0ZXIgaGFuZGxpbmcgYWxsIGV4cGVjdGVkIGFjY2Vzc2VzCgpUaGlzIGlz IGFkZGl0aW9uYWwgaGFyZGVuaW5nIGFnYWluc3QgYW4gZW5kX3RyYW5zZmVy X2Z1bmMgdGhhdCBmYWlscyB0bwpjbGVhciB0aGUgRFJRIHN0YXR1cyBiaXQu IFRoZSBiaXQgbXVzdCBiZSB1bnNldCBhcyBzb29uIGFzIHRoZSBQSU8KdHJh bnNmZXIgaGFzIGNvbXBsZXRlZCwgc28gaXQncyBiZXR0ZXIgdG8gZG8gdGhp cyBpbiBhIGNlbnRyYWwgcGxhY2UKaW5zdGVhZCBvZiBkdXBsaWNhdGluZyB0 aGUgY29kZSBpbiBhbGwgY29tbWFuZHMgKGFuZCBmb3JnZXR0aW5nIGl0IGlu CnNvbWUpLgoKU2lnbmVkLW9mZi1ieTogS2V2aW4gV29sZiA8a3dvbGZAcmVk aGF0LmNvbT4KLS0tCiBody9pZGUvY29yZS5jIHwgMTYgKysrKysrKysrKysr LS0tLQogMSBmaWxlIGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDQgZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcvaWRlL2NvcmUuYyBiL2h3L2lk ZS9jb3JlLmMKaW5kZXggNDRmY2MyMy4uNTA0NDljYSAxMDA2NDQKLS0tIGEv aHcvaWRlL2NvcmUuYworKysgYi9ody9pZGUvY29yZS5jCkBAIC0yMDI4LDgg KzIwMjgsMTAgQEAgdm9pZCBpZGVfZGF0YV93cml0ZXcodm9pZCAqb3BhcXVl LCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCiAgICAgKih1aW50MTZf dCAqKXAgPSBsZTE2X3RvX2NwdSh2YWwpOwogICAgIHAgKz0gMjsKICAgICBz LT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisg ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVz ICY9IH5EUlFfU1RBVDsKICAgICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMo cyk7CisgICAgfQogfQoKIHVpbnQzMl90IGlkZV9kYXRhX3JlYWR3KHZvaWQg Km9wYXF1ZSwgdWludDMyX3QgYWRkcikKQEAgLTIwNTMsOCArMjA1NSwxMCBA QCB1aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpvcGFxdWUsIHVpbnQz Ml90IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMTYoKih1aW50MTZfdCAq KXApOwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAg aWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9l bmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAg ICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVy biByZXQ7CiB9CgpAQCAtMjA3OCw4ICsyMDgyLDEwIEBAIHZvaWQgaWRlX2Rh dGFfd3JpdGVsKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMy X3QgdmFsKQogICAgICoodWludDMyX3QgKilwID0gbGUzMl90b19jcHUodmFs KTsKICAgICBwICs9IDQ7CiAgICAgcy0+ZGF0YV9wdHIgPSBwOwotICAgIGlm IChwID49IHMtPmRhdGFfZW5kKQorICAgIGlmIChwID49IHMtPmRhdGFfZW5k KSB7CisgICAgICAgIHMtPnN0YXR1cyAmPSB+RFJRX1NUQVQ7CiAgICAgICAg IHMtPmVuZF90cmFuc2Zlcl9mdW5jKHMpOworICAgIH0KIH0KCiB1aW50MzJf dCBpZGVfZGF0YV9yZWFkbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90IGFkZHIp CkBAIC0yMTAzLDggKzIxMDksMTAgQEAgdWludDMyX3QgaWRlX2RhdGFfcmVh ZGwodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQogICAgIHJldCA9IGNw dV90b19sZTMyKCoodWludDMyX3QgKilwKTsKICAgICBwICs9IDQ7CiAgICAg cy0+ZGF0YV9wdHIgPSBwOwotICAgIGlmIChwID49IHMtPmRhdGFfZW5kKQor ICAgIGlmIChwID49IHMtPmRhdGFfZW5kKSB7CisgICAgICAgIHMtPnN0YXR1 cyAmPSB+RFJRX1NUQVQ7CiAgICAgICAgIHMtPmVuZF90cmFuc2Zlcl9mdW5j KHMpOworICAgIH0KICAgICByZXR1cm4gcmV0OwogfQoKLS0KMS44LjMuMQoK --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Mon Jul 27 12:04:16 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 12:04:16 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7n-0000ys-0W; Mon, 27 Jul 2015 12:03:19 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7l-0000yQ-06; Mon, 27 Jul 2015 12:03:17 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id DA/07-27764-40E16B55; Mon, 27 Jul 2015 12:03:16 +0000 X-Env-Sender: iwj@xenbits.xen.org X-Msg-Ref: server-16.tower-27.messagelabs.com!1437998593!27957156!1 X-Originating-IP: [50.57.168.107] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9637 invoked from network); 27 Jul 2015 12:03:14 -0000 Received: from mail.xen.org (HELO mail.xen.org) (50.57.168.107) by server-16.tower-27.messagelabs.com with AES256-SHA encrypted SMTP; 27 Jul 2015 12:03:14 -0000 Received: from xenbits.xen.org ([50.57.170.242]) by mail.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJh7b-0001MM-5u; Mon, 27 Jul 2015 12:03:07 +0000 Received: from iwj by xenbits.xen.org with local (Exim 4.72) (envelope-from ) id 1ZJh7a-0007Mm-P4; Mon, 27 Jul 2015 12:03:07 +0000 Date: Mon, 27 Jul 2015 12:03:06 +0000 Message-Id: Content-Type: multipart/mixed; boundary="=separator"; charset="utf-8" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) To: xen-announce@lists.xen.org, xen-devel@lists.xen.org, xen-users@lists.xen.org, oss-security@lists.openwall.com From: Xen.org security team Cc: "Xen.org security team" Subject: [Xen-users] Xen Security Advisory 138 (CVE-2015-5154) - QEMU heap overflow flaw while processing certain ATAPI commands. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --=separator Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Xen Security Advisory CVE-2015-5154 / XSA-138 version 2 QEMU heap overflow flaw while processing certain ATAPI commands. UPDATES IN VERSION 2 ==================== Public release. ISSUE DESCRIPTION ================= The QEMU security team has predisclosed the following advisory: A heap overflow flaw was found in the way QEMU's IDE subsystem handled I/O buffer access while processing certain ATAPI commands. A privileged guest user in a guest with CDROM drive enabled could potentially use this flaw to execute arbitrary code on the host with the privileges of the host's QEMU process corresponding to the guest. IMPACT ====== An HVM guest which has access to an emulated IDE CDROM device (e.g. with a device with "devtype=cdrom", or the "cdrom" convenience alias, in the VBD configuration) can exploit this vulnerability to take over the qemu process elevating its privilege to that of the qemu process. VULNERABLE SYSTEMS ================== All Xen systems running x86 HVM guests without stubdomains which have been configured with an emulated CD-ROM driver model are vulnerable. Systems using qemu-dm stubdomain device models (for example, by specifying "device_model_stubdomain_override=1" in xl's domain configuration files) are NOT vulnerable. Both the traditional ("qemu-xen-traditional") or upstream-based ("qemu-xen") qemu device models are potentially vulnerable. Systems running only PV guests are NOT vulnerable. ARM systems are NOT vulnerable. MITIGATION ========== Avoiding the use of emulated CD-ROM devices altogether, by not specifying such devices in the domain configuration, will avoid this issue. Enabling stubdomains will mitigate this issue, by reducing the escalation to only those privileges accorded to the service domain. qemu-dm stubdomains are only available with "qemu-xen-traditional". CREDITS ======= This issue was discovered by Kevin Wolf of Red Hat. RESOLUTION ========== Applying the appropriate attached patch resolves this issue. xsa138-qemut-{1,2}.patch qemu-xen-traditional, Xen unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x, Xen 4.2.x xsa138-qemuu-{1,2,3}.patch qemu-upstream, xen unstable, Xen 4.5.x, Xen 4.4.x, Xen 4.3.x xsa138-qemuu-{1,3}.patch qemu-upstream, Xen 4.2.x NOTE: xsa138-qemuu-2.patch is not required for Xen 4.2.x. $ sha256sum xsa138*.patch 7e385455379d88658b8ab0d4c1effffe9af21fff2e1dc0fe51cacc779afc83a4 xsa138-qemut-1.patch c9a89082e36a0646a6fe002c6892d966d415d11ad5cfdcfea7e9c8d7a3f1316c xsa138-qemut-2.patch a076808f543c82aeac2f0239a4a46d9baadcd4e4b0a2f9ae7ded99cf59cffde6 xsa138-qemuu-1.patch ed16dca7d2c179d0931d6e2503264d6593547a803eb3f08f6db7fff2127509a9 xsa138-qemuu-2.patch 090bdec00ede1f0ace1af52833038a74971e060d0c176b42bfca08511d36c644 xsa138-qemuu-3.patch $ DEPLOYMENT DURING EMBARGO ========================= Deployment of patches or mitigations is NOT permitted (except on systems used and administered only by organisations which are members of the Xen Project Security Issues Predisclosure List). Specifically, deployment on public cloud systems is NOT permitted. The decision not to permit deployment was made by the group that, at their discretion, disclosed the issue to the Xen Project Security Team. Deployment is permitted only AFTER the embargo ends. (Note: this during-embargo deployment notice is retained in post-embargo publicly released Xen Project advisories, even though it is then no longer applicable. This is to enable the community to have oversight of the Xen Project Security Team's decisionmaking.) For more information about permissible uses of embargoed information, consult the Xen Project community's agreed Security Policy: http://www.xenproject.org/security-policy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJVth2LAAoJEIP+FMlX6CvZcd4IAJYWZrj86FDn9L5SqeTq8cLX 6tnptNaQb+uDQ/thV2R+nUVdJNaJt1UIhRhO2tD2g0dEqj/I7Vx/Hh95ncPCQ3fS ec7ph9lcsdAy8E+7abNlhJnPsOVOazEwI0we2deKjdn3CqyfVXqA47rSDY4VChtc kTV7lEIEebBlo1igz05/poUEhjkCP8UvSfpgpQY60N2y+C0OyIXPIog4q2LiEbeO cq/deACYN3jOVwPTozkQNAAOq0++UfnGfDredOIYCbvqA5OtMf1DGlWyTQLIEuKJ zCiatGudJI2klVYkHSVYfXr54WjreiRCOfLB9ilhBW7Yr2juWFQIAc+0Kf09uFo= =I0Tz -----END PGP SIGNATURE----- --=separator Content-Type: application/octet-stream; name="xsa138-qemut-1.patch" Content-Disposition: attachment; filename="xsa138-qemut-1.patch" Content-Transfer-Encoding: base64 RnJvbSA1MTA5NTJkNGMzM2VlNjk1NzQxNjdjZTMwODI5YjIxYzgxNWExNjVi IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTM6 MzEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEvMl0gaWRlOiBDaGVjayBhcnJh eSBib3VuZHMgYmVmb3JlIHdyaXRpbmcgdG8gaW9fYnVmZmVyCiAoQ1ZFLTIw MTUtNTE1NCkKCklmIHRoZSBlbmRfdHJhbnNmZXJfZnVuYyBvZiBhIGNvbW1h bmQgaXMgY2FsbGVkIGJlY2F1c2UgZW5vdWdoIGRhdGEgaGFzCmJlZW4gcmVh ZCBvciB3cml0dGVuIGZvciB0aGUgY3VycmVudCBQSU8gdHJhbnNmZXIsIGFu ZCBpdCBmYWlscyB0bwpjb3JyZWN0bHkgY2FsbCB0aGUgY29tbWFuZCBjb21w bGV0aW9uIGZ1bmN0aW9ucywgdGhlIERSUSBiaXQgaW4gdGhlCnN0YXR1cyBy ZWdpc3RlciBhbmQgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMgbWF5IHJlbWFpbiBz ZXQuIFRoaXMgYWxsb3dzIHRoZQpndWVzdCB0byBhY2Nlc3MgZnVydGhlciBi eXRlcyBpbiBzLT5pb19idWZmZXIgYmV5b25kIHMtPmRhdGFfZW5kLCBhbmQK ZXZlbnR1YWxseSBvdmVyZmxvd2luZyB0aGUgaW9fYnVmZmVyLgoKT25lIGNh c2Ugd2hlcmUgdGhpcyBjdXJyZW50bHkgaGFwcGVucyBpcyBlbXVsYXRpb24g b2YgdGhlIEFUQVBJIGNvbW1hbmQKU1RBUlQgU1RPUCBVTklULgoKVGhpcyBw YXRjaCBmaXhlcyB0aGUgcHJvYmxlbSBieSBhZGRpbmcgZXhwbGljaXQgYXJy YXkgYm91bmRzIGNoZWNrcwpiZWZvcmUgYWNjZXNzaW5nIHRoZSBidWZmZXIg aW5zdGVhZCBvZiByZWx5aW5nIG9uIGVuZF90cmFuc2Zlcl9mdW5jIHRvCmZ1 bmN0aW9uIGNvcnJlY3RseS4KCkNjOiBxZW11LXN0YWJsZUBub25nbnUub3Jn ClNpZ25lZC1vZmYtYnk6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+ Ci0tLQogaHcvaWRlLmMgfCAxNiArKysrKysrKysrKysrKysrCiAxIGZpbGUg Y2hhbmdlZCwgMTYgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2h3L2lk ZS5jIGIvaHcvaWRlLmMKaW5kZXggNzkxNjY2Yi4uMjExZWM4OCAxMDA2NDQK LS0tIGEvaHcvaWRlLmMKKysrIGIvaHcvaWRlLmMKQEAgLTMwMDIsNiArMzAw MiwxMCBAQCBzdGF0aWMgdm9pZCBpZGVfZGF0YV93cml0ZXcodm9pZCAqb3Bh cXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCiAgICAgYnVmZmVy ZWRfcGlvX3dyaXRlKHMsIGFkZHIsIDIpOwogCiAgICAgcCA9IHMtPmRhdGFf cHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAgICAg IHJldHVybjsKKyAgICB9CisKICAgICAqKHVpbnQxNl90ICopcCA9IGxlMTZf dG9fY3B1KHZhbCk7CiAgICAgcCArPSAyOwogICAgIHMtPmRhdGFfcHRyID0g cDsKQEAgLTMwMjEsNiArMzAyNSwxMCBAQCBzdGF0aWMgdWludDMyX3QgaWRl X2RhdGFfcmVhZHcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQogICAg IGJ1ZmZlcmVkX3Bpb19yZWFkKHMsIGFkZHIsIDIpOwogCiAgICAgcCA9IHMt PmRhdGFfcHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7Cisg ICAgICAgIHJldHVybiAwOworICAgIH0KKwogICAgIHJldCA9IGNwdV90b19s ZTE2KCoodWludDE2X3QgKilwKTsKICAgICBwICs9IDI7CiAgICAgcy0+ZGF0 YV9wdHIgPSBwOwpAQCAtMzA0MCw2ICszMDQ4LDEwIEBAIHN0YXRpYyB2b2lk IGlkZV9kYXRhX3dyaXRlbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90IGFkZHIs IHVpbnQzMl90IHZhbCkKICAgICBidWZmZXJlZF9waW9fd3JpdGUocywgYWRk ciwgNCk7CiAKICAgICBwID0gcy0+ZGF0YV9wdHI7CisgICAgaWYgKHAgKyA0 ID4gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcmV0dXJuOworICAgIH0KKwog ICAgICoodWludDMyX3QgKilwID0gbGUzMl90b19jcHUodmFsKTsKICAgICBw ICs9IDQ7CiAgICAgcy0+ZGF0YV9wdHIgPSBwOwpAQCAtMzA1OSw2ICszMDcx LDEwIEBAIHN0YXRpYyB1aW50MzJfdCBpZGVfZGF0YV9yZWFkbCh2b2lkICpv cGFxdWUsIHVpbnQzMl90IGFkZHIpCiAgICAgYnVmZmVyZWRfcGlvX3JlYWQo cywgYWRkciwgNCk7CiAKICAgICBwID0gcy0+ZGF0YV9wdHI7CisgICAgaWYg KHAgKyA0ID4gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcmV0dXJuIDA7Cisg ICAgfQorCiAgICAgcmV0ID0gY3B1X3RvX2xlMzIoKih1aW50MzJfdCAqKXAp OwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0tIAoyLjEu NAoK --=separator Content-Type: application/octet-stream; name="xsa138-qemut-2.patch" Content-Disposition: attachment; filename="xsa138-qemut-2.patch" Content-Transfer-Encoding: base64 RnJvbSAxYWMwZjYwZDU1OGI3ZmNhNTVjNjlhNjFhYjRjNDUzOGFmMWYwMmY5 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6NDE6 MjcgKzAyMDAKU3ViamVjdDogW1BBVENIIDIvMl0gaWRlOiBDbGVhciBEUlEg YWZ0ZXIgaGFuZGxpbmcgYWxsIGV4cGVjdGVkIGFjY2Vzc2VzCgpUaGlzIGlz IGFkZGl0aW9uYWwgaGFyZGVuaW5nIGFnYWluc3QgYW4gZW5kX3RyYW5zZmVy X2Z1bmMgdGhhdCBmYWlscyB0bwpjbGVhciB0aGUgRFJRIHN0YXR1cyBiaXQu IFRoZSBiaXQgbXVzdCBiZSB1bnNldCBhcyBzb29uIGFzIHRoZSBQSU8KdHJh bnNmZXIgaGFzIGNvbXBsZXRlZCwgc28gaXQncyBiZXR0ZXIgdG8gZG8gdGhp cyBpbiBhIGNlbnRyYWwgcGxhY2UKaW5zdGVhZCBvZiBkdXBsaWNhdGluZyB0 aGUgY29kZSBpbiBhbGwgY29tbWFuZHMgKGFuZCBmb3JnZXR0aW5nIGl0IGlu CnNvbWUpLgoKU2lnbmVkLW9mZi1ieTogS2V2aW4gV29sZiA8a3dvbGZAcmVk aGF0LmNvbT4KLS0tCiBody9pZGUuYyB8IDE2ICsrKysrKysrKysrKy0tLS0K IDEgZmlsZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspLCA0IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL2h3L2lkZS5jIGIvaHcvaWRlLmMKaW5kZXgg MjExZWM4OC4uN2I4NGQxYiAxMDA2NDQKLS0tIGEvaHcvaWRlLmMKKysrIGIv aHcvaWRlLmMKQEAgLTMwMDksOCArMzAwOSwxMCBAQCBzdGF0aWMgdm9pZCBp ZGVfZGF0YV93cml0ZXcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1 aW50MzJfdCB2YWwpCiAgICAgKih1aW50MTZfdCAqKXAgPSBsZTE2X3RvX2Nw dSh2YWwpOwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0g ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0 YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAg ICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogfQogCiBz dGF0aWMgdWludDMyX3QgaWRlX2RhdGFfcmVhZHcodm9pZCAqb3BhcXVlLCB1 aW50MzJfdCBhZGRyKQpAQCAtMzAzMiw4ICszMDM0LDEwIEBAIHN0YXRpYyB1 aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpvcGFxdWUsIHVpbnQzMl90 IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMTYoKih1aW50MTZfdCAqKXAp OwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYg KHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQp IHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAgICAg cy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVybiBy ZXQ7CiB9CiAKQEAgLTMwNTUsOCArMzA1OSwxMCBAQCBzdGF0aWMgdm9pZCBp ZGVfZGF0YV93cml0ZWwodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1 aW50MzJfdCB2YWwpCiAgICAgKih1aW50MzJfdCAqKXAgPSBsZTMyX3RvX2Nw dSh2YWwpOwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0g ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0 YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAg ICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogfQogCiBz dGF0aWMgdWludDMyX3QgaWRlX2RhdGFfcmVhZGwodm9pZCAqb3BhcXVlLCB1 aW50MzJfdCBhZGRyKQpAQCAtMzA3OCw4ICszMDg0LDEwIEBAIHN0YXRpYyB1 aW50MzJfdCBpZGVfZGF0YV9yZWFkbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90 IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMzIoKih1aW50MzJfdCAqKXAp OwogICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYg KHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQp IHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAgICAg cy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVybiBy ZXQ7CiB9CiAKLS0gCjIuMS40Cgo= --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-1.patch" Content-Disposition: attachment; filename="xsa138-qemuu-1.patch" Content-Transfer-Encoding: base64 RnJvbSBhOWRlMTQxNzU1NDhjMDRlMGY4YmU3ZmFlMjE5MjQ2NTA5YmE0NmE5 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTM6 MzEgKzAyMDAKU3ViamVjdDogW1BBVENIIDEvM10gaWRlOiBDaGVjayBhcnJh eSBib3VuZHMgYmVmb3JlIHdyaXRpbmcgdG8gaW9fYnVmZmVyCiAoQ1ZFLTIw MTUtNTE1NCkKCklmIHRoZSBlbmRfdHJhbnNmZXJfZnVuYyBvZiBhIGNvbW1h bmQgaXMgY2FsbGVkIGJlY2F1c2UgZW5vdWdoIGRhdGEgaGFzCmJlZW4gcmVh ZCBvciB3cml0dGVuIGZvciB0aGUgY3VycmVudCBQSU8gdHJhbnNmZXIsIGFu ZCBpdCBmYWlscyB0bwpjb3JyZWN0bHkgY2FsbCB0aGUgY29tbWFuZCBjb21w bGV0aW9uIGZ1bmN0aW9ucywgdGhlIERSUSBiaXQgaW4gdGhlCnN0YXR1cyBy ZWdpc3RlciBhbmQgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMgbWF5IHJlbWFpbiBz ZXQuIFRoaXMgYWxsb3dzIHRoZQpndWVzdCB0byBhY2Nlc3MgZnVydGhlciBi eXRlcyBpbiBzLT5pb19idWZmZXIgYmV5b25kIHMtPmRhdGFfZW5kLCBhbmQK ZXZlbnR1YWxseSBvdmVyZmxvd2luZyB0aGUgaW9fYnVmZmVyLgoKT25lIGNh c2Ugd2hlcmUgdGhpcyBjdXJyZW50bHkgaGFwcGVucyBpcyBlbXVsYXRpb24g b2YgdGhlIEFUQVBJIGNvbW1hbmQKU1RBUlQgU1RPUCBVTklULgoKVGhpcyBw YXRjaCBmaXhlcyB0aGUgcHJvYmxlbSBieSBhZGRpbmcgZXhwbGljaXQgYXJy YXkgYm91bmRzIGNoZWNrcwpiZWZvcmUgYWNjZXNzaW5nIHRoZSBidWZmZXIg aW5zdGVhZCBvZiByZWx5aW5nIG9uIGVuZF90cmFuc2Zlcl9mdW5jIHRvCmZ1 bmN0aW9uIGNvcnJlY3RseS4KCkNjOiBxZW11LXN0YWJsZUBub25nbnUub3Jn ClNpZ25lZC1vZmYtYnk6IEtldmluIFdvbGYgPGt3b2xmQHJlZGhhdC5jb20+ Ci0tLQogaHcvaWRlL2NvcmUuYyB8IDE2ICsrKysrKysrKysrKysrKysKIDEg ZmlsZSBjaGFuZ2VkLCAxNiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEv aHcvaWRlL2NvcmUuYyBiL2h3L2lkZS9jb3JlLmMKaW5kZXggMTIyZTk1NS4u NDRmY2MyMyAxMDA2NDQKLS0tIGEvaHcvaWRlL2NvcmUuYworKysgYi9ody9p ZGUvY29yZS5jCkBAIC0yMDIxLDYgKzIwMjEsMTAgQEAgdm9pZCBpZGVfZGF0 YV93cml0ZXcodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyLCB1aW50MzJf dCB2YWwpCiAgICAgfQogCiAgICAgcCA9IHMtPmRhdGFfcHRyOworICAgIGlm IChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAgICAgIHJldHVybjsKKyAg ICB9CisKICAgICAqKHVpbnQxNl90ICopcCA9IGxlMTZfdG9fY3B1KHZhbCk7 CiAgICAgcCArPSAyOwogICAgIHMtPmRhdGFfcHRyID0gcDsKQEAgLTIwNDIs NiArMjA0NiwxMCBAQCB1aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpv cGFxdWUsIHVpbnQzMl90IGFkZHIpCiAgICAgfQogCiAgICAgcCA9IHMtPmRh dGFfcHRyOworICAgIGlmIChwICsgMiA+IHMtPmRhdGFfZW5kKSB7CisgICAg ICAgIHJldHVybiAwOworICAgIH0KKwogICAgIHJldCA9IGNwdV90b19sZTE2 KCoodWludDE2X3QgKilwKTsKICAgICBwICs9IDI7CiAgICAgcy0+ZGF0YV9w dHIgPSBwOwpAQCAtMjA2Myw2ICsyMDcxLDEwIEBAIHZvaWQgaWRlX2RhdGFf d3JpdGVsKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMyX3Qg dmFsKQogICAgIH0KIAogICAgIHAgPSBzLT5kYXRhX3B0cjsKKyAgICBpZiAo cCArIDQgPiBzLT5kYXRhX2VuZCkgeworICAgICAgICByZXR1cm47CisgICAg fQorCiAgICAgKih1aW50MzJfdCAqKXAgPSBsZTMyX3RvX2NwdSh2YWwpOwog ICAgIHAgKz0gNDsKICAgICBzLT5kYXRhX3B0ciA9IHA7CkBAIC0yMDg0LDYg KzIwOTYsMTAgQEAgdWludDMyX3QgaWRlX2RhdGFfcmVhZGwodm9pZCAqb3Bh cXVlLCB1aW50MzJfdCBhZGRyKQogICAgIH0KIAogICAgIHAgPSBzLT5kYXRh X3B0cjsKKyAgICBpZiAocCArIDQgPiBzLT5kYXRhX2VuZCkgeworICAgICAg ICByZXR1cm4gMDsKKyAgICB9CisKICAgICByZXQgPSBjcHVfdG9fbGUzMigq KHVpbnQzMl90ICopcCk7CiAgICAgcCArPSA0OwogICAgIHMtPmRhdGFfcHRy ID0gcDsKLS0gCjEuOC4zLjEK --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-2.patch" Content-Disposition: attachment; filename="xsa138-qemuu-2.patch" Content-Transfer-Encoding: base64 RnJvbSBhYTg1MWQzMGFjZmJiOTU4MDA5OGFjMWRjODI4ODU1MzBjYjhiM2Mx IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6MTc6 NDYgKzAyMDAKU3ViamVjdDogW1BBVENIIDIvM10gaWRlL2F0YXBpOiBGaXgg U1RBUlQgU1RPUCBVTklUIGNvbW1hbmQgY29tcGxldGlvbgoKVGhlIGNvbW1h bmQgbXVzdCBiZSBjb21wbGV0ZWQgb24gYWxsIGNvZGUgcGF0aHMuIFNUQVJU IFNUT1AgVU5JVCB3aXRoCnB3cmNuZCBzZXQgc2hvdWxkIHN1Y2NlZWQgd2l0 aG91dCBkb2luZyBhbnl0aGluZy4KClNpZ25lZC1vZmYtYnk6IEtldmluIFdv bGYgPGt3b2xmQHJlZGhhdC5jb20+Ci0tLQogaHcvaWRlL2F0YXBpLmMgfCAx ICsKIDEgZmlsZSBjaGFuZ2VkLCAxIGluc2VydGlvbigrKQoKZGlmZiAtLWdp dCBhL2h3L2lkZS9hdGFwaS5jIGIvaHcvaWRlL2F0YXBpLmMKaW5kZXggOTUw ZTMxMS4uNzlkZDE2NyAxMDA2NDQKLS0tIGEvaHcvaWRlL2F0YXBpLmMKKysr IGIvaHcvaWRlL2F0YXBpLmMKQEAgLTk4Myw2ICs5ODMsNyBAQCBzdGF0aWMg dm9pZCBjbWRfc3RhcnRfc3RvcF91bml0KElERVN0YXRlICpzLCB1aW50OF90 KiBidWYpCgogICAgIGlmIChwd3JjbmQpIHsKICAgICAgICAgLyogZWplY3Qv bG9hZCBvbmx5IGhhcHBlbnMgZm9yIHBvd2VyIGNvbmRpdGlvbiA9PSAwICov CisgICAgICAgIGlkZV9hdGFwaV9jbWRfb2socyk7CiAgICAgICAgIHJldHVy bjsKICAgICB9CgotLQoxLjguMy4xCgo= --=separator Content-Type: application/octet-stream; name="xsa138-qemuu-3.patch" Content-Disposition: attachment; filename="xsa138-qemuu-3.patch" Content-Transfer-Encoding: base64 RnJvbSAxZDNjMjI2OGY4NzA4MTI2YTM0MDY0YzJlMGMxMDAwYjQwZTZmM2U1 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBLZXZpbiBXb2xmIDxr d29sZkByZWRoYXQuY29tPgpEYXRlOiBXZWQsIDMgSnVuIDIwMTUgMTQ6NDE6 MjcgKzAyMDAKU3ViamVjdDogW1BBVENIIDMvM10gaWRlOiBDbGVhciBEUlEg YWZ0ZXIgaGFuZGxpbmcgYWxsIGV4cGVjdGVkIGFjY2Vzc2VzCgpUaGlzIGlz IGFkZGl0aW9uYWwgaGFyZGVuaW5nIGFnYWluc3QgYW4gZW5kX3RyYW5zZmVy X2Z1bmMgdGhhdCBmYWlscyB0bwpjbGVhciB0aGUgRFJRIHN0YXR1cyBiaXQu IFRoZSBiaXQgbXVzdCBiZSB1bnNldCBhcyBzb29uIGFzIHRoZSBQSU8KdHJh bnNmZXIgaGFzIGNvbXBsZXRlZCwgc28gaXQncyBiZXR0ZXIgdG8gZG8gdGhp cyBpbiBhIGNlbnRyYWwgcGxhY2UKaW5zdGVhZCBvZiBkdXBsaWNhdGluZyB0 aGUgY29kZSBpbiBhbGwgY29tbWFuZHMgKGFuZCBmb3JnZXR0aW5nIGl0IGlu CnNvbWUpLgoKU2lnbmVkLW9mZi1ieTogS2V2aW4gV29sZiA8a3dvbGZAcmVk aGF0LmNvbT4KLS0tCiBody9pZGUvY29yZS5jIHwgMTYgKysrKysrKysrKysr LS0tLQogMSBmaWxlIGNoYW5nZWQsIDEyIGluc2VydGlvbnMoKyksIDQgZGVs ZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvaHcvaWRlL2NvcmUuYyBiL2h3L2lk ZS9jb3JlLmMKaW5kZXggNDRmY2MyMy4uNTA0NDljYSAxMDA2NDQKLS0tIGEv aHcvaWRlL2NvcmUuYworKysgYi9ody9pZGUvY29yZS5jCkBAIC0yMDI4LDgg KzIwMjgsMTAgQEAgdm9pZCBpZGVfZGF0YV93cml0ZXcodm9pZCAqb3BhcXVl LCB1aW50MzJfdCBhZGRyLCB1aW50MzJfdCB2YWwpCiAgICAgKih1aW50MTZf dCAqKXAgPSBsZTE2X3RvX2NwdSh2YWwpOwogICAgIHAgKz0gMjsKICAgICBz LT5kYXRhX3B0ciA9IHA7Ci0gICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisg ICAgaWYgKHAgPj0gcy0+ZGF0YV9lbmQpIHsKKyAgICAgICAgcy0+c3RhdHVz ICY9IH5EUlFfU1RBVDsKICAgICAgICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMo cyk7CisgICAgfQogfQoKIHVpbnQzMl90IGlkZV9kYXRhX3JlYWR3KHZvaWQg Km9wYXF1ZSwgdWludDMyX3QgYWRkcikKQEAgLTIwNTMsOCArMjA1NSwxMCBA QCB1aW50MzJfdCBpZGVfZGF0YV9yZWFkdyh2b2lkICpvcGFxdWUsIHVpbnQz Ml90IGFkZHIpCiAgICAgcmV0ID0gY3B1X3RvX2xlMTYoKih1aW50MTZfdCAq KXApOwogICAgIHAgKz0gMjsKICAgICBzLT5kYXRhX3B0ciA9IHA7Ci0gICAg aWYgKHAgPj0gcy0+ZGF0YV9lbmQpCisgICAgaWYgKHAgPj0gcy0+ZGF0YV9l bmQpIHsKKyAgICAgICAgcy0+c3RhdHVzICY9IH5EUlFfU1RBVDsKICAgICAg ICAgcy0+ZW5kX3RyYW5zZmVyX2Z1bmMocyk7CisgICAgfQogICAgIHJldHVy biByZXQ7CiB9CgpAQCAtMjA3OCw4ICsyMDgyLDEwIEBAIHZvaWQgaWRlX2Rh dGFfd3JpdGVsKHZvaWQgKm9wYXF1ZSwgdWludDMyX3QgYWRkciwgdWludDMy X3QgdmFsKQogICAgICoodWludDMyX3QgKilwID0gbGUzMl90b19jcHUodmFs KTsKICAgICBwICs9IDQ7CiAgICAgcy0+ZGF0YV9wdHIgPSBwOwotICAgIGlm IChwID49IHMtPmRhdGFfZW5kKQorICAgIGlmIChwID49IHMtPmRhdGFfZW5k KSB7CisgICAgICAgIHMtPnN0YXR1cyAmPSB+RFJRX1NUQVQ7CiAgICAgICAg IHMtPmVuZF90cmFuc2Zlcl9mdW5jKHMpOworICAgIH0KIH0KCiB1aW50MzJf dCBpZGVfZGF0YV9yZWFkbCh2b2lkICpvcGFxdWUsIHVpbnQzMl90IGFkZHIp CkBAIC0yMTAzLDggKzIxMDksMTAgQEAgdWludDMyX3QgaWRlX2RhdGFfcmVh ZGwodm9pZCAqb3BhcXVlLCB1aW50MzJfdCBhZGRyKQogICAgIHJldCA9IGNw dV90b19sZTMyKCoodWludDMyX3QgKilwKTsKICAgICBwICs9IDQ7CiAgICAg cy0+ZGF0YV9wdHIgPSBwOwotICAgIGlmIChwID49IHMtPmRhdGFfZW5kKQor ICAgIGlmIChwID49IHMtPmRhdGFfZW5kKSB7CisgICAgICAgIHMtPnN0YXR1 cyAmPSB+RFJRX1NUQVQ7CiAgICAgICAgIHMtPmVuZF90cmFuc2Zlcl9mdW5j KHMpOworICAgIH0KICAgICByZXR1cm4gcmV0OwogfQoKLS0KMS44LjMuMQoK --=separator Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --=separator-- From xen-users-bounces@lists.xen.org Mon Jul 27 12:25:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 12:25:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJhS5-0002nK-Bz; Mon, 27 Jul 2015 12:24:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJhS4-0002nE-Qk for xen-users@lists.xen.org; Mon, 27 Jul 2015 12:24:16 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 43/BF-17050-0F226B55; Mon, 27 Jul 2015 12:24:16 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1437999855!29544693!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30276 invoked from network); 27 Jul 2015 12:24:15 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-12.tower-31.messagelabs.com with SMTP; 27 Jul 2015 12:24:15 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 47CE42452E6 for ; Mon, 27 Jul 2015 14:24:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx8rKPF7xF_l for ; Mon, 27 Jul 2015 14:24:14 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 968B82452E4 for ; Mon, 27 Jul 2015 14:24:13 +0200 (CEST) From: Wolf Grossi To: xen-users@lists.xen.org X-Enigmail-Draft-Status: N1110 Message-ID: <55B622EB.2000902@magro-soft.com> Date: Mon, 27 Jul 2015 14:24:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Subject: [Xen-users] XEN-4.4 USB on domU not visible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Greetings, using XEN-4.4 on an openSuSE-13.2 I added a USB-device with the graphic tool virt-manager. In the info-screen of the guest it shows the correct Physical USB Device. In the GUEST.xml the USB device is defined as: However, doing a lsusb in the guest throws the error 'unable to initialize libusb: -99' I checked the libraries, libusb is installed and accessable. Any hints? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 12:25:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 12:25:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJhS5-0002nK-Bz; Mon, 27 Jul 2015 12:24:17 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJhS4-0002nE-Qk for xen-users@lists.xen.org; Mon, 27 Jul 2015 12:24:16 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 43/BF-17050-0F226B55; Mon, 27 Jul 2015 12:24:16 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1437999855!29544693!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30276 invoked from network); 27 Jul 2015 12:24:15 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-12.tower-31.messagelabs.com with SMTP; 27 Jul 2015 12:24:15 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 47CE42452E6 for ; Mon, 27 Jul 2015 14:24:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx8rKPF7xF_l for ; Mon, 27 Jul 2015 14:24:14 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 968B82452E4 for ; Mon, 27 Jul 2015 14:24:13 +0200 (CEST) From: Wolf Grossi To: xen-users@lists.xen.org X-Enigmail-Draft-Status: N1110 Message-ID: <55B622EB.2000902@magro-soft.com> Date: Mon, 27 Jul 2015 14:24:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Subject: [Xen-users] XEN-4.4 USB on domU not visible X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Greetings, using XEN-4.4 on an openSuSE-13.2 I added a USB-device with the graphic tool virt-manager. In the info-screen of the guest it shows the correct Physical USB Device. In the GUEST.xml the USB device is defined as: However, doing a lsusb in the guest throws the error 'unable to initialize libusb: -99' I checked the libraries, libusb is installed and accessable. Any hints? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Mon Jul 27 16:31:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 16:31:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJlIA-0003h7-7b; Mon, 27 Jul 2015 16:30:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJlI9-0003h1-Et for xen-users@lists.xen.org; Mon, 27 Jul 2015 16:30:17 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 7F/F7-19220-89C56B55; Mon, 27 Jul 2015 16:30:16 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-12.tower-206.messagelabs.com!1438014616!23909343!1 X-Originating-IP: [212.7.160.41] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7407 invoked from network); 27 Jul 2015 16:30:16 -0000 Received: from mout01.rz-online.net (HELO mout01.rz-online.net) (212.7.160.41) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jul 2015 16:30:16 -0000 Received: from donald.local (212-7-188-136.ktk-ip.de [212.7.188.136]) by mout01.rz-online.net (8.14.0/8.12.10) with ESMTP id t6RGUFR4012870 for ; Mon, 27 Jul 2015 18:30:15 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id 48CEFA3D9B for ; Mon, 27 Jul 2015 18:24:38 +0200 (CEST) Message-ID: <55B65B46.5000805@rz-online.de> Date: Mon, 27 Jul 2015 18:24:38 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Length: 1500 Subject: [Xen-users] Xen serial console has only 7 bit? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SSB0cmllZCB0byB1c2UgdGhlIFhlbiBzZXJpYWwgY29uc29sZSwgYXMgZGVzY3JpYmVkIGluIApo dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX1NlcmlhbF9Db25zb2xlIC4gSSBhbHNvIHVzZWQg dGhlIHJlc3VsdGluZyAKeHZjMCBkZXZpY2UgYXMgYSBjb25zb2xlIG9mIHRoZSBET00wIExpbnV4 LgoKRXZlcnl0aGluZyB3YXMgd29ya2luZyBmaW5lLCBhbmQgSSBjb3VsZCBleHBsb3JlIHRoZSBm ZWF0dXJlcyBvZiB0aGUgWGVuIApjb25zb2xlLiBBbG1vc3QgZXZlcnl0aGluZy4uLiBGaW5hbGx5 IEkgZGlzY292ZXJlZCwgdGhhdCB3aGVuIGxvZ2dpbmcgaW4gCnRvIExpbnV4IG9uIHRoZSBzZXJp YWwgY29uc29sZSwgSSBjb3VsZCBub3QgdXNlIGdlcm1hbiB1bWxhdXRzLiBJdCAKc2VlbWVkIGFz IGlmIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCB3YXMgbWFza2VkIG9mZiBkdXJpbmcgaW5wdXQu CgpBZnRlciBhIGxvbmcgc2VhcmNoLCB3aGF0IEkgd2FzIGRvaW5nIHdyb25nIEkgc2F3IHRoaXMg bGluZSBvZiBjb2RlIAppbnNpZGUgdGhlIFhlbiBzZXJpYWwgZHJpdmVyOgoKaHR0cDovL3hlbmJp dHMueGVuLm9yZy9naXR3ZWIvP3A9eGVuLmdpdDthPWJsb2I7Zj14ZW4vZHJpdmVycy9jaGFyL3Nl cmlhbC5jO2g9YzU4M2E0OGMwODIzZTdiZjI2MTlhMWE2M2YwNWRhM2JmYmQyMGUzZDtoYj1IRUFE I2wzMDAKCk9LLCB0aGlzIGV4cGxhaW5zIHRoZSBiZWhhdmlvdXIuIEJ1dCB3aGF0IGlzIHRoZSBp bnRlbnRpb24gb2YgdGhpcyBsaW5lPyAKU2hvdWxkbid0IHRoaXMgYWN0dWFsbHkgYmUgc29tZXRo aW5nIGxpa2UKCmlmIChoYW5kbGUgJiBTRVJITkRfSEkpCnsKICAgICBjICY9IDB4N2Y7Cn0KcmV0 dXJuIGM7CgotLSAKTWFuZnJlZCBIw6RydGVsLCBEQjNITSAgICBtYWlsdG86TWFuZnJlZC5IYWVy dGVsQHJ6LW9ubGluZS5kZQogICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9yei1ob21l LmRlL21oYWVydGVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0cy54ZW4ub3JnCmh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Mon Jul 27 16:31:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Mon, 27 Jul 2015 16:31:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJlIA-0003h7-7b; Mon, 27 Jul 2015 16:30:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJlI9-0003h1-Et for xen-users@lists.xen.org; Mon, 27 Jul 2015 16:30:17 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 7F/F7-19220-89C56B55; Mon, 27 Jul 2015 16:30:16 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-12.tower-206.messagelabs.com!1438014616!23909343!1 X-Originating-IP: [212.7.160.41] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7407 invoked from network); 27 Jul 2015 16:30:16 -0000 Received: from mout01.rz-online.net (HELO mout01.rz-online.net) (212.7.160.41) by server-12.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 27 Jul 2015 16:30:16 -0000 Received: from donald.local (212-7-188-136.ktk-ip.de [212.7.188.136]) by mout01.rz-online.net (8.14.0/8.12.10) with ESMTP id t6RGUFR4012870 for ; Mon, 27 Jul 2015 18:30:15 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id 48CEFA3D9B for ; Mon, 27 Jul 2015 18:24:38 +0200 (CEST) Message-ID: <55B65B46.5000805@rz-online.de> Date: Mon, 27 Jul 2015 18:24:38 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users@lists.xen.org Content-Length: 1500 Subject: [Xen-users] Xen serial console has only 7 bit? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org SSB0cmllZCB0byB1c2UgdGhlIFhlbiBzZXJpYWwgY29uc29sZSwgYXMgZGVzY3JpYmVkIGluIApo dHRwOi8vd2lraS54ZW4ub3JnL3dpa2kvWGVuX1NlcmlhbF9Db25zb2xlIC4gSSBhbHNvIHVzZWQg dGhlIHJlc3VsdGluZyAKeHZjMCBkZXZpY2UgYXMgYSBjb25zb2xlIG9mIHRoZSBET00wIExpbnV4 LgoKRXZlcnl0aGluZyB3YXMgd29ya2luZyBmaW5lLCBhbmQgSSBjb3VsZCBleHBsb3JlIHRoZSBm ZWF0dXJlcyBvZiB0aGUgWGVuIApjb25zb2xlLiBBbG1vc3QgZXZlcnl0aGluZy4uLiBGaW5hbGx5 IEkgZGlzY292ZXJlZCwgdGhhdCB3aGVuIGxvZ2dpbmcgaW4gCnRvIExpbnV4IG9uIHRoZSBzZXJp YWwgY29uc29sZSwgSSBjb3VsZCBub3QgdXNlIGdlcm1hbiB1bWxhdXRzLiBJdCAKc2VlbWVkIGFz IGlmIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCB3YXMgbWFza2VkIG9mZiBkdXJpbmcgaW5wdXQu CgpBZnRlciBhIGxvbmcgc2VhcmNoLCB3aGF0IEkgd2FzIGRvaW5nIHdyb25nIEkgc2F3IHRoaXMg bGluZSBvZiBjb2RlIAppbnNpZGUgdGhlIFhlbiBzZXJpYWwgZHJpdmVyOgoKaHR0cDovL3hlbmJp dHMueGVuLm9yZy9naXR3ZWIvP3A9eGVuLmdpdDthPWJsb2I7Zj14ZW4vZHJpdmVycy9jaGFyL3Nl cmlhbC5jO2g9YzU4M2E0OGMwODIzZTdiZjI2MTlhMWE2M2YwNWRhM2JmYmQyMGUzZDtoYj1IRUFE I2wzMDAKCk9LLCB0aGlzIGV4cGxhaW5zIHRoZSBiZWhhdmlvdXIuIEJ1dCB3aGF0IGlzIHRoZSBp bnRlbnRpb24gb2YgdGhpcyBsaW5lPyAKU2hvdWxkbid0IHRoaXMgYWN0dWFsbHkgYmUgc29tZXRo aW5nIGxpa2UKCmlmIChoYW5kbGUgJiBTRVJITkRfSEkpCnsKICAgICBjICY9IDB4N2Y7Cn0KcmV0 dXJuIGM7CgotLSAKTWFuZnJlZCBIw6RydGVsLCBEQjNITSAgICBtYWlsdG86TWFuZnJlZC5IYWVy dGVsQHJ6LW9ubGluZS5kZQogICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHA6Ly9yei1ob21l LmRlL21oYWVydGVsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0cy54ZW4ub3JnCmh0dHA6 Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Tue Jul 28 03:53:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 03:53:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwf-0001j0-8h; Tue, 28 Jul 2015 03:52:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwd-0001ic-Iw; Tue, 28 Jul 2015 03:52:47 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 66/C8-19125-E8CF6B55; Tue, 28 Jul 2015 03:52:46 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1438055566!21124365!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 503 invoked from network); 28 Jul 2015 03:52:46 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 03:52:46 -0000 Received: by wibud3 with SMTP id ud3so163484062wib.1; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=z58TzHytt85SkKfOISQsb6ZI32MQY1ZtcB0XxtdrcCA=; b=hxxzveWJYdVzPcCo7buqr1IY9nqJZbq9SmkoexvNWLnaMC7Ad+h0wTwdlfJQ3y+ynB oJ2MpGMcCoDjOJE1YkL/62fU2A+N1vVCteQE/IW21tVaDbVxaYYHAlTFGlH9w1jpXDX1 mfppy8vfJ/G76u5uwmyl6R9OKR8TL8M44SkQumlDxkUKzJ26LCqV+KQGxw73M8CN95Nb Z31C4EFPlSIy3yuBdhSnltdmD4K54rOSDJFpOl0GfYK9X904C06/hOidG3hjBa6m3u3u Ykjzmwg6b0GvpTAE3zPF4/epZ7pCt5ssB0zTCtJEfL81LavAUMknxyGjGJ2JW+IW5iVZ sV2A== MIME-Version: 1.0 X-Received: by 10.180.10.200 with SMTP id k8mr2328015wib.5.1438055566013; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Mon, 27 Jul 2015 20:52:45 -0700 (PDT) Date: Mon, 27 Jul 2015 23:52:45 -0400 X-Google-Sender-Auth: Mfns2vI3u7yLA7g3vVkEbD5FcRM Message-ID: From: Russ Pavlicek To: xen-devel , "xen-users@lists.xen.org" , xs-devel@lists.xenserver.org, xen-api@lists.xen.org, mirageos-devel@lists.xenproject.org, "publicity@lists.xenproject.org" Subject: [Xen-users] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Our next Xen Project Document Day is this Wednesday, July 29! Our THEME OF THE MONTH: "The Reverse Yard Sale" For many of us in the northern hemisphere, this is the time of year when people sort through the things they own and put the things they no longer need into a yard sale. Well, instead of removing things we don't need, we want a reverse yard sale, where we add the things we *do* need. Some topics to address include: - Hyper: the new hypervisor-independent Docker engine which uses Xen Project (among other hypervisors); we need a basic document on how to use Xen Project with Hyper - XAPI: The latest docs from the XenServer crew need to be referenced from our wiki - Unikernels: Lots of Unikernels leverage Xen Project; we need them properly linked in to our wiki - Booting with UEFI: needs to be made current - Raisin: the new effort has a new wiki page which needs review - and anything else which needs to be added All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days Also take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 03:53:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 03:53:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwf-0001j0-8h; Tue, 28 Jul 2015 03:52:49 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZJvwd-0001ic-Iw; Tue, 28 Jul 2015 03:52:47 +0000 Received: from [85.158.139.211] by server-14.bemta-5.messagelabs.com id 66/C8-19125-E8CF6B55; Tue, 28 Jul 2015 03:52:46 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-16.tower-206.messagelabs.com!1438055566!21124365!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 503 invoked from network); 28 Jul 2015 03:52:46 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-16.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 03:52:46 -0000 Received: by wibud3 with SMTP id ud3so163484062wib.1; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=z58TzHytt85SkKfOISQsb6ZI32MQY1ZtcB0XxtdrcCA=; b=hxxzveWJYdVzPcCo7buqr1IY9nqJZbq9SmkoexvNWLnaMC7Ad+h0wTwdlfJQ3y+ynB oJ2MpGMcCoDjOJE1YkL/62fU2A+N1vVCteQE/IW21tVaDbVxaYYHAlTFGlH9w1jpXDX1 mfppy8vfJ/G76u5uwmyl6R9OKR8TL8M44SkQumlDxkUKzJ26LCqV+KQGxw73M8CN95Nb Z31C4EFPlSIy3yuBdhSnltdmD4K54rOSDJFpOl0GfYK9X904C06/hOidG3hjBa6m3u3u Ykjzmwg6b0GvpTAE3zPF4/epZ7pCt5ssB0zTCtJEfL81LavAUMknxyGjGJ2JW+IW5iVZ sV2A== MIME-Version: 1.0 X-Received: by 10.180.10.200 with SMTP id k8mr2328015wib.5.1438055566013; Mon, 27 Jul 2015 20:52:46 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Mon, 27 Jul 2015 20:52:45 -0700 (PDT) Date: Mon, 27 Jul 2015 23:52:45 -0400 X-Google-Sender-Auth: Mfns2vI3u7yLA7g3vVkEbD5FcRM Message-ID: From: Russ Pavlicek To: xen-devel , "xen-users@lists.xen.org" , xs-devel@lists.xenserver.org, xen-api@lists.xen.org, mirageos-devel@lists.xenproject.org, "publicity@lists.xenproject.org" Subject: [Xen-users] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Our next Xen Project Document Day is this Wednesday, July 29! Our THEME OF THE MONTH: "The Reverse Yard Sale" For many of us in the northern hemisphere, this is the time of year when people sort through the things they own and put the things they no longer need into a yard sale. Well, instead of removing things we don't need, we want a reverse yard sale, where we add the things we *do* need. Some topics to address include: - Hyper: the new hypervisor-independent Docker engine which uses Xen Project (among other hypervisors); we need a basic document on how to use Xen Project with Hyper - XAPI: The latest docs from the XenServer crew need to be referenced from our wiki - Unikernels: Lots of Unikernels leverage Xen Project; we need them properly linked in to our wiki - Booting with UEFI: needs to be made current - Raisin: the new effort has a new wiki page which needs review - and anything else which needs to be added All the information you need to participate in Document Day is here: http://wiki.xenproject.org/wiki/Xen_Document_Days Also take a look at the current TODO list to see other items which need attention: http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO Please think about how you can help out. If you haven't requested to be made a Wiki editor, save time and do it now so you are ready to go on Document Day. Just fill out the form below: http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 09:45:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 09:45:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK1RA-0005Ml-F4; Tue, 28 Jul 2015 09:44:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK1R9-0005Me-1g for xen-users@lists.xen.org; Tue, 28 Jul 2015 09:44:39 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id E9/D3-01753-60F47B55; Tue, 28 Jul 2015 09:44:38 +0000 X-Env-Sender: prvs=644a1b3a5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1438076672!28651067!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19403 invoked from network); 28 Jul 2015 09:44:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 09:44:33 -0000 X-IronPort-AV: E=Sophos;i="5.15,562,1432598400"; d="scan'208";a="288286407" Message-ID: <1438076670.11600.101.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" , Date: Tue, 28 Jul 2015 10:44:30 +0100 In-Reply-To: <55B65B46.5000805@rz-online.de> References: <55B65B46.5000805@rz-online.de> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Xen serial console has only 7 bit? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-27 at 18:24 +0200, Manfred Haertel, DB3HM wrote: > I tried to use the Xen serial console, as described in > http://wiki.xen.org/wiki/Xen_Serial_Console . I also used the resulting > xvc0 device as a console of the DOM0 Linux. > > Everything was working fine, and I could explore the features of the Xen > console. Almost everything... Finally I discovered, that when logging in > to Linux on the serial console, I could not use german umlauts. It > seemed as if the most significant bit was masked off during input. > > After a long search, what I was doing wrong I saw this line of code > inside the Xen serial driver: > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/drivers/char/serial > .c;h=c583a48c0823e7bf2619a1a63f05da3bfbd20e3d;hb=HEAD#l300 > > OK, this explains the behaviour. But what is the intention of this line? Way before my time, but I think it used to be possible to multiplex both the console and something else (remote gdb server?) over the serial line by differentiating on the top bit. Or possibly "Xen" vs "dom0" were multiplexed in this way. TBH I've not heard of anyone actually doing this and I have no idea what software is needed to support it on the other end. And I just found docs/misc/crashdb.txt, which seems to explain some of it. > Shouldn't this actually be something like > > if (handle & SERHND_HI) > { > c &= 0x7f; > } That sounds/looks rather plausible to me. This code has been as it was for more than a decade, which surely makes it a candidate for the oldest bug found so far! I think it would be appropriate for you to raise this on xen-devel. If you feel up to it then submitting it as a patch would best I think. http://wiki.xen.org/wiki/Submitting_Xen_Patches has some helpful guidance on that. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 09:45:40 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 09:45:40 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK1RA-0005Ml-F4; Tue, 28 Jul 2015 09:44:40 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK1R9-0005Me-1g for xen-users@lists.xen.org; Tue, 28 Jul 2015 09:44:39 +0000 Received: from [85.158.137.68] by server-3.bemta-3.messagelabs.com id E9/D3-01753-60F47B55; Tue, 28 Jul 2015 09:44:38 +0000 X-Env-Sender: prvs=644a1b3a5=Ian.Campbell@citrix.com X-Msg-Ref: server-4.tower-31.messagelabs.com!1438076672!28651067!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19403 invoked from network); 28 Jul 2015 09:44:33 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-4.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 09:44:33 -0000 X-IronPort-AV: E=Sophos;i="5.15,562,1432598400"; d="scan'208";a="288286407" Message-ID: <1438076670.11600.101.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" , Date: Tue, 28 Jul 2015 10:44:30 +0100 In-Reply-To: <55B65B46.5000805@rz-online.de> References: <55B65B46.5000805@rz-online.de> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Xen serial console has only 7 bit? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-27 at 18:24 +0200, Manfred Haertel, DB3HM wrote: > I tried to use the Xen serial console, as described in > http://wiki.xen.org/wiki/Xen_Serial_Console . I also used the resulting > xvc0 device as a console of the DOM0 Linux. > > Everything was working fine, and I could explore the features of the Xen > console. Almost everything... Finally I discovered, that when logging in > to Linux on the serial console, I could not use german umlauts. It > seemed as if the most significant bit was masked off during input. > > After a long search, what I was doing wrong I saw this line of code > inside the Xen serial driver: > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/drivers/char/serial > .c;h=c583a48c0823e7bf2619a1a63f05da3bfbd20e3d;hb=HEAD#l300 > > OK, this explains the behaviour. But what is the intention of this line? Way before my time, but I think it used to be possible to multiplex both the console and something else (remote gdb server?) over the serial line by differentiating on the top bit. Or possibly "Xen" vs "dom0" were multiplexed in this way. TBH I've not heard of anyone actually doing this and I have no idea what software is needed to support it on the other end. And I just found docs/misc/crashdb.txt, which seems to explain some of it. > Shouldn't this actually be something like > > if (handle & SERHND_HI) > { > c &= 0x7f; > } That sounds/looks rather plausible to me. This code has been as it was for more than a decade, which surely makes it a candidate for the oldest bug found so far! I think it would be appropriate for you to raise this on xen-devel. If you feel up to it then submitting it as a patch would best I think. http://wiki.xen.org/wiki/Submitting_Xen_Patches has some helpful guidance on that. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 14:56:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 14:56:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK6Ht-0004oW-Dl; Tue, 28 Jul 2015 14:55:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK6Hr-0004oI-QQ for xen-users@lists.xen.org; Tue, 28 Jul 2015 14:55:23 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id B5/55-31450-BD797B55; Tue, 28 Jul 2015 14:55:23 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1438095322!8467076!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5730 invoked from network); 28 Jul 2015 14:55:22 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-15.tower-206.messagelabs.com with SMTP; 28 Jul 2015 14:55:22 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 02A2C245466 for ; Tue, 28 Jul 2015 16:55:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbGf2QE4Y4rT for ; Tue, 28 Jul 2015 16:55:19 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id A623524543A for ; Tue, 28 Jul 2015 16:55:19 +0200 (CEST) To: xen-users@lists.xen.org From: Wolf Grossi X-Enigmail-Draft-Status: N1110 Message-ID: <55B797D2.6050708@magro-soft.com> Date: Tue, 28 Jul 2015 16:55:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Subject: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Greetings! There are several docs in the net describing how to passthru/attach a USB device to a PV guest. (e.g. http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) I tried them all but without success. I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. Does USB support even work in the above constellation? Any hints? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 14:56:28 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 14:56:28 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK6Ht-0004oW-Dl; Tue, 28 Jul 2015 14:55:25 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK6Hr-0004oI-QQ for xen-users@lists.xen.org; Tue, 28 Jul 2015 14:55:23 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id B5/55-31450-BD797B55; Tue, 28 Jul 2015 14:55:23 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1438095322!8467076!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5730 invoked from network); 28 Jul 2015 14:55:22 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-15.tower-206.messagelabs.com with SMTP; 28 Jul 2015 14:55:22 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 02A2C245466 for ; Tue, 28 Jul 2015 16:55:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JbGf2QE4Y4rT for ; Tue, 28 Jul 2015 16:55:19 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id A623524543A for ; Tue, 28 Jul 2015 16:55:19 +0200 (CEST) To: xen-users@lists.xen.org From: Wolf Grossi X-Enigmail-Draft-Status: N1110 Message-ID: <55B797D2.6050708@magro-soft.com> Date: Tue, 28 Jul 2015 16:55:14 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Subject: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Greetings! There are several docs in the net describing how to passthru/attach a USB device to a PV guest. (e.g. http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) I tried them all but without success. I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. Does USB support even work in the above constellation? Any hints? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 15:53:38 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 15:53:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK7B7-0002yq-Rh; Tue, 28 Jul 2015 15:52:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK7B6-0002yT-CH for xen-users@lists.xen.org; Tue, 28 Jul 2015 15:52:28 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 82/04-10678-B35A7B55; Tue, 28 Jul 2015 15:52:27 +0000 X-Env-Sender: zir_blazer@hotmail.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1438098745!29941281!1 X-Originating-IP: [65.55.90.106] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13854 invoked from network); 28 Jul 2015 15:52:26 -0000 Received: from snt004-omc2s31.hotmail.com (HELO SNT004-OMC2S31.hotmail.com) (65.55.90.106) by server-15.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 28 Jul 2015 15:52:26 -0000 Received: from SNT151-W55 ([65.55.90.71]) by SNT004-OMC2S31.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 28 Jul 2015 08:52:24 -0700 X-TMN: [7JgjVhTlHe7ZgdZABp7gd44ofjM40u9s] X-Originating-Email: [zir_blazer@hotmail.com] Message-ID: From: Zir Blazer To: Wolf Grossi , "xen-users@lists.xen.org" Date: Tue, 28 Jul 2015 12:52:24 -0300 Importance: Normal In-Reply-To: <55B797D2.6050708@magro-soft.com> References: <55B797D2.6050708@magro-soft.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2015 15:52:24.0769 (UTC) FILETIME=[65954310:01D0C94D] Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. http://xen.1045712.n5.nabble.com/Need-help-trying-to-use-SPICE-USB-Redirection-on-Xen-4-5-td5727045.html ---------------------------------------- > To: xen-users@lists.xen.org > From: wg@magro-soft.com > Date: Tue, 28 Jul 2015 16:55:14 +0200 > Subject: [Xen-users] PV Guest and USB > > Greetings! > > There are several docs in the net describing how to passthru/attach a > USB device to a PV guest. (e.g. > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) > > I tried them all but without success. > > > I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. > > Does USB support even work in the above constellation? > > Any hints? > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 15:53:38 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 15:53:38 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK7B7-0002yq-Rh; Tue, 28 Jul 2015 15:52:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK7B6-0002yT-CH for xen-users@lists.xen.org; Tue, 28 Jul 2015 15:52:28 +0000 Received: from [85.158.137.68] by server-9.bemta-3.messagelabs.com id 82/04-10678-B35A7B55; Tue, 28 Jul 2015 15:52:27 +0000 X-Env-Sender: zir_blazer@hotmail.com X-Msg-Ref: server-15.tower-31.messagelabs.com!1438098745!29941281!1 X-Originating-IP: [65.55.90.106] X-SpamReason: No, hits=0.1 required=7.0 tests=FORGED_HOTMAIL_RCVD X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13854 invoked from network); 28 Jul 2015 15:52:26 -0000 Received: from snt004-omc2s31.hotmail.com (HELO SNT004-OMC2S31.hotmail.com) (65.55.90.106) by server-15.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 28 Jul 2015 15:52:26 -0000 Received: from SNT151-W55 ([65.55.90.71]) by SNT004-OMC2S31.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 28 Jul 2015 08:52:24 -0700 X-TMN: [7JgjVhTlHe7ZgdZABp7gd44ofjM40u9s] X-Originating-Email: [zir_blazer@hotmail.com] Message-ID: From: Zir Blazer To: Wolf Grossi , "xen-users@lists.xen.org" Date: Tue, 28 Jul 2015 12:52:24 -0300 Importance: Normal In-Reply-To: <55B797D2.6050708@magro-soft.com> References: <55B797D2.6050708@magro-soft.com> MIME-Version: 1.0 X-OriginalArrivalTime: 28 Jul 2015 15:52:24.0769 (UTC) FILETIME=[65954310:01D0C94D] Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. http://xen.1045712.n5.nabble.com/Need-help-trying-to-use-SPICE-USB-Redirection-on-Xen-4-5-td5727045.html ---------------------------------------- > To: xen-users@lists.xen.org > From: wg@magro-soft.com > Date: Tue, 28 Jul 2015 16:55:14 +0200 > Subject: [Xen-users] PV Guest and USB > > Greetings! > > There are several docs in the net describing how to passthru/attach a > USB device to a PV guest. (e.g. > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) > > I tried them all but without success. > > > I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. > > Does USB support even work in the above constellation? > > Any hints? > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 18:10:52 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 18:10:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK9Jz-00008P-GA; Tue, 28 Jul 2015 18:09:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK66i-0003uL-8T for xen-users@lists.xen.org; Tue, 28 Jul 2015 14:43:52 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id C2/14-01469-72597B55; Tue, 28 Jul 2015 14:43:51 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1438094629!35961692!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9669 invoked from network); 28 Jul 2015 14:43:50 -0000 Received: from mail-ig0-f173.google.com (HELO mail-ig0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 14:43:50 -0000 Received: by igk11 with SMTP id 11so109589754igk.1 for ; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kFudjMUrUE0KzNJYm9HsMBg9pHJixk6pkchKJ1fV3HE=; b=xL8YgdWRaNEPO6Ay6oylSKhBotnqzb1RUJrk6QNF/CixBTbvJqqRtg4heUEzBR2S4A zvtAB82FOH+c9w7sftLDt1+UiOzSnKyJZ29zCEZy0pHu+/FcK6KikRn1nGoorgN0IGdt 633LBQ/nEzoWjfUFNw8PBaHwsdRWHzeleYxw/rs61YvhrOI8rpbxThOQLaSYtmd0W4RR KUV5vlbEohjpDHvIxLkmZw7yDuqorEC9j2SSIqO20LVpJz0LhXcxhWk4+C60gebHljbb 2bD5ApuZdeBbfGTYf3rj4zit77eBpuLATnf3ztxUtpwAeAWGfLSKXT+MGmcOKd82B2iU f2HA== MIME-Version: 1.0 X-Received: by 10.107.132.154 with SMTP id o26mr55153883ioi.3.1438094629400; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) Date: Tue, 28 Jul 2015 17:43:49 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 28 Jul 2015 18:09:46 +0000 Subject: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7692922693140849553==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7692922693140849553== Content-Type: multipart/alternative; boundary=001a113f278289f568051bf07f84 --001a113f278289f568051bf07f84 Content-Type: text/plain; charset=UTF-8 I have posted on minios-devel list, but I'll post here too, because of lack of responses. Basically what I'm trying to do is connect to the daytime server application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24. I can ping it just fine, I see it in ifconfig, it is bridged with xenbr0. More, If i create a Mini-OS Client, I can connect just fine to it, I just can't do it from eth0 (using netcat, or whatever socket layer API). Has anyone encountered this problem and is there a fix ? I just want to be able to communicate from Dom0 with the VM on TCP level. Mihai --001a113f278289f568051bf07f84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113f278289f568051bf07f84-- --===============7692922693140849553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7692922693140849553==-- From xen-users-bounces@lists.xen.org Tue Jul 28 18:10:52 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 18:10:52 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK9Jz-00008P-GA; Tue, 28 Jul 2015 18:09:47 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZK66i-0003uL-8T for xen-users@lists.xen.org; Tue, 28 Jul 2015 14:43:52 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id C2/14-01469-72597B55; Tue, 28 Jul 2015 14:43:51 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-8.tower-27.messagelabs.com!1438094629!35961692!1 X-Originating-IP: [209.85.213.173] X-SpamReason: No, hits=1.2 required=7.0 tests=HTML_20_30,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9669 invoked from network); 28 Jul 2015 14:43:50 -0000 Received: from mail-ig0-f173.google.com (HELO mail-ig0-f173.google.com) (209.85.213.173) by server-8.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 28 Jul 2015 14:43:50 -0000 Received: by igk11 with SMTP id 11so109589754igk.1 for ; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kFudjMUrUE0KzNJYm9HsMBg9pHJixk6pkchKJ1fV3HE=; b=xL8YgdWRaNEPO6Ay6oylSKhBotnqzb1RUJrk6QNF/CixBTbvJqqRtg4heUEzBR2S4A zvtAB82FOH+c9w7sftLDt1+UiOzSnKyJZ29zCEZy0pHu+/FcK6KikRn1nGoorgN0IGdt 633LBQ/nEzoWjfUFNw8PBaHwsdRWHzeleYxw/rs61YvhrOI8rpbxThOQLaSYtmd0W4RR KUV5vlbEohjpDHvIxLkmZw7yDuqorEC9j2SSIqO20LVpJz0LhXcxhWk4+C60gebHljbb 2bD5ApuZdeBbfGTYf3rj4zit77eBpuLATnf3ztxUtpwAeAWGfLSKXT+MGmcOKd82B2iU f2HA== MIME-Version: 1.0 X-Received: by 10.107.132.154 with SMTP id o26mr55153883ioi.3.1438094629400; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Tue, 28 Jul 2015 07:43:49 -0700 (PDT) Date: Tue, 28 Jul 2015 17:43:49 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: xen-users@lists.xen.org X-Mailman-Approved-At: Tue, 28 Jul 2015 18:09:46 +0000 Subject: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============7692922693140849553==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============7692922693140849553== Content-Type: multipart/alternative; boundary=001a113f278289f568051bf07f84 --001a113f278289f568051bf07f84 Content-Type: text/plain; charset=UTF-8 I have posted on minios-devel list, but I'll post here too, because of lack of responses. Basically what I'm trying to do is connect to the daytime server application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24. I can ping it just fine, I see it in ifconfig, it is bridged with xenbr0. More, If i create a Mini-OS Client, I can connect just fine to it, I just can't do it from eth0 (using netcat, or whatever socket layer API). Has anyone encountered this problem and is there a fix ? I just want to be able to communicate from Dom0 with the VM on TCP level. Mihai --001a113f278289f568051bf07f84 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113f278289f568051bf07f84-- --===============7692922693140849553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============7692922693140849553==-- From xen-users-bounces@lists.xen.org Tue Jul 28 19:03:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 19:03:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKA9S-00032F-5Q; Tue, 28 Jul 2015 19:02:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKA9Q-000324-IG for xen-users@lists.xen.org; Tue, 28 Jul 2015 19:02:56 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 51/7C-29123-FD1D7B55; Tue, 28 Jul 2015 19:02:55 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-3.tower-27.messagelabs.com!1438110174!35930250!1 X-Originating-IP: [212.7.160.41] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19834 invoked from network); 28 Jul 2015 19:02:55 -0000 Received: from mout01.rz-online.net (HELO mout01.rz-online.net) (212.7.160.41) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2015 19:02:55 -0000 Received: from donald.local (212-7-188-28.ktk-ip.de [212.7.188.28]) by mout01.rz-online.net (8.14.0/8.12.10) with ESMTP id t6SJ2r1g005618 for ; Tue, 28 Jul 2015 21:02:53 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id 3A6C1A0474 for ; Tue, 28 Jul 2015 21:02:44 +0200 (CEST) Message-ID: <55B7D1D3.7030200@rz-online.de> Date: Tue, 28 Jul 2015 21:02:43 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users References: In-Reply-To: Content-Length: 822 Subject: Re: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org P=EErvu Mihai schrieb: > Basically what I'm trying to do is connect to the daytime server > application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24 > . I can ping it just fine, I see it in ifconfig, it > is bridged with xenbr0. > > More, If i create a Mini-OS Client, I can connect just fine to it, I > just can't do it from eth0 (using netcat, or whatever socket layer API). Funny, I tried the same thing today (before reading your mail), with the = same results. So either we make the same mistake or daytime is broken in mini-os... -- = Manfred H=E4rtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Tue Jul 28 19:03:29 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Tue, 28 Jul 2015 19:03:29 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKA9S-00032F-5Q; Tue, 28 Jul 2015 19:02:58 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKA9Q-000324-IG for xen-users@lists.xen.org; Tue, 28 Jul 2015 19:02:56 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 51/7C-29123-FD1D7B55; Tue, 28 Jul 2015 19:02:55 +0000 X-Env-Sender: Manfred.Haertel@rz-online.de X-Msg-Ref: server-3.tower-27.messagelabs.com!1438110174!35930250!1 X-Originating-IP: [212.7.160.41] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19834 invoked from network); 28 Jul 2015 19:02:55 -0000 Received: from mout01.rz-online.net (HELO mout01.rz-online.net) (212.7.160.41) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Jul 2015 19:02:55 -0000 Received: from donald.local (212-7-188-28.ktk-ip.de [212.7.188.28]) by mout01.rz-online.net (8.14.0/8.12.10) with ESMTP id t6SJ2r1g005618 for ; Tue, 28 Jul 2015 21:02:53 +0200 Received: from [192.168.1.13] (work.donald.local [192.168.1.13]) by donald.local (Postfix) with ESMTP id 3A6C1A0474 for ; Tue, 28 Jul 2015 21:02:44 +0200 (CEST) Message-ID: <55B7D1D3.7030200@rz-online.de> Date: Tue, 28 Jul 2015 21:02:43 +0200 From: "Manfred Haertel, DB3HM" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Firefox/36.0 SeaMonkey/2.33.1 MIME-Version: 1.0 To: xen-users References: In-Reply-To: Content-Length: 822 Subject: Re: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org P=EErvu Mihai schrieb: > Basically what I'm trying to do is connect to the daytime server > application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24 > . I can ping it just fine, I see it in ifconfig, it > is bridged with xenbr0. > > More, If i create a Mini-OS Client, I can connect just fine to it, I > just can't do it from eth0 (using netcat, or whatever socket layer API). Funny, I tried the same thing today (before reading your mail), with the = same results. So either we make the same mistake or daytime is broken in mini-os... -- = Manfred H=E4rtel, DB3HM mailto:Manfred.Haertel@rz-online.de http://rz-home.de/mhaertel _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 04:08:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 04:08:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIe0-0000TR-Ku; Wed, 29 Jul 2015 04:07:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIdy-0000Sv-Gt; Wed, 29 Jul 2015 04:07:02 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 9A/57-00475-56158B55; Wed, 29 Jul 2015 04:07:01 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1438142820!36082770!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26362 invoked from network); 29 Jul 2015 04:07:00 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 04:07:00 -0000 Received: by wicgb10 with SMTP id gb10so182129043wic.1; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0CwZO5LHNb2jHZ0urb7MMfRTul/JcdSHB31rWdHceUk=; b=AwQuH4pv3puR1W275c4DGfAyg8SaXcxwcOci3gbqZfh98Vr7l4f/o4+3rH2IeMSbsp DFJXvn92mdr9YJpwdlI+VdgxL1u2LYvnsAnTH/GRVy1lPvXwfXkrInPeAzSijH1xLPtu GTCFwWWNmNpd3vgLawSU6d6rgLkN2d1skSp2hqSt5XvLyCh1egpA+V8FYeCq6klTKuZ/ IlLcfBMxFYPQbHqh7+1Z9oc+hZKGkte0W4vqdbmCTR51J7nomNV76IOT1uOM0HbMLvdv Pvi8FsllaZ93mloHtsGiI4qUdeiNYT5wbil0q5hVv2FTHhUM00jZ9px9BoVo3677u59/ IsnA== MIME-Version: 1.0 X-Received: by 10.181.12.20 with SMTP id em20mr1731884wid.28.1438142819118; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 00:06:59 -0400 X-Google-Sender-Auth: qPaVX-Ni8ZfC0IaKYVfwr-84lq4 Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: xen-api@lists.xen.org, xen-devel , xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Xen Project Document Day is here! Join us as we seek to make our Wiki more accurate and useful! On Mon, Jul 27, 2015 at 11:52 PM, Russ Pavlicek wrote: > Our next Xen Project Document Day is this Wednesday, July 29! > > Our THEME OF THE MONTH: "The Reverse Yard Sale" > > For many of us in the northern hemisphere, this is the time of year > when people sort through the things they own and put the things they > no longer need into a yard sale. Well, instead of removing things we > don't need, we want a reverse yard sale, where we add the things we > *do* need. Some topics to address include: > > - Hyper: the new hypervisor-independent Docker engine which uses Xen > Project (among other hypervisors); we need a basic document on how to > use Xen Project with Hyper > - XAPI: The latest docs from the XenServer crew need to be referenced > from our wiki > - Unikernels: Lots of Unikernels leverage Xen Project; we need them > properly linked in to our wiki > - Booting with UEFI: needs to be made current > - Raisin: the new effort has a new wiki page which needs review > - and anything else which needs to be added > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > Also take a look at the current TODO list to see other items which > need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 04:08:02 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 04:08:02 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIe0-0000TR-Ku; Wed, 29 Jul 2015 04:07:04 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKIdy-0000Sv-Gt; Wed, 29 Jul 2015 04:07:02 +0000 Received: from [193.109.254.147] by server-5.bemta-14.messagelabs.com id 9A/57-00475-56158B55; Wed, 29 Jul 2015 04:07:01 +0000 X-Env-Sender: russell.pavlicek.xen@gmail.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1438142820!36082770!1 X-Originating-IP: [209.85.212.182] X-SpamReason: No, hits=2.1 required=7.0 tests=RCVD_BY_IP, SUSPICIOUS_RECIPS X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26362 invoked from network); 29 Jul 2015 04:07:00 -0000 Received: from mail-wi0-f182.google.com (HELO mail-wi0-f182.google.com) (209.85.212.182) by server-6.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 04:07:00 -0000 Received: by wicgb10 with SMTP id gb10so182129043wic.1; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=0CwZO5LHNb2jHZ0urb7MMfRTul/JcdSHB31rWdHceUk=; b=AwQuH4pv3puR1W275c4DGfAyg8SaXcxwcOci3gbqZfh98Vr7l4f/o4+3rH2IeMSbsp DFJXvn92mdr9YJpwdlI+VdgxL1u2LYvnsAnTH/GRVy1lPvXwfXkrInPeAzSijH1xLPtu GTCFwWWNmNpd3vgLawSU6d6rgLkN2d1skSp2hqSt5XvLyCh1egpA+V8FYeCq6klTKuZ/ IlLcfBMxFYPQbHqh7+1Z9oc+hZKGkte0W4vqdbmCTR51J7nomNV76IOT1uOM0HbMLvdv Pvi8FsllaZ93mloHtsGiI4qUdeiNYT5wbil0q5hVv2FTHhUM00jZ9px9BoVo3677u59/ IsnA== MIME-Version: 1.0 X-Received: by 10.181.12.20 with SMTP id em20mr1731884wid.28.1438142819118; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) Received: by 10.194.81.99 with HTTP; Tue, 28 Jul 2015 21:06:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 29 Jul 2015 00:06:59 -0400 X-Google-Sender-Auth: qPaVX-Ni8ZfC0IaKYVfwr-84lq4 Message-ID: From: Russ Pavlicek To: Russ Pavlicek Cc: xen-api@lists.xen.org, xen-devel , xs-devel@lists.xenserver.org, mirageos-devel@lists.xenproject.org, "xen-users@lists.xen.org" Subject: Re: [Xen-users] Xen Project Document Day is this Wednesday July 29 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Xen Project Document Day is here! Join us as we seek to make our Wiki more accurate and useful! On Mon, Jul 27, 2015 at 11:52 PM, Russ Pavlicek wrote: > Our next Xen Project Document Day is this Wednesday, July 29! > > Our THEME OF THE MONTH: "The Reverse Yard Sale" > > For many of us in the northern hemisphere, this is the time of year > when people sort through the things they own and put the things they > no longer need into a yard sale. Well, instead of removing things we > don't need, we want a reverse yard sale, where we add the things we > *do* need. Some topics to address include: > > - Hyper: the new hypervisor-independent Docker engine which uses Xen > Project (among other hypervisors); we need a basic document on how to > use Xen Project with Hyper > - XAPI: The latest docs from the XenServer crew need to be referenced > from our wiki > - Unikernels: Lots of Unikernels leverage Xen Project; we need them > properly linked in to our wiki > - Booting with UEFI: needs to be made current > - Raisin: the new effort has a new wiki page which needs review > - and anything else which needs to be added > > All the information you need to participate in Document Day is here: > > http://wiki.xenproject.org/wiki/Xen_Document_Days > > Also take a look at the current TODO list to see other items which > need attention: > > http://wiki.xenproject.org/wiki/Xen_Document_Days/TODO > > Please think about how you can help out. If you haven't requested > to be made a Wiki editor, save time and do it now so you are ready to > go on Document Day. Just fill out the form below: > > http://xenproject.org/component/content/article/100-misc/145-request-to-be-made-a-wiki-editor.html > > We hope to see you Wednesday in #xendocs! _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 08:48:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 08:48:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKN12-0005gg-HA; Wed, 29 Jul 2015 08:47:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKN10-0005gb-PG for xen-users@lists.xen.org; Wed, 29 Jul 2015 08:47:06 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 10/FA-16965-A0398B55; Wed, 29 Jul 2015 08:47:06 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438159616!30245658!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19888 invoked from network); 29 Jul 2015 08:47:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 08:47:05 -0000 X-IronPort-AV: E=Sophos;i="5.15,569,1432598400"; d="scan'208";a="288764142" Message-ID: <1438159613.11600.171.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" , xen-users Date: Wed, 29 Jul 2015 09:46:53 +0100 In-Reply-To: <55B7D1D3.7030200@rz-online.de> References: <55B7D1D3.7030200@rz-online.de> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Minios-devel@lists.xenproject.org Subject: Re: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gVHVlLCAyMDE1LTA3LTI4IGF0IDIxOjAyICswMjAwLCBNYW5mcmVkIEhhZXJ0ZWwsIERCM0hN IHdyb3RlOgoKSSdtIGNyb3NzIHBvc3RpbmcgdG8gbWluaW9zLWRldmVsIHRvbywganVzdCB0byBr ZWVwIHRoZW0gaW4gdGhlIGxvb3AuCgo+IFDDrnJ2dSBNaWhhaSBzY2hyaWViOgo+IAo+ID4gQmFz aWNhbGx5IHdoYXQgSSdtIHRyeWluZyB0byBkbyBpcyBjb25uZWN0IHRvIHRoZSBkYXl0aW1lIHNl cnZlcgo+ID4gYXBwbGljYXRpb24gbWluaS1vcyBwcm92ZGVzIGZyb20gRG9tMC4gVGhlIElQIGkg c2V0IGlzIDEwLjAuMi4xMC8yNAo+ID4gPGh0dHA6Ly8xMC4wLjIuMTAvMjQ+LiBJIGNhbiBwaW5n IGl0IGp1c3QgZmluZSwgSSBzZWUgaXQgaW4gaWZjb25maWcsIAo+ID4gaXQKPiA+IGlzIGJyaWRn ZWQgd2l0aCB4ZW5icjAuCj4gPiAKPiA+IE1vcmUsIElmIGkgY3JlYXRlIGEgTWluaS1PUyBDbGll bnQsIEkgY2FuIGNvbm5lY3QganVzdCBmaW5lIHRvIGl0LCBJCj4gPiBqdXN0IGNhbid0IGRvIGl0 IGZyb20gZXRoMCAodXNpbmcgbmV0Y2F0LCBvciB3aGF0ZXZlciBzb2NrZXQgbGF5ZXIgCj4gPiBB UEkpLgo+IAo+IEZ1bm55LCBJIHRyaWVkIHRoZSBzYW1lIHRoaW5nIHRvZGF5IChiZWZvcmUgcmVh ZGluZyB5b3VyIG1haWwpLCB3aXRoIHRoZSAKPiBzYW1lIHJlc3VsdHMuCj4gCj4gU28gZWl0aGVy IHdlIG1ha2UgdGhlIHNhbWUgbWlzdGFrZSBvciBkYXl0aW1lIGlzIGJyb2tlbiBpbiBtaW5pLW9z Li4uCgpWZXJ5IGZldyBvZiB0aGUgaW4tdHJlZSBzdHViZG9tcyB1c2UgbmV0d29ya2luZyAob25s eSBwdmdydWIgbWlnaHQsIGJ1dCBJCmJldCBpdCBpc24ndCBjb21tb25seSB1c2VkIHRoYXQgd2F5 LCBzaW5jZSBub3JtYWxseSBwZW9wbGUgYm9vdCBvZiBkaXNrIG5vdApuZXR3b3JrKSBhbmQgSSdt IHByZXR0eSBjZXJ0YWluIHRoYXQgbm9uZSBvZiB0aGVtIHVzZSBkYXl0aW1lIHNwZWNpZmljYWxs eSwKc28gaWYgdGhpcyBldmVyIHdvcmtlZCBJJ2Qgbm90IGJlIHRvbyBzdXJwcmlzZWQgaWYgaXQg aGFkIHJlZ3Jlc3NlZCBhdCBzb21lCnBvaW50IG92ZXIgdGhlIHllYXJzLgoKUGxlYXNlIGNhbiBv bmUgb3IgYm90aCBvZiB5b3UgcHJvdmlkZSBzb21lIGRldGFpbHMgb2YgZXhhY3RseSB3aGF0IHlv dSd2ZQpkb25lL2FyZSBzZWVpbmcsIHNvOgoKICAgICAgKiBXaGljaCBzdHViZG9tIHRhcmdldCB5 b3UgaGF2ZSBidWlsdCwgd2hpY2ggY29uZmlndXJhdGlvbiBpdCBpcwogICAgICAgIHVzaW5nLCB3 aGljaCBiaW5hcnkgeW91IGFyZSBsb2FkaW5nCiAgICAgICogVGhlIGd1ZXN0IENGRyBmaWxlCiAg ICAgICogVGhlIGd1ZXN0IGNvbnNvbGUgbG9nCiAgICAgICogTG9ncyBmcm9tIHRoZSBjcmVhdGlv biBvZiB0aGUgZ3Vlc3QKICAgICAgKiBicmN0bCwgaWZjb25maWcgZXRjIGZyb20gZG9tMC4KICAg ICAgKiBEZXRhaWxzIG9mIHdoYXQgY29tbWFuZHMgcnVuIGluIGRvbTAgYXJlbid0IHdvcmtpbmcu CgpNYXliZSBzb21ldGhpbmcgaW4gdGhlcmUgd2lsbCBnaXZlIHVzIGEgaGludCB3aGVyZSB0byBs b29rIG5leHQuCgpJYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0 cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Wed Jul 29 08:48:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 08:48:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKN12-0005gg-HA; Wed, 29 Jul 2015 08:47:08 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKN10-0005gb-PG for xen-users@lists.xen.org; Wed, 29 Jul 2015 08:47:06 +0000 Received: from [85.158.137.68] by server-7.bemta-3.messagelabs.com id 10/FA-16965-A0398B55; Wed, 29 Jul 2015 08:47:06 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438159616!30245658!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 19888 invoked from network); 29 Jul 2015 08:47:05 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 08:47:05 -0000 X-IronPort-AV: E=Sophos;i="5.15,569,1432598400"; d="scan'208";a="288764142" Message-ID: <1438159613.11600.171.camel@citrix.com> From: Ian Campbell To: "Manfred Haertel, DB3HM" , xen-users Date: Wed, 29 Jul 2015 09:46:53 +0100 In-Reply-To: <55B7D1D3.7030200@rz-online.de> References: <55B7D1D3.7030200@rz-online.de> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Minios-devel@lists.xenproject.org Subject: Re: [Xen-users] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gVHVlLCAyMDE1LTA3LTI4IGF0IDIxOjAyICswMjAwLCBNYW5mcmVkIEhhZXJ0ZWwsIERCM0hN IHdyb3RlOgoKSSdtIGNyb3NzIHBvc3RpbmcgdG8gbWluaW9zLWRldmVsIHRvbywganVzdCB0byBr ZWVwIHRoZW0gaW4gdGhlIGxvb3AuCgo+IFDDrnJ2dSBNaWhhaSBzY2hyaWViOgo+IAo+ID4gQmFz aWNhbGx5IHdoYXQgSSdtIHRyeWluZyB0byBkbyBpcyBjb25uZWN0IHRvIHRoZSBkYXl0aW1lIHNl cnZlcgo+ID4gYXBwbGljYXRpb24gbWluaS1vcyBwcm92ZGVzIGZyb20gRG9tMC4gVGhlIElQIGkg c2V0IGlzIDEwLjAuMi4xMC8yNAo+ID4gPGh0dHA6Ly8xMC4wLjIuMTAvMjQ+LiBJIGNhbiBwaW5n IGl0IGp1c3QgZmluZSwgSSBzZWUgaXQgaW4gaWZjb25maWcsIAo+ID4gaXQKPiA+IGlzIGJyaWRn ZWQgd2l0aCB4ZW5icjAuCj4gPiAKPiA+IE1vcmUsIElmIGkgY3JlYXRlIGEgTWluaS1PUyBDbGll bnQsIEkgY2FuIGNvbm5lY3QganVzdCBmaW5lIHRvIGl0LCBJCj4gPiBqdXN0IGNhbid0IGRvIGl0 IGZyb20gZXRoMCAodXNpbmcgbmV0Y2F0LCBvciB3aGF0ZXZlciBzb2NrZXQgbGF5ZXIgCj4gPiBB UEkpLgo+IAo+IEZ1bm55LCBJIHRyaWVkIHRoZSBzYW1lIHRoaW5nIHRvZGF5IChiZWZvcmUgcmVh ZGluZyB5b3VyIG1haWwpLCB3aXRoIHRoZSAKPiBzYW1lIHJlc3VsdHMuCj4gCj4gU28gZWl0aGVy IHdlIG1ha2UgdGhlIHNhbWUgbWlzdGFrZSBvciBkYXl0aW1lIGlzIGJyb2tlbiBpbiBtaW5pLW9z Li4uCgpWZXJ5IGZldyBvZiB0aGUgaW4tdHJlZSBzdHViZG9tcyB1c2UgbmV0d29ya2luZyAob25s eSBwdmdydWIgbWlnaHQsIGJ1dCBJCmJldCBpdCBpc24ndCBjb21tb25seSB1c2VkIHRoYXQgd2F5 LCBzaW5jZSBub3JtYWxseSBwZW9wbGUgYm9vdCBvZiBkaXNrIG5vdApuZXR3b3JrKSBhbmQgSSdt IHByZXR0eSBjZXJ0YWluIHRoYXQgbm9uZSBvZiB0aGVtIHVzZSBkYXl0aW1lIHNwZWNpZmljYWxs eSwKc28gaWYgdGhpcyBldmVyIHdvcmtlZCBJJ2Qgbm90IGJlIHRvbyBzdXJwcmlzZWQgaWYgaXQg aGFkIHJlZ3Jlc3NlZCBhdCBzb21lCnBvaW50IG92ZXIgdGhlIHllYXJzLgoKUGxlYXNlIGNhbiBv bmUgb3IgYm90aCBvZiB5b3UgcHJvdmlkZSBzb21lIGRldGFpbHMgb2YgZXhhY3RseSB3aGF0IHlv dSd2ZQpkb25lL2FyZSBzZWVpbmcsIHNvOgoKICAgICAgKiBXaGljaCBzdHViZG9tIHRhcmdldCB5 b3UgaGF2ZSBidWlsdCwgd2hpY2ggY29uZmlndXJhdGlvbiBpdCBpcwogICAgICAgIHVzaW5nLCB3 aGljaCBiaW5hcnkgeW91IGFyZSBsb2FkaW5nCiAgICAgICogVGhlIGd1ZXN0IENGRyBmaWxlCiAg ICAgICogVGhlIGd1ZXN0IGNvbnNvbGUgbG9nCiAgICAgICogTG9ncyBmcm9tIHRoZSBjcmVhdGlv biBvZiB0aGUgZ3Vlc3QKICAgICAgKiBicmN0bCwgaWZjb25maWcgZXRjIGZyb20gZG9tMC4KICAg ICAgKiBEZXRhaWxzIG9mIHdoYXQgY29tbWFuZHMgcnVuIGluIGRvbTAgYXJlbid0IHdvcmtpbmcu CgpNYXliZSBzb21ldGhpbmcgaW4gdGhlcmUgd2lsbCBnaXZlIHVzIGEgaGludCB3aGVyZSB0byBs b29rIG5leHQuCgpJYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0 cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Wed Jul 29 11:21:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 11:21:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPPk-0000Ac-Qb; Wed, 29 Jul 2015 11:20:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKOYv-0003cW-Vd for xen-users@lists.xen.org; Wed, 29 Jul 2015 10:26:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 74/67-06021-54AA8B55; Wed, 29 Jul 2015 10:26:13 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438165568!30290199!1 X-Originating-IP: [209.85.213.182] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7497 invoked from network); 29 Jul 2015 10:26:09 -0000 Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com) (209.85.213.182) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 10:26:09 -0000 Received: by iggf3 with SMTP id f3so9351913igg.1 for ; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IV/7IkLx5bTwX7qra6vg3mveG5C0nxzp8xVX4m8oTcA=; b=n6KUNR6PYiCVrLJdO7AHzcgmBaWES2/hycZsRmdvqhk7NrdL23t07FzfWOsaqeg4uM gFdy+/AyZ08M8QYDn+1ynifg7MWWVrUsmpktmN1AMTYCVcqnKlN+neOsDts/a391pkZE VaN8PEGAktRFjg8pe4pX0dtwF2DxvjV7dbkIR/SkWk0FVrCdDwQOt4soP5cSHRkzpW4z 7wKuUy3yPYr98thxZT2Iroa+elU/uYIJIiCy54A4b4MbYRCPbN1LjQwuspyyni/A6lc+ SOPAbF5TQHmCPuBcTm09YzbhqAqJN2z0wEEAc9MdABkFPuNslPYHfhAoWTxVe6Dkih2i ddqQ== MIME-Version: 1.0 X-Received: by 10.50.67.2 with SMTP id j2mr289865igt.79.1438165568470; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) In-Reply-To: <1438159613.11600.171.camel@citrix.com> References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> Date: Wed, 29 Jul 2015 13:26:08 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: Ian Campbell X-Mailman-Approved-At: Wed, 29 Jul 2015 11:20:47 +0000 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3647586262447138573==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3647586262447138573== Content-Type: multipart/alternative; boundary=047d7bdc1004d64658051c0103d0 --047d7bdc1004d64658051c0103d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alright, here it is, hope we can sort this out: 1. I'm simply compiling Mini-OS from xen/extras/mini-os directory with LWIP support as stated in the README: export LWIPDIR=3D/home/mihai/lwip-1.3.2 and make. It creates this binary: http://pastebin.com/xyyg6P03 I'm not using any stubdom, so I guess the default one is used If I have informed myself good about this. 2. Guest CFG file is : http://pastebin.com/VbkVq6vV and that's it. 3. This is the guest console log: http://pastebin.com/m1AYtJB8 4. This is log from creation of the guest: http://pastebin.com/a8kfu5Fw 5. Here's brctl and ifconfig from dom0: http://pastebin.com/vAvupgLz 6. Alright, here's all the things I've tried so far: 6a) Firstly I though that since eth0 and vifX.0 are bridged, you should be able to netcat to the VM. The pings works fine: This is the mini-so provided daytime which I'm running. The only difference is that I set the IP to 10.0.2.10/24: http://pastebin.com/UURCj36d Here's where I try to ping (works) and netcat (hangs): http://pastebin.com/zHtS01Tg Here's ltrace and strace of netcat, to see what happens: http://pastebin.com/K9vXF5dX It's pretty verbose, but if you look at the last lines, you can see that connect returns EINPROGRESS. 6b) Going further, I created another VM which basically connects to 10.0.2.10/24. This is the code: http://pastebin.com/w9LCmguH Similary to above, here's the verbose creation output: http://pastebin.com/KUKmisRs Here's the console of "Client-OS": http://pastebin.com/bQQS9K9p We can see that IT WORKS, it connects to the IP just fine. So what's happening here? Here's ifconfig and brctl: http://pastebin.com/VwfXCeUu We can see that the interfaces vif5.0 and vif7.0 are bridged together, which makes sense. I get the daytime output from "Server-OS" to "Client-OS", then the "client" thread exits just fine. It works good. 6c) Obviously, I tried to make the same "experiment" using a lwip client, thinking that I need to connect using LWIP API to a LWIP server (which is wrong, I proved this later, I can connect just find using linux sockets to a LWIP server). What I have done at this step is using the netconn API to create a Linux client that connects to 10.0.2.10 and outputs the received daytime value.I have looked up and found out about lwip unix ports and that there is a shared library which I can link with my linux application. Here's the application code: http://pastebin.com/EnfYnzEC Makefile: http://pastebin.com/i5y4cnMd Here's the ifconfig/brctl: http://pastebin.com/QJakkJj6 Tap0 is bridged in xenbr0. How I did this (it's not provided by defualt): https://groups.google.com/forum/#!topic/osdeve_mirror_tcpip_lwip/yQcb1YmeP5= 4 See third answer. Basically I edited contrib/ports/unix/netif/tapif.c which is used in compiling the liblwip.so library so firstly it adds the tap0 linux interface to xenbr0 before tries to connect to 10.0.2.10/24. Here's the ltrace when running the application (SUPER VERBOSE, probably becuase I have to use root permissions to run this due to the creation of the linux interface which requires special permissions): http://pastebin.com/4vG4QMfi It hangs like netcat. 6d) Moving on, I tried to build the daytime application as a linux application (testing purposes, my target is to create a VM that accepts TCP connections from Linux/win32/whatever platform clients). I have used the same liblwip.so library, and I have compiled an application on my Linux PC. For simplicity, I have added my code to the already provided "simhost" application (which is a ping/telnet/http server application for lwip on linux). I compile that and it works just fine, I can even connect with netcat 10.0.0.2 13 (the default IP the application binds on) and it prints the daytime output. Thus I have concluded that you can connect with regular socket application to a LWIP server if it's configured properly. PS: This application comes in the "contrib-1.3.2" archive from LWIP site at ports/unix/proj/lib (for the shared library) and ports/unix/proj/simhost (for the http server/telnet/ping answerer). Sorry for the extremly long mail, but I wanted to show you all the things I've done so maybe you understand where I've gone wrong and what I should've done better. Tell me if you need additional info. Mihai On Wed, Jul 29, 2015 at 11:46 AM, Ian Campbell wrote: > On Tue, 2015-07-28 at 21:02 +0200, Manfred Haertel, DB3HM wrote: > > I'm cross posting to minios-devel too, just to keep them in the loop. > > > P=C3=AErvu Mihai schrieb: > > > > > Basically what I'm trying to do is connect to the daytime server > > > application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24 > > > . I can ping it just fine, I see it in ifconfig, > > > it > > > is bridged with xenbr0. > > > > > > More, If i create a Mini-OS Client, I can connect just fine to it, I > > > just can't do it from eth0 (using netcat, or whatever socket layer > > > API). > > > > Funny, I tried the same thing today (before reading your mail), with th= e > > same results. > > > > So either we make the same mistake or daytime is broken in mini-os... > > Very few of the in-tree stubdoms use networking (only pvgrub might, but I > bet it isn't commonly used that way, since normally people boot of disk n= ot > network) and I'm pretty certain that none of them use daytime specificall= y, > so if this ever worked I'd not be too surprised if it had regressed at so= me > point over the years. > > Please can one or both of you provide some details of exactly what you've > done/are seeing, so: > > * Which stubdom target you have built, which configuration it is > using, which binary you are loading > * The guest CFG file > * The guest console log > * Logs from the creation of the guest > * brctl, ifconfig etc from dom0. > * Details of what commands run in dom0 aren't working. > > Maybe something in there will give us a hint where to look next. > > Ian > > _______________________________________________ > Minios-devel mailing list > Minios-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel --047d7bdc1004d64658051c0103d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright, here it is, hope we can sort this out:

=C2=A0 I'm not= using any stubdom, so I guess the default one is used If I have informed m= yself good about this.

2. Guest CFG file is : =C2= =A0http://pastebin.com/VbkVq6vV and that's it.


4. This is log from creation of the guest= : http://pastebin.com/a8kfu5Fw=

5. Here's brctl and ifconfig from dom0:=C2=A0= http://pastebin.com/vAvupgLz

6. Alright, here's all the things I've trie= d so far:

6a) Firstly I though that since eth0 and= vifX.0 are bridged, you should be able to netcat to the VM. The pings work= s fine:=C2=A0
=C2=A0 This is the mini-so provided daytime which I= 'm running. The only difference is that I set the IP to 10.0.2.10/24: http://pastebin.com/UURCj36d
=C2=A0=C2=A0
=C2=A0 H= ere's where I try to ping (works) and netcat (hangs): http://pastebin.com/zHtS01Tg
=C2=A0 H= ere's ltrace and strace of netcat, to see what happens: =C2=A0http://pastebin.com/K9vXF5dX
=C2=A0 It's pretty verbose, but if you look at the last lines, you ca= n see that connect returns EINPROGRESS.

6b) Going = further, I created another VM which basically connects to 10.0.2.10/24. This is the code: http://pastebin.com/w9LCmguH
Similary to abo= ve, here's the verbose creation output: http://pastebin.com/KUKmisRs
Here's the console= of "Client-OS": http://= pastebin.com/bQQS9K9p
We can see that IT WORKS, it connects t= o the IP just fine. So what's happening here?

= Here's ifconfig and brctl: htt= p://pastebin.com/VwfXCeUu
We can see that the interfaces vif5= .0 and vif7.0 are bridged together, which makes sense. I get the daytime ou= tput from "Server-OS" to "Client-OS", then the "cl= ient" thread exits just fine. It works good.

= 6c) Obviously, I tried to make the same "experiment" using a lwip= client, thinking that I need to connect using LWIP API to a LWIP server (w= hich is wrong, I proved this later, I can connect just find using linux soc= kets to a LWIP server).

What I have done at this s= tep is using the netconn =C2=A0API to create a Linux client that connects t= o 10.0.2.10 and outputs the received daytime value.I have looked up and fou= nd out about lwip unix ports and that there is a shared library which I can= link with my linux application.

Here's the ap= plication code:=C2=A0http://pasteb= in.com/EnfYnzEC
Here's the ifconf= ig/brctl:=C2=A0http://pastebin.com= /QJakkJj6

Tap0 is bridged in xenbr0. How I did= this (it's not provided by defualt):=C2=A0https://groups= .google.com/forum/#!topic/osdeve_mirror_tcpip_lwip/yQcb1YmeP54

See third answer. Basically I edited=C2=A0=C2=A0contrib/ports/u= nix/netif/tapif.c which is used in compiling the liblwip.so library so fi= rstly it adds the tap0 linux interface to xenbr0 before tries to connect to= 10.0.2.10/24.=C2=A0
<= span style=3D"font-size:13px;font-family:Arial,Helvetica,sans-serif">
Here's the ltrace when running the application (SUPER VERBOS= E, probably becuase I have to use root permissions to run this due to the c= reation of the linux interface which requires special permissions):=C2=A0http://pastebin.com/4vG4QMfi

It hangs like netcat.

6d) Moving on, I tried= to build the daytime application as a linux application (testing purposes,= my target is to create a VM that accepts TCP connections from Linux/win32/= whatever platform clients). I have used the same liblwip.so library, and I = have compiled an application on my Linux PC. For simplicity, I have added m= y code to the already provided "simhost" application (which is a = ping/telnet/http server application for lwip on linux). I compile that and = it works just fine, I can even connect with netcat 10.0.0.2 13 (the default= IP the application binds on) and it prints the daytime output. Thus I have= concluded that you can connect with regular socket application to a LWIP s= erver if it's configured properly.=C2=A0

PS: This application comes in the "contrib-1.3.2" archive from L= WIP site at ports/unix/proj/lib (for the shared library) and ports/unix/pro= j/simhost (for the http server/telnet/ping answerer).

=C2=A0=C2=A0

Sorry for the extremly= long mail, but I wanted to show you all the things I've done so maybe = you understand where I've gone wrong and what I should've done bett= er.=C2=A0 Tell me if you need additional info.

Mihai

On Wed, Jul 29, 2015 at 11:46 AM, Ian Campbell <ian.camp= bell@citrix.com> wrote:
On = Tue, 2015-07-28 at 21:02 +0200, Manfred Haertel, DB3HM wrote:

I'm cross posting to minios-devel too, just to keep them in the loop.
> P=C3=AErvu Mihai schrieb:
>
> > Basically what I'm trying to do is connect to the daytime ser= ver
> > application mini-os provdes from Dom0. The IP i set is 10.0.2.10= /24
> > <http://10.0.2.10/24>. I can ping it just fine, I see it in i= fconfig,
> > it
> > is bridged with xenbr0.
> >
> > More, If i create a Mini-OS Client, I can connect just fine to it= , I
> > just can't do it from eth0 (using netcat, or whatever socket = layer
> > API).
>
> Funny, I tried the same thing today (before re= ading your mail), with the
> same results.
>
> So either we make the same mistake or daytime is broken in mini-os...<= br>
Very few of the in-tree stubdoms use networking (only pvgrub might, = but I
bet it isn't commonly used that way, since normally people boot of disk= not
network) and I'm pretty certain that none of them use daytime specifica= lly,
so if this ever worked I'd not be too surprised if it had regressed at = some
point over the years.

Please can one or both of you provide some details of exactly what you'= ve
done/are seeing, so:

=C2=A0 =C2=A0 =C2=A0 * Which stubdom target you have built, which configura= tion it is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using, which binary you are loading
=C2=A0 =C2=A0 =C2=A0 * The guest CFG file
=C2=A0 =C2=A0 =C2=A0 * The guest console log
=C2=A0 =C2=A0 =C2=A0 * Logs from the creation of the guest
=C2=A0 =C2=A0 =C2=A0 * brctl, ifconfig etc from dom0.
=C2=A0 =C2=A0 =C2=A0 * Details of what commands run in dom0 aren't work= ing.

Maybe something in there will give us a hint where to look next.

Ian

_______________________________________________
Minios-devel mailing list
Minios-devel@lists.xen= project.org
http://lists.xenproject.org/cgi-bin= /mailman/listinfo/minios-devel

--047d7bdc1004d64658051c0103d0-- --===============3647586262447138573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3647586262447138573==-- From xen-users-bounces@lists.xen.org Wed Jul 29 11:21:48 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 11:21:48 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPPk-0000Ac-Qb; Wed, 29 Jul 2015 11:20:48 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKOYv-0003cW-Vd for xen-users@lists.xen.org; Wed, 29 Jul 2015 10:26:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id 74/67-06021-54AA8B55; Wed, 29 Jul 2015 10:26:13 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438165568!30290199!1 X-Originating-IP: [209.85.213.182] X-SpamReason: No, hits=0.9 required=7.0 tests=BODY_RANDOM_LONG, HTML_30_40,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7497 invoked from network); 29 Jul 2015 10:26:09 -0000 Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com) (209.85.213.182) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 10:26:09 -0000 Received: by iggf3 with SMTP id f3so9351913igg.1 for ; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IV/7IkLx5bTwX7qra6vg3mveG5C0nxzp8xVX4m8oTcA=; b=n6KUNR6PYiCVrLJdO7AHzcgmBaWES2/hycZsRmdvqhk7NrdL23t07FzfWOsaqeg4uM gFdy+/AyZ08M8QYDn+1ynifg7MWWVrUsmpktmN1AMTYCVcqnKlN+neOsDts/a391pkZE VaN8PEGAktRFjg8pe4pX0dtwF2DxvjV7dbkIR/SkWk0FVrCdDwQOt4soP5cSHRkzpW4z 7wKuUy3yPYr98thxZT2Iroa+elU/uYIJIiCy54A4b4MbYRCPbN1LjQwuspyyni/A6lc+ SOPAbF5TQHmCPuBcTm09YzbhqAqJN2z0wEEAc9MdABkFPuNslPYHfhAoWTxVe6Dkih2i ddqQ== MIME-Version: 1.0 X-Received: by 10.50.67.2 with SMTP id j2mr289865igt.79.1438165568470; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Wed, 29 Jul 2015 03:26:08 -0700 (PDT) In-Reply-To: <1438159613.11600.171.camel@citrix.com> References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> Date: Wed, 29 Jul 2015 13:26:08 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: Ian Campbell X-Mailman-Approved-At: Wed, 29 Jul 2015 11:20:47 +0000 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============3647586262447138573==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============3647586262447138573== Content-Type: multipart/alternative; boundary=047d7bdc1004d64658051c0103d0 --047d7bdc1004d64658051c0103d0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alright, here it is, hope we can sort this out: 1. I'm simply compiling Mini-OS from xen/extras/mini-os directory with LWIP support as stated in the README: export LWIPDIR=3D/home/mihai/lwip-1.3.2 and make. It creates this binary: http://pastebin.com/xyyg6P03 I'm not using any stubdom, so I guess the default one is used If I have informed myself good about this. 2. Guest CFG file is : http://pastebin.com/VbkVq6vV and that's it. 3. This is the guest console log: http://pastebin.com/m1AYtJB8 4. This is log from creation of the guest: http://pastebin.com/a8kfu5Fw 5. Here's brctl and ifconfig from dom0: http://pastebin.com/vAvupgLz 6. Alright, here's all the things I've tried so far: 6a) Firstly I though that since eth0 and vifX.0 are bridged, you should be able to netcat to the VM. The pings works fine: This is the mini-so provided daytime which I'm running. The only difference is that I set the IP to 10.0.2.10/24: http://pastebin.com/UURCj36d Here's where I try to ping (works) and netcat (hangs): http://pastebin.com/zHtS01Tg Here's ltrace and strace of netcat, to see what happens: http://pastebin.com/K9vXF5dX It's pretty verbose, but if you look at the last lines, you can see that connect returns EINPROGRESS. 6b) Going further, I created another VM which basically connects to 10.0.2.10/24. This is the code: http://pastebin.com/w9LCmguH Similary to above, here's the verbose creation output: http://pastebin.com/KUKmisRs Here's the console of "Client-OS": http://pastebin.com/bQQS9K9p We can see that IT WORKS, it connects to the IP just fine. So what's happening here? Here's ifconfig and brctl: http://pastebin.com/VwfXCeUu We can see that the interfaces vif5.0 and vif7.0 are bridged together, which makes sense. I get the daytime output from "Server-OS" to "Client-OS", then the "client" thread exits just fine. It works good. 6c) Obviously, I tried to make the same "experiment" using a lwip client, thinking that I need to connect using LWIP API to a LWIP server (which is wrong, I proved this later, I can connect just find using linux sockets to a LWIP server). What I have done at this step is using the netconn API to create a Linux client that connects to 10.0.2.10 and outputs the received daytime value.I have looked up and found out about lwip unix ports and that there is a shared library which I can link with my linux application. Here's the application code: http://pastebin.com/EnfYnzEC Makefile: http://pastebin.com/i5y4cnMd Here's the ifconfig/brctl: http://pastebin.com/QJakkJj6 Tap0 is bridged in xenbr0. How I did this (it's not provided by defualt): https://groups.google.com/forum/#!topic/osdeve_mirror_tcpip_lwip/yQcb1YmeP5= 4 See third answer. Basically I edited contrib/ports/unix/netif/tapif.c which is used in compiling the liblwip.so library so firstly it adds the tap0 linux interface to xenbr0 before tries to connect to 10.0.2.10/24. Here's the ltrace when running the application (SUPER VERBOSE, probably becuase I have to use root permissions to run this due to the creation of the linux interface which requires special permissions): http://pastebin.com/4vG4QMfi It hangs like netcat. 6d) Moving on, I tried to build the daytime application as a linux application (testing purposes, my target is to create a VM that accepts TCP connections from Linux/win32/whatever platform clients). I have used the same liblwip.so library, and I have compiled an application on my Linux PC. For simplicity, I have added my code to the already provided "simhost" application (which is a ping/telnet/http server application for lwip on linux). I compile that and it works just fine, I can even connect with netcat 10.0.0.2 13 (the default IP the application binds on) and it prints the daytime output. Thus I have concluded that you can connect with regular socket application to a LWIP server if it's configured properly. PS: This application comes in the "contrib-1.3.2" archive from LWIP site at ports/unix/proj/lib (for the shared library) and ports/unix/proj/simhost (for the http server/telnet/ping answerer). Sorry for the extremly long mail, but I wanted to show you all the things I've done so maybe you understand where I've gone wrong and what I should've done better. Tell me if you need additional info. Mihai On Wed, Jul 29, 2015 at 11:46 AM, Ian Campbell wrote: > On Tue, 2015-07-28 at 21:02 +0200, Manfred Haertel, DB3HM wrote: > > I'm cross posting to minios-devel too, just to keep them in the loop. > > > P=C3=AErvu Mihai schrieb: > > > > > Basically what I'm trying to do is connect to the daytime server > > > application mini-os provdes from Dom0. The IP i set is 10.0.2.10/24 > > > . I can ping it just fine, I see it in ifconfig, > > > it > > > is bridged with xenbr0. > > > > > > More, If i create a Mini-OS Client, I can connect just fine to it, I > > > just can't do it from eth0 (using netcat, or whatever socket layer > > > API). > > > > Funny, I tried the same thing today (before reading your mail), with th= e > > same results. > > > > So either we make the same mistake or daytime is broken in mini-os... > > Very few of the in-tree stubdoms use networking (only pvgrub might, but I > bet it isn't commonly used that way, since normally people boot of disk n= ot > network) and I'm pretty certain that none of them use daytime specificall= y, > so if this ever worked I'd not be too surprised if it had regressed at so= me > point over the years. > > Please can one or both of you provide some details of exactly what you've > done/are seeing, so: > > * Which stubdom target you have built, which configuration it is > using, which binary you are loading > * The guest CFG file > * The guest console log > * Logs from the creation of the guest > * brctl, ifconfig etc from dom0. > * Details of what commands run in dom0 aren't working. > > Maybe something in there will give us a hint where to look next. > > Ian > > _______________________________________________ > Minios-devel mailing list > Minios-devel@lists.xenproject.org > http://lists.xenproject.org/cgi-bin/mailman/listinfo/minios-devel --047d7bdc1004d64658051c0103d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alright, here it is, hope we can sort this out:

1. I'm simply compiling Mini-OS from xen/extras/mini-os direct= ory with LWIP support as stated in the README:=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0export LWIPDIR=3D/home/mihai/lwip-1.3.2 and make.
=C2=A0 It creates this binary: h= ttp://pastebin.com/xyyg6P03

=C2=A0 I'm not= using any stubdom, so I guess the default one is used If I have informed m= yself good about this.

2. Guest CFG file is : =C2= =A0http://pastebin.com/VbkVq6vV and that's it.


4. This is log from creation of the guest= : http://pastebin.com/a8kfu5Fw=

5. Here's brctl and ifconfig from dom0:=C2=A0= http://pastebin.com/vAvupgLz

6. Alright, here's all the things I've trie= d so far:

6a) Firstly I though that since eth0 and= vifX.0 are bridged, you should be able to netcat to the VM. The pings work= s fine:=C2=A0
=C2=A0 This is the mini-so provided daytime which I= 'm running. The only difference is that I set the IP to 10.0.2.10/24: http://pastebin.com/UURCj36d
=C2=A0=C2=A0
=C2=A0 H= ere's where I try to ping (works) and netcat (hangs): http://pastebin.com/zHtS01Tg
=C2=A0 H= ere's ltrace and strace of netcat, to see what happens: =C2=A0http://pastebin.com/K9vXF5dX
=C2=A0 It's pretty verbose, but if you look at the last lines, you ca= n see that connect returns EINPROGRESS.

6b) Going = further, I created another VM which basically connects to 10.0.2.10/24. This is the code: http://pastebin.com/w9LCmguH
Similary to abo= ve, here's the verbose creation output: http://pastebin.com/KUKmisRs
Here's the console= of "Client-OS": http://= pastebin.com/bQQS9K9p
We can see that IT WORKS, it connects t= o the IP just fine. So what's happening here?

= Here's ifconfig and brctl: htt= p://pastebin.com/VwfXCeUu
We can see that the interfaces vif5= .0 and vif7.0 are bridged together, which makes sense. I get the daytime ou= tput from "Server-OS" to "Client-OS", then the "cl= ient" thread exits just fine. It works good.

= 6c) Obviously, I tried to make the same "experiment" using a lwip= client, thinking that I need to connect using LWIP API to a LWIP server (w= hich is wrong, I proved this later, I can connect just find using linux soc= kets to a LWIP server).

What I have done at this s= tep is using the netconn =C2=A0API to create a Linux client that connects t= o 10.0.2.10 and outputs the received daytime value.I have looked up and fou= nd out about lwip unix ports and that there is a shared library which I can= link with my linux application.

Here's the ap= plication code:=C2=A0http://pasteb= in.com/EnfYnzEC
Here's the ifconf= ig/brctl:=C2=A0http://pastebin.com= /QJakkJj6

Tap0 is bridged in xenbr0. How I did= this (it's not provided by defualt):=C2=A0https://groups= .google.com/forum/#!topic/osdeve_mirror_tcpip_lwip/yQcb1YmeP54

See third answer. Basically I edited=C2=A0=C2=A0contrib/ports/u= nix/netif/tapif.c which is used in compiling the liblwip.so library so fi= rstly it adds the tap0 linux interface to xenbr0 before tries to connect to= 10.0.2.10/24.=C2=A0
<= span style=3D"font-size:13px;font-family:Arial,Helvetica,sans-serif">
Here's the ltrace when running the application (SUPER VERBOS= E, probably becuase I have to use root permissions to run this due to the c= reation of the linux interface which requires special permissions):=C2=A0http://pastebin.com/4vG4QMfi

It hangs like netcat.

6d) Moving on, I tried= to build the daytime application as a linux application (testing purposes,= my target is to create a VM that accepts TCP connections from Linux/win32/= whatever platform clients). I have used the same liblwip.so library, and I = have compiled an application on my Linux PC. For simplicity, I have added m= y code to the already provided "simhost" application (which is a = ping/telnet/http server application for lwip on linux). I compile that and = it works just fine, I can even connect with netcat 10.0.0.2 13 (the default= IP the application binds on) and it prints the daytime output. Thus I have= concluded that you can connect with regular socket application to a LWIP s= erver if it's configured properly.=C2=A0

PS: This application comes in the "contrib-1.3.2" archive from L= WIP site at ports/unix/proj/lib (for the shared library) and ports/unix/pro= j/simhost (for the http server/telnet/ping answerer).

=C2=A0=C2=A0

Sorry for the extremly= long mail, but I wanted to show you all the things I've done so maybe = you understand where I've gone wrong and what I should've done bett= er.=C2=A0 Tell me if you need additional info.

Mihai

On Wed, Jul 29, 2015 at 11:46 AM, Ian Campbell <ian.camp= bell@citrix.com> wrote:
On = Tue, 2015-07-28 at 21:02 +0200, Manfred Haertel, DB3HM wrote:

I'm cross posting to minios-devel too, just to keep them in the loop.
> P=C3=AErvu Mihai schrieb:
>
> > Basically what I'm trying to do is connect to the daytime ser= ver
> > application mini-os provdes from Dom0. The IP i set is 10.0.2.10= /24
> > <http://10.0.2.10/24>. I can ping it just fine, I see it in i= fconfig,
> > it
> > is bridged with xenbr0.
> >
> > More, If i create a Mini-OS Client, I can connect just fine to it= , I
> > just can't do it from eth0 (using netcat, or whatever socket = layer
> > API).
>
> Funny, I tried the same thing today (before re= ading your mail), with the
> same results.
>
> So either we make the same mistake or daytime is broken in mini-os...<= br>
Very few of the in-tree stubdoms use networking (only pvgrub might, = but I
bet it isn't commonly used that way, since normally people boot of disk= not
network) and I'm pretty certain that none of them use daytime specifica= lly,
so if this ever worked I'd not be too surprised if it had regressed at = some
point over the years.

Please can one or both of you provide some details of exactly what you'= ve
done/are seeing, so:

=C2=A0 =C2=A0 =C2=A0 * Which stubdom target you have built, which configura= tion it is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 using, which binary you are loading
=C2=A0 =C2=A0 =C2=A0 * The guest CFG file
=C2=A0 =C2=A0 =C2=A0 * The guest console log
=C2=A0 =C2=A0 =C2=A0 * Logs from the creation of the guest
=C2=A0 =C2=A0 =C2=A0 * brctl, ifconfig etc from dom0.
=C2=A0 =C2=A0 =C2=A0 * Details of what commands run in dom0 aren't work= ing.

Maybe something in there will give us a hint where to look next.

Ian

_______________________________________________
Minios-devel mailing list
Minios-devel@lists.xen= project.org
http://lists.xenproject.org/cgi-bin= /mailman/listinfo/minios-devel

--047d7bdc1004d64658051c0103d0-- --===============3647586262447138573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============3647586262447138573==-- From xen-users-bounces@lists.xen.org Wed Jul 29 11:25:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 11:25:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPTo-0000XD-Dr; Wed, 29 Jul 2015 11:25:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPTm-0000X4-HW for xen-users@lists.xensource.com; Wed, 29 Jul 2015 11:24:58 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 88/E9-31069-908B8B55; Wed, 29 Jul 2015 11:24:57 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-14.tower-31.messagelabs.com!1438169096!27905377!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13895 invoked from network); 29 Jul 2015 11:24:56 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-14.tower-31.messagelabs.com with SMTP; 29 Jul 2015 11:24:56 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id E09D21228CCC for ; Wed, 29 Jul 2015 04:25:20 -0700 (PDT) Date: Wed, 29 Jul 2015 04:24:55 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438169095826-5728143.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Does Ubuntu lucid support more than 32 GB of ram? I have a XEN server running a PV guest. I upgraded from 32 to 64 GB RAM. The domain0 (host) sees all the RAM and starts the domainU (guest) with all the RAM. But inside the guest OS I can only see 32 of 64 GB RAM. I think this is a limitation of ubuntu 10.04 because the xentop command give me the guest with all the RAM. Domain0 (host) specifications : - Ubuntu 12.04.2 LTS - 3.5.0-34-generic kernel - 64 bit - all RAM is addressed DomainU (guest) specifications : - Ubuntu 10.04.4 LTS - 2.6.32-40-server kernel - 64 bit - ParaVirtualized - it sees only 32GB of 64 GB RAM. There was no problem while upgrading from 16 to 32 GB. This is very similar to this old topic: http://old-list-archives.xenproject.org/xen-users/2011-06/msg00393.html But I guess I already have the newer kernel... Thanks to everyone. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 11:25:06 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 11:25:06 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPTo-0000XD-Dr; Wed, 29 Jul 2015 11:25:00 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKPTm-0000X4-HW for xen-users@lists.xensource.com; Wed, 29 Jul 2015 11:24:58 +0000 Received: from [85.158.137.68] by server-8.bemta-3.messagelabs.com id 88/E9-31069-908B8B55; Wed, 29 Jul 2015 11:24:57 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-14.tower-31.messagelabs.com!1438169096!27905377!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13895 invoked from network); 29 Jul 2015 11:24:56 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-14.tower-31.messagelabs.com with SMTP; 29 Jul 2015 11:24:56 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id E09D21228CCC for ; Wed, 29 Jul 2015 04:25:20 -0700 (PDT) Date: Wed, 29 Jul 2015 04:24:55 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438169095826-5728143.post@n5.nabble.com> MIME-Version: 1.0 Subject: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Does Ubuntu lucid support more than 32 GB of ram? I have a XEN server running a PV guest. I upgraded from 32 to 64 GB RAM. The domain0 (host) sees all the RAM and starts the domainU (guest) with all the RAM. But inside the guest OS I can only see 32 of 64 GB RAM. I think this is a limitation of ubuntu 10.04 because the xentop command give me the guest with all the RAM. Domain0 (host) specifications : - Ubuntu 12.04.2 LTS - 3.5.0-34-generic kernel - 64 bit - all RAM is addressed DomainU (guest) specifications : - Ubuntu 10.04.4 LTS - 2.6.32-40-server kernel - 64 bit - ParaVirtualized - it sees only 32GB of 64 GB RAM. There was no problem while upgrading from 16 to 32 GB. This is very similar to this old topic: http://old-list-archives.xenproject.org/xen-users/2011-06/msg00393.html But I guess I already have the newer kernel... Thanks to everyone. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 12:52:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 12:52:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKQpi-0006k9-Cq; Wed, 29 Jul 2015 12:51:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKQph-0006k4-9U for xen-users@lists.xen.org; Wed, 29 Jul 2015 12:51:41 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id F5/E3-10422-C5CC8B55; Wed, 29 Jul 2015 12:51:40 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1438174299!24400154!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23503 invoked from network); 29 Jul 2015 12:51:39 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-12.tower-206.messagelabs.com with SMTP; 29 Jul 2015 12:51:39 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 8599B24567C; Wed, 29 Jul 2015 14:51:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfaJu_YAKI6v; Wed, 29 Jul 2015 14:51:37 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 9791E24564A; Wed, 29 Jul 2015 14:51:36 +0200 (CEST) From: Wolf Grossi To: Zir Blazer , "xen-users@lists.xen.org" References: <55B797D2.6050708@magro-soft.com> Message-ID: <55B8CC51.4060207@magro-soft.com> Date: Wed, 29 Jul 2015 14:51:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 28.07.2015 17:52, Zir Blazer wrote: > PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. > > > http://xen.1045712.n5.nabble.com/Need-help-trying-to-use-SPICE-USB-Redirection-on-Xen-4-5-td5727045.html > > > > ---------------------------------------- >> To: xen-users@lists.xen.org >> From: wg@magro-soft.com >> Date: Tue, 28 Jul 2015 16:55:14 +0200 >> Subject: [Xen-users] PV Guest and USB >> >> Greetings! >> >> There are several docs in the net describing how to passthru/attach a >> USB device to a PV guest. (e.g. >> http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) >> >> I tried them all but without success. >> >> >> I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. >> >> Does USB support even work in the above constellation? >> >> Any hints? >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > Thanks for your info. I checked SPICE and apparently is for HVM guest only, I'm using a PV-guest. PVUSB is broken since 4.4; quote: 'As of Xen 4.4 PVUSB is only supported with xm/xend toolstack.' http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl ...and xm/xend does not go together with libvirt/xl-tools. Wolf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 12:52:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 12:52:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKQpi-0006k9-Cq; Wed, 29 Jul 2015 12:51:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKQph-0006k4-9U for xen-users@lists.xen.org; Wed, 29 Jul 2015 12:51:41 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id F5/E3-10422-C5CC8B55; Wed, 29 Jul 2015 12:51:40 +0000 X-Env-Sender: wg@magro-soft.com X-Msg-Ref: server-12.tower-206.messagelabs.com!1438174299!24400154!1 X-Originating-IP: [216.55.106.149] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23503 invoked from network); 29 Jul 2015 12:51:39 -0000 Received: from magro-soft.com (HELO mail.magro-soft.com) (216.55.106.149) by server-12.tower-206.messagelabs.com with SMTP; 29 Jul 2015 12:51:39 -0000 Received: from localhost (localhost [127.0.0.1]) by mail.magro-soft.com (Postfix) with ESMTP id 8599B24567C; Wed, 29 Jul 2015 14:51:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at magro-soft.com Received: from mail.magro-soft.com ([127.0.0.1]) by localhost (magro-soft.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfaJu_YAKI6v; Wed, 29 Jul 2015 14:51:37 +0200 (CEST) Received: from [192.168.1.20] (MAGRO.SBG [85.199.50.235]) (Authenticated sender: magro@magro-soft.com) by mail.magro-soft.com (Postfix) with ESMTPSA id 9791E24564A; Wed, 29 Jul 2015 14:51:36 +0200 (CEST) From: Wolf Grossi To: Zir Blazer , "xen-users@lists.xen.org" References: <55B797D2.6050708@magro-soft.com> Message-ID: <55B8CC51.4060207@magro-soft.com> Date: Wed, 29 Jul 2015 14:51:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 28.07.2015 17:52, Zir Blazer wrote: > PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. > > > http://xen.1045712.n5.nabble.com/Need-help-trying-to-use-SPICE-USB-Redirection-on-Xen-4-5-td5727045.html > > > > ---------------------------------------- >> To: xen-users@lists.xen.org >> From: wg@magro-soft.com >> Date: Tue, 28 Jul 2015 16:55:14 +0200 >> Subject: [Xen-users] PV Guest and USB >> >> Greetings! >> >> There are several docs in the net describing how to passthru/attach a >> USB device to a PV guest. (e.g. >> http://wiki.xenproject.org/wiki/Xen_USB_Passthrough) >> >> I tried them all but without success. >> >> >> I am using openSuse-13.2 with XEN-4.4 and libvirt-1.2.9. >> >> Does USB support even work in the above constellation? >> >> Any hints? >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users > Thanks for your info. I checked SPICE and apparently is for HVM guest only, I'm using a PV-guest. PVUSB is broken since 4.4; quote: 'As of Xen 4.4 PVUSB is only supported with xm/xend toolstack.' http://wiki.xenproject.org/wiki/Xen_USB_Passthrough#PVUSB_in_xl.2Flibxl ...and xm/xend does not go together with libvirt/xl-tools. Wolf _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 13:26:17 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 13:26:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKRM3-0008Eo-DE; Wed, 29 Jul 2015 13:25:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKRM2-0008Ej-Ec for xen-users@lists.xensource.com; Wed, 29 Jul 2015 13:25:06 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id B1/45-17885-134D8B55; Wed, 29 Jul 2015 13:25:05 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1438176303!19028834!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7228 invoked from network); 29 Jul 2015 13:25:05 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 13:25:05 -0000 X-IronPort-AV: E=Sophos;i="5.15,570,1432598400"; d="scan'208";a="285626774" Message-ID: <1438176296.11600.199.camel@citrix.com> From: Ian Campbell To: dataworks.biz , Date: Wed, 29 Jul 2015 14:24:56 +0100 In-Reply-To: <1438169095826-5728143.post@n5.nabble.com> References: <1438169095826-5728143.post@n5.nabble.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-29 at 04:24 -0700, dataworks.biz wrote: > Does Ubuntu lucid support more than 32 GB of ram? > I have a XEN server running a PV guest. I upgraded from 32 to 64 GB RAM. > The domain0 (host) sees all the RAM and starts the domainU (guest) with > all > the RAM. But inside the guest OS I can only see 32 of 64 GB RAM. I think > this is a limitation of ubuntu 10.04 because the xentop command give me > the > guest with all the RAM. > Domain0 (host) specifications : > - Ubuntu 12.04.2 LTS > - 3.5.0-34-generic kernel > - 64 bit > - all RAM is addressed > DomainU (guest) specifications : > - Ubuntu 10.04.4 LTS > - 2.6.32-40-server kernel > - 64 bit > - ParaVirtualized > - it sees only 32GB of 64 GB RAM. > There was no problem while upgrading from 16 to 32 GB. > > This is very similar to this old topic: > http://old-list-archives.xenproject.org/xen-users/2011-06/msg00393.html > > But I guess I already have the newer kernel... I think your 2.6.32 based domU kernel is old enough that it still has the old compile time limit, which Ubuntu appears to have set to 32GB. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 13:26:17 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 13:26:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKRM3-0008Eo-DE; Wed, 29 Jul 2015 13:25:07 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKRM2-0008Ej-Ec for xen-users@lists.xensource.com; Wed, 29 Jul 2015 13:25:06 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id B1/45-17885-134D8B55; Wed, 29 Jul 2015 13:25:05 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1438176303!19028834!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7228 invoked from network); 29 Jul 2015 13:25:05 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 13:25:05 -0000 X-IronPort-AV: E=Sophos;i="5.15,570,1432598400"; d="scan'208";a="285626774" Message-ID: <1438176296.11600.199.camel@citrix.com> From: Ian Campbell To: dataworks.biz , Date: Wed, 29 Jul 2015 14:24:56 +0100 In-Reply-To: <1438169095826-5728143.post@n5.nabble.com> References: <1438169095826-5728143.post@n5.nabble.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-29 at 04:24 -0700, dataworks.biz wrote: > Does Ubuntu lucid support more than 32 GB of ram? > I have a XEN server running a PV guest. I upgraded from 32 to 64 GB RAM. > The domain0 (host) sees all the RAM and starts the domainU (guest) with > all > the RAM. But inside the guest OS I can only see 32 of 64 GB RAM. I think > this is a limitation of ubuntu 10.04 because the xentop command give me > the > guest with all the RAM. > Domain0 (host) specifications : > - Ubuntu 12.04.2 LTS > - 3.5.0-34-generic kernel > - 64 bit > - all RAM is addressed > DomainU (guest) specifications : > - Ubuntu 10.04.4 LTS > - 2.6.32-40-server kernel > - 64 bit > - ParaVirtualized > - it sees only 32GB of 64 GB RAM. > There was no problem while upgrading from 16 to 32 GB. > > This is very similar to this old topic: > http://old-list-archives.xenproject.org/xen-users/2011-06/msg00393.html > > But I guess I already have the newer kernel... I think your 2.6.32 based domU kernel is old enough that it still has the old compile time limit, which Ubuntu appears to have set to 32GB. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 15:04:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:04:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKStI-000650-Bx; Wed, 29 Jul 2015 15:03:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKStG-00064q-D2 for xen-users@lists.xensource.com; Wed, 29 Jul 2015 15:03:30 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 24/DD-10715-14BE8B55; Wed, 29 Jul 2015 15:03:29 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-15.tower-27.messagelabs.com!1438182208!36284385!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21419 invoked from network); 29 Jul 2015 15:03:28 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-15.tower-27.messagelabs.com with SMTP; 29 Jul 2015 15:03:28 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 59DF9122C8C6 for ; Wed, 29 Jul 2015 08:03:53 -0700 (PDT) Date: Wed, 29 Jul 2015 08:03:28 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438182208011-5728146.post@n5.nabble.com> In-Reply-To: <1438176296.11600.199.camel@citrix.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org If I upgrade my ubuntu 10.04 domU, the kernel version changes from 2.6.32-40-server to 2.6.32-74-server. Should this solve the issue or i need a kernel newer than 2.6 ? Thank you. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143p5728146.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 15:04:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:04:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKStI-000650-Bx; Wed, 29 Jul 2015 15:03:32 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKStG-00064q-D2 for xen-users@lists.xensource.com; Wed, 29 Jul 2015 15:03:30 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id 24/DD-10715-14BE8B55; Wed, 29 Jul 2015 15:03:29 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-15.tower-27.messagelabs.com!1438182208!36284385!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21419 invoked from network); 29 Jul 2015 15:03:28 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-15.tower-27.messagelabs.com with SMTP; 29 Jul 2015 15:03:28 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 59DF9122C8C6 for ; Wed, 29 Jul 2015 08:03:53 -0700 (PDT) Date: Wed, 29 Jul 2015 08:03:28 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438182208011-5728146.post@n5.nabble.com> In-Reply-To: <1438176296.11600.199.camel@citrix.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org If I upgrade my ubuntu 10.04 domU, the kernel version changes from 2.6.32-40-server to 2.6.32-74-server. Should this solve the issue or i need a kernel newer than 2.6 ? Thank you. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143p5728146.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 15:04:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:04:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKSuD-00067a-Uw; Wed, 29 Jul 2015 15:04:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKSuD-00067R-3T for xen-users@lists.xen.org; Wed, 29 Jul 2015 15:04:29 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 59/81-01421-C7BE8B55; Wed, 29 Jul 2015 15:04:28 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438182266!30400337!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11308 invoked from network); 29 Jul 2015 15:04:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:04:27 -0000 X-IronPort-AV: E=Sophos;i="5.15,571,1432598400"; d="scan'208";a="285678707" Message-ID: <1438182258.11600.208.camel@citrix.com> From: Ian Campbell To: =?ISO-8859-1?Q?P=EErvu?= Mihai Date: Wed, 29 Jul 2015 16:04:18 +0100 In-Reply-To: References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gV2VkLCAyMDE1LTA3LTI5IGF0IDEzOjI2ICswMzAwLCBQw65ydnUgTWloYWkgd3JvdGU6Cj4g QWxyaWdodCwgaGVyZSBpdCBpcywgaG9wZSB3ZSBjYW4gc29ydCB0aGlzIG91dDoKClRoYW5rcywg SSB0b29rIHdoYXQgeW91IGhhZCwgYnV0IHVzaW5nIHRoZSBsd2lwLTEuMy4wICsgcGF0Y2hlcyBm cm9tCnhlbi5naXQvc3R1YmRvbSAoanVzdCBiZWNhdXNlIHRoZXkgd2VyZSB0byBoYW5kKSBhbmQg cmVwcm9kIHdoYXQgeW91J3ZlCmJlZW4gc2VlaW5nLgoKVGhlbiAob24gYSBodW5jaCkgSSBkaWQg ImV0aHRvb2wgLUsgdmlmMTMuMCB0eCBvZmYiIGFuZCBpdCBzdGFydGVkIHdvcmtpbmcuCgpTbyBJ IHRoaW5rIHRoZXJlIG11c3QgYmUgYSBidWcgZWl0aGVyIGluIG1pbmktb3MncyBuZXRmcm9udCBj aGVja3N1bQpvZmZsb2FkLCBvciBpbiB0aGUgbmVnb3RpYXRpb24gaXQgZG9lcyB3aXRoIG5ldGJh Y2suCgpIb3BlZnVsbHkgdGhhdCBpcyBlbm91Z2ggZm9yIHNvbWVvbmUgdG8gYmUgZ29pbmcgb24g d2l0aC4KCklhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Wed Jul 29 15:04:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:04:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKSuD-00067a-Uw; Wed, 29 Jul 2015 15:04:29 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKSuD-00067R-3T for xen-users@lists.xen.org; Wed, 29 Jul 2015 15:04:29 +0000 Received: from [85.158.137.68] by server-1.bemta-3.messagelabs.com id 59/81-01421-C7BE8B55; Wed, 29 Jul 2015 15:04:28 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1438182266!30400337!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11308 invoked from network); 29 Jul 2015 15:04:27 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:04:27 -0000 X-IronPort-AV: E=Sophos;i="5.15,571,1432598400"; d="scan'208";a="285678707" Message-ID: <1438182258.11600.208.camel@citrix.com> From: Ian Campbell To: =?ISO-8859-1?Q?P=EErvu?= Mihai Date: Wed, 29 Jul 2015 16:04:18 +0100 In-Reply-To: References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gV2VkLCAyMDE1LTA3LTI5IGF0IDEzOjI2ICswMzAwLCBQw65ydnUgTWloYWkgd3JvdGU6Cj4g QWxyaWdodCwgaGVyZSBpdCBpcywgaG9wZSB3ZSBjYW4gc29ydCB0aGlzIG91dDoKClRoYW5rcywg SSB0b29rIHdoYXQgeW91IGhhZCwgYnV0IHVzaW5nIHRoZSBsd2lwLTEuMy4wICsgcGF0Y2hlcyBm cm9tCnhlbi5naXQvc3R1YmRvbSAoanVzdCBiZWNhdXNlIHRoZXkgd2VyZSB0byBoYW5kKSBhbmQg cmVwcm9kIHdoYXQgeW91J3ZlCmJlZW4gc2VlaW5nLgoKVGhlbiAob24gYSBodW5jaCkgSSBkaWQg ImV0aHRvb2wgLUsgdmlmMTMuMCB0eCBvZmYiIGFuZCBpdCBzdGFydGVkIHdvcmtpbmcuCgpTbyBJ IHRoaW5rIHRoZXJlIG11c3QgYmUgYSBidWcgZWl0aGVyIGluIG1pbmktb3MncyBuZXRmcm9udCBj aGVja3N1bQpvZmZsb2FkLCBvciBpbiB0aGUgbmVnb3RpYXRpb24gaXQgZG9lcyB3aXRoIG5ldGJh Y2suCgpIb3BlZnVsbHkgdGhhdCBpcyBlbm91Z2ggZm9yIHNvbWVvbmUgdG8gYmUgZ29pbmcgb24g d2l0aC4KCklhbi4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcKaHR0cDov L2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Wed Jul 29 15:18:12 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:18:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKT7C-0007my-S6; Wed, 29 Jul 2015 15:17:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKT7B-0007mq-HZ for xen-users@lists.xensource.com; Wed, 29 Jul 2015 15:17:53 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 47/46-19220-0AEE8B55; Wed, 29 Jul 2015 15:17:52 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1438183071!24448307!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11919 invoked from network); 29 Jul 2015 15:17:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:17:52 -0000 X-IronPort-AV: E=Sophos;i="5.15,571,1432598400"; d="scan'208";a="285686907" Message-ID: <1438183068.11600.212.camel@citrix.com> From: Ian Campbell To: dataworks.biz , Date: Wed, 29 Jul 2015 16:17:48 +0100 In-Reply-To: <1438182208011-5728146.post@n5.nabble.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> <1438182208011-5728146.post@n5.nabble.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-29 at 08:03 -0700, dataworks.biz wrote: > If I upgrade my ubuntu 10.04 domU, the kernel version changes from > 2.6.32-40-server to 2.6.32-74-server. > > Should this solve the issue or i need a kernel newer than 2.6 ? I don't know, but I would expect that this will not be sufficient. You can easily check, since there will be a CONFIG_XEN_MAX_DOMAIN_MEMORY=NN in the given kernel's config telling you the limit. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 15:18:12 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 15:18:12 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKT7C-0007my-S6; Wed, 29 Jul 2015 15:17:54 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKT7B-0007mq-HZ for xen-users@lists.xensource.com; Wed, 29 Jul 2015 15:17:53 +0000 Received: from [85.158.139.211] by server-12.bemta-5.messagelabs.com id 47/46-19220-0AEE8B55; Wed, 29 Jul 2015 15:17:52 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1438183071!24448307!1 X-Originating-IP: [66.165.176.89] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni44OSA9PiAyMDMwMDc=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 11919 invoked from network); 29 Jul 2015 15:17:52 -0000 Received: from smtp.citrix.com (HELO SMTP.CITRIX.COM) (66.165.176.89) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:17:52 -0000 X-IronPort-AV: E=Sophos;i="5.15,571,1432598400"; d="scan'208";a="285686907" Message-ID: <1438183068.11600.212.camel@citrix.com> From: Ian Campbell To: dataworks.biz , Date: Wed, 29 Jul 2015 16:17:48 +0100 In-Reply-To: <1438182208011-5728146.post@n5.nabble.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> <1438182208011-5728146.post@n5.nabble.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Wed, 2015-07-29 at 08:03 -0700, dataworks.biz wrote: > If I upgrade my ubuntu 10.04 domU, the kernel version changes from > 2.6.32-40-server to 2.6.32-74-server. > > Should this solve the issue or i need a kernel newer than 2.6 ? I don't know, but I would expect that this will not be sufficient. You can easily check, since there will be a CONFIG_XEN_MAX_DOMAIN_MEMORY=NN in the given kernel's config telling you the limit. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 16:24:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 16:24:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKU9P-0003vM-Lg; Wed, 29 Jul 2015 16:24:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKU9O-0003vF-87 for xen-users@lists.xensource.com; Wed, 29 Jul 2015 16:24:14 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 63/F2-01143-D2EF8B55; Wed, 29 Jul 2015 16:24:13 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-6.tower-27.messagelabs.com!1438187052!36306120!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15795 invoked from network); 29 Jul 2015 16:24:12 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-6.tower-27.messagelabs.com with SMTP; 29 Jul 2015 16:24:12 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 86133122E0E1 for ; Wed, 29 Jul 2015 09:24:37 -0700 (PDT) Date: Wed, 29 Jul 2015 09:24:12 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438187052092-5728159.post@n5.nabble.com> In-Reply-To: <1438183068.11600.212.camel@citrix.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> <1438182208011-5728146.post@n5.nabble.com> <1438183068.11600.212.camel@citrix.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org For others with same issue: I installed the 2.6.32-74-server kernel on a test machine, and this SHOULD solve the issue: before: cat /boot/config-2.6.32-40-server |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=32 after: cat /boot/config-2.6.32-74-server |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=70 So the limit was changed to 70 GB. Still low form my server that supports up to 256 GB but is ok for my actual 64 GB RAM. Obviously I do not have 64 GB on the test server, so I should test this on the production server... Thank you Ian. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143p5728159.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 16:24:56 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 16:24:56 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKU9P-0003vM-Lg; Wed, 29 Jul 2015 16:24:15 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKU9O-0003vF-87 for xen-users@lists.xensource.com; Wed, 29 Jul 2015 16:24:14 +0000 Received: from [193.109.254.147] by server-10.bemta-14.messagelabs.com id 63/F2-01143-D2EF8B55; Wed, 29 Jul 2015 16:24:13 +0000 X-Env-Sender: tex---74@tiscali.it X-Msg-Ref: server-6.tower-27.messagelabs.com!1438187052!36306120!1 X-Originating-IP: [162.253.133.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15795 invoked from network); 29 Jul 2015 16:24:12 -0000 Received: from mbob.nabble.com (HELO mbob.nabble.com) (162.253.133.15) by server-6.tower-27.messagelabs.com with SMTP; 29 Jul 2015 16:24:12 -0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mbob.nabble.com (Postfix) with ESMTP id 86133122E0E1 for ; Wed, 29 Jul 2015 09:24:37 -0700 (PDT) Date: Wed, 29 Jul 2015 09:24:12 -0700 (MST) From: "dataworks.biz" To: xen-users@lists.xensource.com Message-ID: <1438187052092-5728159.post@n5.nabble.com> In-Reply-To: <1438183068.11600.212.camel@citrix.com> References: <1438169095826-5728143.post@n5.nabble.com> <1438176296.11600.199.camel@citrix.com> <1438182208011-5728146.post@n5.nabble.com> <1438183068.11600.212.camel@citrix.com> MIME-Version: 1.0 Subject: Re: [Xen-users] Can be installed more than 32 GB RAM on Ubuntu 10.04 64 bit XEN VM? X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org For others with same issue: I installed the 2.6.32-74-server kernel on a test machine, and this SHOULD solve the issue: before: cat /boot/config-2.6.32-40-server |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=32 after: cat /boot/config-2.6.32-74-server |grep CONFIG_XEN_MAX_DOMAIN_MEMORY CONFIG_XEN_MAX_DOMAIN_MEMORY=70 So the limit was changed to 70 GB. Still low form my server that supports up to 256 GB but is ok for my actual 64 GB RAM. Obviously I do not have 64 GB on the test server, so I should test this on the production server... Thank you Ian. -- View this message in context: http://xen.1045712.n5.nabble.com/Can-be-installed-more-than-32-GB-RAM-on-Ubuntu-10-04-64-bit-XEN-VM-tp5728143p5728159.html Sent from the Xen - User mailing list archive at Nabble.com. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 16:46:59 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 16:46:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKUV8-0005g4-97; Wed, 29 Jul 2015 16:46:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKUV7-0005fk-6T for xen-users@lists.xen.org; Wed, 29 Jul 2015 16:46:41 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 27/A1-17885-07309B55; Wed, 29 Jul 2015 16:46:40 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1438188397!24491156!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25370 invoked from network); 29 Jul 2015 16:46:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 16:46:39 -0000 X-IronPort-AV: E=Sophos;i="5.15,572,1432598400"; d="scan'208";a="288956919" Message-ID: <1438188391.11600.219.camel@citrix.com> From: Ian Campbell To: =?ISO-8859-1?Q?P=EErvu?= Mihai Date: Wed, 29 Jul 2015 17:46:31 +0100 In-Reply-To: References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> <1438182258.11600.208.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gV2VkLCAyMDE1LTA3LTI5IGF0IDE4OjUwICswMzAwLCBQw65ydnUgTWloYWkgd3JvdGU6Cj4g SSd2ZSBiZWVuIG9uIHRoaXMgZm9yIGxpa2UgMTAgZGF5cyBhbmQgeW91IGhhdmUgZm91bmQgYSBz b2x1dGlvbiBpbiBmZXcgCj4gaG91cnMuIFRoYW5rcyB5b3UsIEkgZ3Vlc3MgdGhpcyBzaG93cyB0 aGUgZGlmZmVyZW5jZSBpbiBleHBlcmllbmNlIG92ZXIgCj4gdGhpcyBwcm9qZWN0IDopCgpJIGp1 c3Qga25vdyB3aGVyZSB0aGUgYm9kaWVzIGFyZSBidXJpZWQgOy0pCgo+ICBIb3BlIHRoaXMgZ2V0 cyBzb3J0ZWQgb3V0LgoKRkFPRCBJIHBlcnNvbmFsbHkgZG9uJ3QgaGF2ZSB0aW1lIHRvIGxvb2sg aW50byB0aGlzIGFueSBmdXJ0aGVyLiBQYXRjaGVzCmFyZSBvZiBjb3Vyc2UgdmVyeSBtdWNoIHdl bGNvbWVkLCBmcm9tIHlvdSBvciBvdGhlcnMuCgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxpbmcgbGlzdApYZW4tdXNl cnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM= From xen-users-bounces@lists.xen.org Wed Jul 29 16:46:59 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 16:46:59 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKUV8-0005g4-97; Wed, 29 Jul 2015 16:46:42 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKUV7-0005fk-6T for xen-users@lists.xen.org; Wed, 29 Jul 2015 16:46:41 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 27/A1-17885-07309B55; Wed, 29 Jul 2015 16:46:40 +0000 X-Env-Sender: prvs=6453b2377=Ian.Campbell@citrix.com X-Msg-Ref: server-6.tower-206.messagelabs.com!1438188397!24491156!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25370 invoked from network); 29 Jul 2015 16:46:39 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-6.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 16:46:39 -0000 X-IronPort-AV: E=Sophos;i="5.15,572,1432598400"; d="scan'208";a="288956919" Message-ID: <1438188391.11600.219.camel@citrix.com> From: Ian Campbell To: =?ISO-8859-1?Q?P=EErvu?= Mihai Date: Wed, 29 Jul 2015 17:46:31 +0100 In-Reply-To: References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> <1438182258.11600.208.camel@citrix.com> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA1 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org T24gV2VkLCAyMDE1LTA3LTI5IGF0IDE4OjUwICswMzAwLCBQw65ydnUgTWloYWkgd3JvdGU6Cj4g SSd2ZSBiZWVuIG9uIHRoaXMgZm9yIGxpa2UgMTAgZGF5cyBhbmQgeW91IGhhdmUgZm91bmQgYSBz b2x1dGlvbiBpbiBmZXcgCj4gaG91cnMuIFRoYW5rcyB5b3UsIEkgZ3Vlc3MgdGhpcyBzaG93cyB0 aGUgZGlmZmVyZW5jZSBpbiBleHBlcmllbmNlIG92ZXIgCj4gdGhpcyBwcm9qZWN0IDopCgpJIGp1 c3Qga25vdyB3aGVyZSB0aGUgYm9kaWVzIGFyZSBidXJpZWQgOy0pCgo+ICBIb3BlIHRoaXMgZ2V0 cyBzb3J0ZWQgb3V0LgoKRkFPRCBJIHBlcnNvbmFsbHkgZG9uJ3QgaGF2ZSB0aW1lIHRvIGxvb2sg aW50byB0aGlzIGFueSBmdXJ0aGVyLiBQYXRjaGVzCmFyZSBvZiBjb3Vyc2UgdmVyeSBtdWNoIHdl bGNvbWVkLCBmcm9tIHlvdSBvciBvdGhlcnMuCgpJYW4uCgoKX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLXVzZXJzIG1haWxpbmcgbGlzdApYZW4tdXNl cnNAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9yZy94ZW4tdXNlcnM= From xen-users-bounces@lists.xen.org Wed Jul 29 18:43:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 18:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKWJ9-0002ow-J6; Wed, 29 Jul 2015 18:42:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKTck-0001Wj-BG for xen-users@lists.xen.org; Wed, 29 Jul 2015 15:50:30 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id D8/97-17885-546F8B55; Wed, 29 Jul 2015 15:50:29 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1438185028!16904185!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2856 invoked from network); 29 Jul 2015 15:50:29 -0000 Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:50:29 -0000 Received: by iodd187 with SMTP id d187so25678825iod.2 for ; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hhh9FcMHFJR9mLYei3htHd91yx7I3bRkbi/9vPBYWbA=; b=QXufhp3vOMYKLTSoVWOIekxTNfkKZKKB5NH5OF/ejNtXk/wYAH0KkG695vu2YDRXMJ AmhYEx9gESOo8AfFBHsmPYQe67NlJqkLDL7IQri9EeK/Tqylv5QfE3aQ+hzVCMjOgwPD GeIvlk20dxLxc4hUnpN5JZLNjhXEQe3ifcL9T1DBZ5oQjAq6GD2SnWnlrAmsVz1feNbA dXjYHRaz492cW/l6Sm8eLKym+oHGe9xSFrlRa2Ki9tEqpenKaKn3b/OYly/lQ09UJuhp 2nj2frLOJSO370QdUSoIJeFMb2zW6vJdQ0HpRtP3lO3ShP0wWyQWnH6ayQzREtLoVdQD 4XuQ== MIME-Version: 1.0 X-Received: by 10.107.37.134 with SMTP id l128mr2796954iol.92.1438185028080; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) In-Reply-To: <1438182258.11600.208.camel@citrix.com> References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> <1438182258.11600.208.camel@citrix.com> Date: Wed, 29 Jul 2015 18:50:28 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: Ian Campbell X-Mailman-Approved-At: Wed, 29 Jul 2015 18:42:27 +0000 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8240207702369924697==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8240207702369924697== Content-Type: multipart/alternative; boundary=001a1140ea86b859ed051c058bda --001a1140ea86b859ed051c058bda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been on this for like 10 days and you have found a solution in few hours. Thanks you, I guess this shows the difference in experience over this project :) Hope this gets sorted out. Mihai On Wed, Jul 29, 2015 at 6:04 PM, Ian Campbell wrote: > On Wed, 2015-07-29 at 13:26 +0300, P=C3=AErvu Mihai wrote: > > Alright, here it is, hope we can sort this out: > > Thanks, I took what you had, but using the lwip-1.3.0 + patches from > xen.git/stubdom (just because they were to hand) and reprod what you've > been seeing. > > Then (on a hunch) I did "ethtool -K vif13.0 tx off" and it started workin= g. > > So I think there must be a bug either in mini-os's netfront checksum > offload, or in the negotiation it does with netback. > > Hopefully that is enough for someone to be going on with. > > Ian. > --001a1140ea86b859ed051c058bda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been on this for like 10 days and you have found = a solution in few hours. Thanks you, I guess this shows the difference in e= xperience over this project :) Hope this gets sorted out.

Mihai

On Wed, Jul 29, 2015 at 6:04 PM, Ian Campbell <ian.campbell@citrix= .com> wrote:
On Wed, 2015-07-29 at 13:26 +0300, P=C3=AErvu Mihai wrote:
> Alright, here it is, hope we can sort this out:

Thanks, I took what you had, but using the lwip-1.3.0 + patches from=
xen.git/stubdom (just because they were to hand) and reprod what you've=
been seeing.

Then (on a hunch) I did "ethtool -K vif13.0 tx off" and it starte= d working.

So I think there must be a bug either in mini-os's netfront checksum offload, or in the negotiation it does with netback.

Hopefully that is enough for someone to be going on with.

Ian.

--001a1140ea86b859ed051c058bda-- --===============8240207702369924697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8240207702369924697==-- From xen-users-bounces@lists.xen.org Wed Jul 29 18:43:15 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 18:43:15 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKWJ9-0002ow-J6; Wed, 29 Jul 2015 18:42:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKTck-0001Wj-BG for xen-users@lists.xen.org; Wed, 29 Jul 2015 15:50:30 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id D8/97-17885-546F8B55; Wed, 29 Jul 2015 15:50:29 +0000 X-Env-Sender: mihaicristianpirvu@gmail.com X-Msg-Ref: server-3.tower-206.messagelabs.com!1438185028!16904185!1 X-Originating-IP: [209.85.223.181] X-SpamReason: No, hits=0.4 required=7.0 tests=HTML_30_40,HTML_MESSAGE, RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2856 invoked from network); 29 Jul 2015 15:50:29 -0000 Received: from mail-io0-f181.google.com (HELO mail-io0-f181.google.com) (209.85.223.181) by server-3.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 29 Jul 2015 15:50:29 -0000 Received: by iodd187 with SMTP id d187so25678825iod.2 for ; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Hhh9FcMHFJR9mLYei3htHd91yx7I3bRkbi/9vPBYWbA=; b=QXufhp3vOMYKLTSoVWOIekxTNfkKZKKB5NH5OF/ejNtXk/wYAH0KkG695vu2YDRXMJ AmhYEx9gESOo8AfFBHsmPYQe67NlJqkLDL7IQri9EeK/Tqylv5QfE3aQ+hzVCMjOgwPD GeIvlk20dxLxc4hUnpN5JZLNjhXEQe3ifcL9T1DBZ5oQjAq6GD2SnWnlrAmsVz1feNbA dXjYHRaz492cW/l6Sm8eLKym+oHGe9xSFrlRa2Ki9tEqpenKaKn3b/OYly/lQ09UJuhp 2nj2frLOJSO370QdUSoIJeFMb2zW6vJdQ0HpRtP3lO3ShP0wWyQWnH6ayQzREtLoVdQD 4XuQ== MIME-Version: 1.0 X-Received: by 10.107.37.134 with SMTP id l128mr2796954iol.92.1438185028080; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) Received: by 10.107.143.215 with HTTP; Wed, 29 Jul 2015 08:50:28 -0700 (PDT) In-Reply-To: <1438182258.11600.208.camel@citrix.com> References: <55B7D1D3.7030200@rz-online.de> <1438159613.11600.171.camel@citrix.com> <1438182258.11600.208.camel@citrix.com> Date: Wed, 29 Jul 2015 18:50:28 +0300 Message-ID: From: =?UTF-8?B?UMOucnZ1IE1paGFp?= To: Ian Campbell X-Mailman-Approved-At: Wed, 29 Jul 2015 18:42:27 +0000 Cc: Minios-devel@lists.xenproject.org, xen-users , "Manfred Haertel, DB3HM" Subject: Re: [Xen-users] [Minios-devel] Problems connecting to the daytime application provided with Mini-OS X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8240207702369924697==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8240207702369924697== Content-Type: multipart/alternative; boundary=001a1140ea86b859ed051c058bda --001a1140ea86b859ed051c058bda Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've been on this for like 10 days and you have found a solution in few hours. Thanks you, I guess this shows the difference in experience over this project :) Hope this gets sorted out. Mihai On Wed, Jul 29, 2015 at 6:04 PM, Ian Campbell wrote: > On Wed, 2015-07-29 at 13:26 +0300, P=C3=AErvu Mihai wrote: > > Alright, here it is, hope we can sort this out: > > Thanks, I took what you had, but using the lwip-1.3.0 + patches from > xen.git/stubdom (just because they were to hand) and reprod what you've > been seeing. > > Then (on a hunch) I did "ethtool -K vif13.0 tx off" and it started workin= g. > > So I think there must be a bug either in mini-os's netfront checksum > offload, or in the negotiation it does with netback. > > Hopefully that is enough for someone to be going on with. > > Ian. > --001a1140ea86b859ed051c058bda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've been on this for like 10 days and you have found = a solution in few hours. Thanks you, I guess this shows the difference in e= xperience over this project :) Hope this gets sorted out.

Mihai

On Wed, Jul 29, 2015 at 6:04 PM, Ian Campbell <ian.campbell@citrix= .com> wrote:
On Wed, 2015-07-29 at 13:26 +0300, P=C3=AErvu Mihai wrote:
> Alright, here it is, hope we can sort this out:

Thanks, I took what you had, but using the lwip-1.3.0 + patches from=
xen.git/stubdom (just because they were to hand) and reprod what you've=
been seeing.

Then (on a hunch) I did "ethtool -K vif13.0 tx off" and it starte= d working.

So I think there must be a bug either in mini-os's netfront checksum offload, or in the negotiation it does with netback.

Hopefully that is enough for someone to be going on with.

Ian.

--001a1140ea86b859ed051c058bda-- --===============8240207702369924697== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8240207702369924697==-- From xen-users-bounces@lists.xen.org Wed Jul 29 21:17:26 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 21:17:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKYi5-0001l1-9y; Wed, 29 Jul 2015 21:16:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKYi3-0001kw-Jp for xen-users@lists.xen.org; Wed, 29 Jul 2015 21:16:20 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 79/84-15055-2A249B55; Wed, 29 Jul 2015 21:16:18 +0000 X-Env-Sender: hakon@alstadheim.priv.no X-Msg-Ref: server-15.tower-31.messagelabs.com!1438204577!30372537!1 X-Originating-IP: [109.247.116.9] X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6675 invoked from network); 29 Jul 2015 21:16:18 -0000 Received: from asav22.altibox.net (HELO asav22.altibox.net) (109.247.116.9) by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2015 21:16:18 -0000 Received: from localhost (localhost [127.0.0.1]) by asav22.altibox.net (Postfix) with ESMTP id CE0982026D; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) Received: from asav22.altibox.net ([127.0.0.1]) by localhost (asav22.lysetele.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s-lZeev6DtnH; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) Received: from postfix-relay.alstadheim.priv.no (178-164-66.9.3p.ntebredband.no [178.164.66.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon.alstadheim@ntebb.no) by asav22.altibox.net (Postfix) with ESMTPSA id 0DFD72027E; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no Received: from smtps.alstadheim.priv.no (localhost [127.0.0.1]) by postfix-relay.alstadheim.priv.no (Postfix) with ESMTP id 86B046801F9; Wed, 29 Jul 2015 23:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=alstadheim.priv.no; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=smtp; bh=ae6UcGVBmOHaQRTL4o1LvMSzKPo=; b=wtNoFLsbjBqfvkoiqCYS qjTRb36L9Kx1Xf5khKGswC+7IIzdUJN/efxBsr10UfeZL+vzptQ7dY5YOMipkiH7 WJwKPTOiH68M6g1YWGZMZUnNqPuGKBjmJUdnSrGH85slGWx0F0Vnq5XPBl3lk8B9 b/+ljg53+8atWkV2F+FCcfQ= Received: from [10.0.0.38] (ti0043a400-7782.bb.online.no [88.89.69.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon) by smtps.alstadheim.priv.no (Postfix) with ESMTPSA id 683166C0116; Wed, 29 Jul 2015 23:15:43 +0200 (CEST) References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <55B8CC51.4060207@magro-soft.com> Message-Id: <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> X-Mailer: iPad Mail (12H143) From: =?utf-8?Q?H=C3=A5kon_Alstadheim?= Date: Wed, 29 Jul 2015 23:16:13 +0200 To: Wolf Grossi Cc: "xen-users@lists.xen.org" , Zir Blazer Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org > Den 29. jul. 2015 kl. 14.51 skrev Wolf Grossi : > >> On 28.07.2015 17:52, Zir Blazer wrote: >> PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. >> > ... or use usbip. A bit clunky, but stable with low data-rate stuff in my experience. Don't try running a sound-card over usbip though. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 21:17:26 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 21:17:26 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKYi5-0001l1-9y; Wed, 29 Jul 2015 21:16:21 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKYi3-0001kw-Jp for xen-users@lists.xen.org; Wed, 29 Jul 2015 21:16:20 +0000 Received: from [85.158.137.68] by server-2.bemta-3.messagelabs.com id 79/84-15055-2A249B55; Wed, 29 Jul 2015 21:16:18 +0000 X-Env-Sender: hakon@alstadheim.priv.no X-Msg-Ref: server-15.tower-31.messagelabs.com!1438204577!30372537!1 X-Originating-IP: [109.247.116.9] X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6675 invoked from network); 29 Jul 2015 21:16:18 -0000 Received: from asav22.altibox.net (HELO asav22.altibox.net) (109.247.116.9) by server-15.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2015 21:16:18 -0000 Received: from localhost (localhost [127.0.0.1]) by asav22.altibox.net (Postfix) with ESMTP id CE0982026D; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) Received: from asav22.altibox.net ([127.0.0.1]) by localhost (asav22.lysetele.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id s-lZeev6DtnH; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) Received: from postfix-relay.alstadheim.priv.no (178-164-66.9.3p.ntebredband.no [178.164.66.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon.alstadheim@ntebb.no) by asav22.altibox.net (Postfix) with ESMTPSA id 0DFD72027E; Wed, 29 Jul 2015 23:16:17 +0200 (CEST) X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no Received: from smtps.alstadheim.priv.no (localhost [127.0.0.1]) by postfix-relay.alstadheim.priv.no (Postfix) with ESMTP id 86B046801F9; Wed, 29 Jul 2015 23:15:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=alstadheim.priv.no; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=smtp; bh=ae6UcGVBmOHaQRTL4o1LvMSzKPo=; b=wtNoFLsbjBqfvkoiqCYS qjTRb36L9Kx1Xf5khKGswC+7IIzdUJN/efxBsr10UfeZL+vzptQ7dY5YOMipkiH7 WJwKPTOiH68M6g1YWGZMZUnNqPuGKBjmJUdnSrGH85slGWx0F0Vnq5XPBl3lk8B9 b/+ljg53+8atWkV2F+FCcfQ= Received: from [10.0.0.38] (ti0043a400-7782.bb.online.no [88.89.69.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon) by smtps.alstadheim.priv.no (Postfix) with ESMTPSA id 683166C0116; Wed, 29 Jul 2015 23:15:43 +0200 (CEST) References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> Mime-Version: 1.0 (1.0) In-Reply-To: <55B8CC51.4060207@magro-soft.com> Message-Id: <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> X-Mailer: iPad Mail (12H143) From: =?utf-8?Q?H=C3=A5kon_Alstadheim?= Date: Wed, 29 Jul 2015 23:16:13 +0200 To: Wolf Grossi Cc: "xen-users@lists.xen.org" , Zir Blazer Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org > Den 29. jul. 2015 kl. 14.51 skrev Wolf Grossi : > >> On 28.07.2015 17:52, Zir Blazer wrote: >> PVUSB got broken in either Xen 4.4/4.5 if I recall correctly, and supposedly it was intended to be back in 4.6. In the meantime, a viable alternative is using a SPICE client (And setting up the VM accordingly) so you can use USB Redirection. >> > ... or use usbip. A bit clunky, but stable with low data-rate stuff in my experience. Don't try running a sound-card over usbip though. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Wed Jul 29 21:52:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 21:52:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKZG5-0004GE-FW; Wed, 29 Jul 2015 21:51:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKZG4-0004G9-2W for xen-users@lists.xen.org; Wed, 29 Jul 2015 21:51:28 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 52/D2-31450-FDA49B55; Wed, 29 Jul 2015 21:51:27 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1438206684!8800207!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32061 invoked from network); 29 Jul 2015 21:51:26 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2015 21:51:26 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6TLpObN012053 for ; Wed, 29 Jul 2015 16:51:24 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6TLpOuj031038 for ; Wed, 29 Jul 2015 16:51:24 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 29 Jul 2015 16:51:23 -0500 Message-ID: <55B94ADB.4090609@ti.com> Date: Wed, 29 Jul 2015 17:51:23 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------020501080008080604040503" X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues Changing the Dom0 Memory Size (Boot-time) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020501080008080604040503 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello All, To begin, here's my system setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Repo: git://git.omapzoom.org/kernel/omap.git - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 I'm experiencing some issues when I try to change the initial amount of memory allocated to Dom0 by Xen, using the "dom0_mem" parameter on the command line. I know that 128 MB is the traditional size to use for Dom0, but my Dom0 needs some additional memory due to large CMA areas that are reserved by coprocessors on the chip. The chip I'm using has a total of 1GB of memory. The target size I'm shooting for is 256 MB. However, this isn't the only size that causes me issues. For most other sizes, even if they are smaller, I have issues booting the kernel. It crashes almost immediately. Some other sizes I have tried: 64 MB, 192 MB, 224 MB, 512 MB. The only other size I could get to work was 132 MB. I tried other sizes too, but the choice of sizes is of course limited as per [1] I've attached the boot log from when I boot with 256 MB of memory. The extra print at the end was a printk I added to do_trap_hypervisor(). (XEN) Instruction abort from kernel. regs->pc: 0x97a00000, regs->hsr.ec: 32, regs->hsr.iss=0x0000000e As you can see from the log, 0x97a00000 is the entry point of the Dom0 kernel. I've stepped through the code with a debugger to confirm that this is the source of the fault. The execution of the first instruction in the kernel is causing a prefetch abort. Looking at the ISS bits, this indicates that the problem comes from improper permissions on that page. Since the kernel doesn't even get to run a single instruction, this leads me to believe that the problem is likely coming from Xen, somehow related to allocate_memory_11(). It's odd that 128 MB works, but any other size, even if its only on a single memory bank like 128 MB, fails. The only difference between the 128 MB and 256 MB boots is that the zImage is relocated to a different VA than the 128 MB. However, when booting with 64 MB, the zImage VA is the same as the 128 MB boot, but the same issue occurs. I've attached the boot logs from 64 MB, 128 MB, and 256 MB boots. I was hoping to get some guidance on what might be causing this bug before trying to dive deeper into the code. Thanks, Brandon Perez [1] http://xen.markmail.org/message/ldamhobnot5jfdnc#query:+page:1+mid:6chbukafg5wn2ewe+state:results --------------020501080008080604040503 Content-Type: text/x-log; name="boot_64.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_64.log" Unknown command 'ATZ' - try 'help' U-Boot# AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 syntax error U-Boot# printenv d xn enb - _bootargs xen_bootargs=sync_console console=dtuart dtuart=serial0 dom0_mem=256M U-Boot# setenv xen_bootargs "sync_console console=dtuart dtuart=serial0 dom0_mem=256M    64M" U-Boot# boot reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 237 ms (18.4 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 dom0_mem=64M (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 64MB for dom0: (XEN) BANK[0] 0x000000a4000000-0x000000a8000000 (64MB) (XEN) Loading zImage from 00000000a0000000 to 00000000a7a00000-00000000a7e5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x00000000a7800000-0x00000000a7815fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) Data abort from kernel. regs->pc: 0xa7a003d8, regs->hsr.ec: 36, regs->hsr.iss=0x00000046, gva=0xa0004000, gpa=0x00a00040 (XEN) traps.c:2418:d0v0 HSR=0x90000046 pc=0xa7a003d8 gva=0xa0004000 gpa=0x000000a0004000 --------------020501080008080604040503 Content-Type: text/x-log; name="boot_128.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_128.log" U-Boot SPL 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) DRA722 ES1.0 spl_mmc_load_image reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) CPU : DRA722 ES1.0 Board: DRA7xx I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst scanning bus for devices... Found 0 device(s). 256 128K xloader 512 384K bootloader 1280 128K environment 1536 128K misc 2560 16M efs 35328 16K crypto 35360 10M recovery 55840 10M boot 76320 768M system 1649184 256M cache 2173472 1024K ipu1 2175520 1024K ipu2 2177568 6360M userdata SCSI: Net: cpsw Hit any key to stop autoboot: 3  2  0 U-Boot# printenv xen_bootargs xen_bootargs=sync_console console=dtuart dtuart=serial0 dom0_mem=256M U-Boot# set  env xenb _bootargs "sync_console console=dtuart dtuart=serial0 dom0_mem=256M    128             " U-Boot# boot reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 237 ms (18.4 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000a8000000-0x000000b0000000 (128MB) (XEN) Loading zImage from 00000000a0000000 to 00000000afa00000-00000000afe5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x00000000af800000-0x00000000af815fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. --------------020501080008080604040503 Content-Type: text/x-log; name="boot_256.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_256.log" Unknown command 'ATZ' - try 'help' U-Boot# AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 syntax error U-Boot# U-Boot SPL 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) DRA722 ES1.0 spl_mmc_load_image reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) CPU : DRA722 ES1.0 Board: DRA7xx I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst scanning bus for devices... Found 0 device(s). 256 128K xloader 512 384K bootloader 1280 128K environment 1536 128K misc 2560 16M efs 35328 16K crypto 35360 10M recovery 55840 10M boot 76320 768M system 1649184 256M cache 2173472 1024K ipu1 2175520 1024K ipu2 2177568 6360M userdata SCSI: Net: cpsw Hit any key to stop autoboot: 3  2  1  0 reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 236 ms (18.5 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 dom0_mem=256M (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 256MB for dom0: (XEN) BANK[0] 0x00000090000000-0x000000a0000000 (256MB) (XEN) Loading zImage from 00000000a0000000 to 0000000097a00000-0000000097e5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x0000000098000000-0x0000000098015fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) Instruction abort from kernel. regs->pc: 0x97a00000, regs->hsr.ec: 32, regs->hsr.iss=0x0000000e --------------020501080008080604040503 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020501080008080604040503-- From xen-users-bounces@lists.xen.org Wed Jul 29 21:52:44 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Wed, 29 Jul 2015 21:52:44 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKZG5-0004GE-FW; Wed, 29 Jul 2015 21:51:29 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKZG4-0004G9-2W for xen-users@lists.xen.org; Wed, 29 Jul 2015 21:51:28 +0000 Received: from [85.158.139.211] by server-2.bemta-5.messagelabs.com id 52/D2-31450-FDA49B55; Wed, 29 Jul 2015 21:51:27 +0000 X-Env-Sender: b-perez1@ti.com X-Msg-Ref: server-15.tower-206.messagelabs.com!1438206684!8800207!1 X-Originating-IP: [198.47.26.152] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMTk4LjQ3LjI2LjE1MiA9PiAxNjQ5NzY=\n X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 32061 invoked from network); 29 Jul 2015 21:51:26 -0000 Received: from comal.ext.ti.com (HELO comal.ext.ti.com) (198.47.26.152) by server-15.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2015 21:51:26 -0000 Received: from dflxv15.itg.ti.com ([128.247.5.124]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id t6TLpObN012053 for ; Wed, 29 Jul 2015 16:51:24 -0500 Received: from DLEE70.ent.ti.com (dlemailx.itg.ti.com [157.170.170.113]) by dflxv15.itg.ti.com (8.14.3/8.13.8) with ESMTP id t6TLpOuj031038 for ; Wed, 29 Jul 2015 16:51:24 -0500 Received: from [128.247.93.131] (128.247.93.131) by DLEE70.ent.ti.com (157.170.170.113) with Microsoft SMTP Server id 14.3.224.2; Wed, 29 Jul 2015 16:51:23 -0500 Message-ID: <55B94ADB.4090609@ti.com> Date: Wed, 29 Jul 2015 17:51:23 -0400 From: Brandon Perez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Content-Type: multipart/mixed; boundary="------------020501080008080604040503" X-Originating-IP: [128.247.93.131] Subject: [Xen-users] [Xen-Users] Issues Changing the Dom0 Memory Size (Boot-time) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --------------020501080008080604040503 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Hello All, To begin, here's my system setup: - Hardware: TI DRA72 Chip, Arm Cortex A15 - Xen: - Version: 4.6-unstable - Compiled from source, with some local changes - Branch: master - Linux Kernel: - Version: 3.14 - Compiled From source, with some local changes - Repo: git://git.omapzoom.org/kernel/omap.git - Branch: android-3.14-6AL.1.0 - Commit: 7b2f1133857414b96927c06f08ed6c440f5472e7 I'm experiencing some issues when I try to change the initial amount of memory allocated to Dom0 by Xen, using the "dom0_mem" parameter on the command line. I know that 128 MB is the traditional size to use for Dom0, but my Dom0 needs some additional memory due to large CMA areas that are reserved by coprocessors on the chip. The chip I'm using has a total of 1GB of memory. The target size I'm shooting for is 256 MB. However, this isn't the only size that causes me issues. For most other sizes, even if they are smaller, I have issues booting the kernel. It crashes almost immediately. Some other sizes I have tried: 64 MB, 192 MB, 224 MB, 512 MB. The only other size I could get to work was 132 MB. I tried other sizes too, but the choice of sizes is of course limited as per [1] I've attached the boot log from when I boot with 256 MB of memory. The extra print at the end was a printk I added to do_trap_hypervisor(). (XEN) Instruction abort from kernel. regs->pc: 0x97a00000, regs->hsr.ec: 32, regs->hsr.iss=0x0000000e As you can see from the log, 0x97a00000 is the entry point of the Dom0 kernel. I've stepped through the code with a debugger to confirm that this is the source of the fault. The execution of the first instruction in the kernel is causing a prefetch abort. Looking at the ISS bits, this indicates that the problem comes from improper permissions on that page. Since the kernel doesn't even get to run a single instruction, this leads me to believe that the problem is likely coming from Xen, somehow related to allocate_memory_11(). It's odd that 128 MB works, but any other size, even if its only on a single memory bank like 128 MB, fails. The only difference between the 128 MB and 256 MB boots is that the zImage is relocated to a different VA than the 128 MB. However, when booting with 64 MB, the zImage VA is the same as the 128 MB boot, but the same issue occurs. I've attached the boot logs from 64 MB, 128 MB, and 256 MB boots. I was hoping to get some guidance on what might be causing this bug before trying to dive deeper into the code. Thanks, Brandon Perez [1] http://xen.markmail.org/message/ldamhobnot5jfdnc#query:+page:1+mid:6chbukafg5wn2ewe+state:results --------------020501080008080604040503 Content-Type: text/x-log; name="boot_64.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_64.log" Unknown command 'ATZ' - try 'help' U-Boot# AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 syntax error U-Boot# printenv d xn enb - _bootargs xen_bootargs=sync_console console=dtuart dtuart=serial0 dom0_mem=256M U-Boot# setenv xen_bootargs "sync_console console=dtuart dtuart=serial0 dom0_mem=256M    64M" U-Boot# boot reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 237 ms (18.4 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 dom0_mem=64M (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 64MB for dom0: (XEN) BANK[0] 0x000000a4000000-0x000000a8000000 (64MB) (XEN) Loading zImage from 00000000a0000000 to 00000000a7a00000-00000000a7e5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x00000000a7800000-0x00000000a7815fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) Data abort from kernel. regs->pc: 0xa7a003d8, regs->hsr.ec: 36, regs->hsr.iss=0x00000046, gva=0xa0004000, gpa=0x00a00040 (XEN) traps.c:2418:d0v0 HSR=0x90000046 pc=0xa7a003d8 gva=0xa0004000 gpa=0x000000a0004000 --------------020501080008080604040503 Content-Type: text/x-log; name="boot_128.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_128.log" U-Boot SPL 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) DRA722 ES1.0 spl_mmc_load_image reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) CPU : DRA722 ES1.0 Board: DRA7xx I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst scanning bus for devices... Found 0 device(s). 256 128K xloader 512 384K bootloader 1280 128K environment 1536 128K misc 2560 16M efs 35328 16K crypto 35360 10M recovery 55840 10M boot 76320 768M system 1649184 256M cache 2173472 1024K ipu1 2175520 1024K ipu2 2177568 6360M userdata SCSI: Net: cpsw Hit any key to stop autoboot: 3  2  0 U-Boot# printenv xen_bootargs xen_bootargs=sync_console console=dtuart dtuart=serial0 dom0_mem=256M U-Boot# set  env xenb _bootargs "sync_console console=dtuart dtuart=serial0 dom0_mem=256M    128             " U-Boot# boot reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 237 ms (18.4 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 128MB for dom0: (XEN) BANK[0] 0x000000a8000000-0x000000b0000000 (128MB) (XEN) Loading zImage from 00000000a0000000 to 00000000afa00000-00000000afe5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x00000000af800000-0x00000000af815fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. --------------020501080008080604040503 Content-Type: text/x-log; name="boot_256.log" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="boot_256.log" Unknown command 'ATZ' - try 'help' U-Boot# AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0 syntax error U-Boot# U-Boot SPL 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) DRA722 ES1.0 spl_mmc_load_image reading args spl_load_image_fat_os: error reading image args, err - -1 reading u-boot.img reading u-boot.img U-Boot 2014.07-00003-g6dc444a-dirty (Jul 20 2015 - 16:46:53) CPU : DRA722 ES1.0 Board: DRA7xx I2C: ready DRAM: 1 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode flags: 64bit ncq stag pm led clo only pmp pio slum part ccc apst scanning bus for devices... Found 0 device(s). 256 128K xloader 512 384K bootloader 1280 128K environment 1536 128K misc 2560 16M efs 35328 16K crypto 35360 10M recovery 55840 10M boot 76320 768M system 1649184 256M cache 2173472 1024K ipu1 2175520 1024K ipu2 2177568 6360M userdata SCSI: Net: cpsw Hit any key to stop autoboot: 3  2  1  0 reading dra72-evm-lcd10.dtb 90337 bytes read in 10 ms (8.6 MiB/s) reading xen-uImage 754608 bytes read in 43 ms (16.7 MiB/s) reading zImage 4581184 bytes read in 236 ms (18.5 MiB/s) ## Booting kernel from Legacy Image at 90000000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 754544 Bytes = 736.9 KiB Load Address: 80200000 Entry Point: 80200000 Verifying Checksum ... OK ## Flattened Device Tree blob at 825f0000 Booting using the fdt blob at 0x825f0000 Loading Kernel Image ... OK reserving fdt memory region: addr=825f0000 size=17000 Loading Device Tree to 8ffe6000, end 8fffffff ... OK Starting kernel ... - UART enabled - - CPU 00000000 booting - - Xen starting in Hyp mode - - Zero BSS - - Setting up control registers - - Turning on paging - - Ready - (XEN) Checking for initrd in /chosen (XEN) RAM: 0000000080000000 - 00000000bfffffff (XEN) (XEN) MODULE[0]: 000000008ffe6000 - 000000008fffd000 Device Tree (XEN) MODULE[1]: 00000000a0000000 - 00000000a0a00000 Kernel (XEN) RESVD[0]: 00000000825f0000 - 0000000082607000 (XEN) RESVD[1]: 000000008ffe6000 - 000000008fffd000 (XEN) (XEN) Command line: sync_console console=dtuart dtuart=serial0 dom0_mem=256M (XEN) Placing Xen at 0x00000000bfe00000-0x00000000c0000000 (XEN) Update BOOTMOD_XEN from 0000000080200000-0000000080301701 => 00000000bfe00000-00000000bff01701 (XEN) Xen heap: 00000000bc000000-00000000be000000 (8192 pages) (XEN) Dom heap: 253952 pages (XEN) Domain heap initialised (XEN) Platform: TI DRA7 (XEN) Looking for dtuart at "serial0", options "" Xen 4.6-unstable (XEN) Xen version 4.6-unstable (brandonlocal@) (arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3) debug=y Wed Jul 29 17:34:16 EDT 2015 (XEN) Latest ChangeSet: Mon Jul 20 18:25:35 2015 -0400 git:f7ff6a8-dirty (XEN) Console output is synchronous. (XEN) Processor: 412fc0f2: "ARM Limited", variant: 0x2, part 0xc0f, rev 0x2 (XEN) 32-bit Execution: (XEN) Processor Features: 00001131:00011011 (XEN) Instruction Sets: AArch32 A32 Thumb Thumb-2 ThumbEE Jazelle (XEN) Extensions: GenericTimer Security (XEN) Debug Features: 02010555 (XEN) Auxiliary Features: 00000000 (XEN) Memory Model Features: 10201105 20000000 01240000 02102211 (XEN) ISA Features: 02101110 13112111 21232041 11112131 10011142 00000000 (XEN) Set AuxCoreBoot1 to 00000000bfe0004c (0020004c) (XEN) Set AuxCoreBoot0 to 0x20 (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27 Freq: 6147 KHz (XEN) GICv2 initialization: (XEN) gic_dist_addr=0000000048211000 (XEN) gic_cpu_addr=0000000048212000 (XEN) gic_hyp_addr=0000000048214000 (XEN) gic_vcpu_addr=0000000048216000 (XEN) gic_maintenance_irq=25 (XEN) GICv2: 192 lines, 1 cpu, secure (IID 0000043b). (XEN) Using scheduler: SMP Credit Scheduler (credit) (XEN) Allocated console ring of 16 KiB. (XEN) VFP implementer 0x41 architecture 4 part 0x30 variant 0xf rev 0x0 (XEN) Brought up 1 CPUs (XEN) P2M: 40-bit IPA (XEN) P2M: 3 levels with order-1 root, VTCR 0x80003558 (XEN) I/O virtualisation disabled (XEN) *** LOADING DOMAIN 0 *** (XEN) Loading kernel from boot module @ 00000000a0000000 (XEN) Allocating 1:1 mappings totalling 256MB for dom0: (XEN) BANK[0] 0x00000090000000-0x000000a0000000 (256MB) (XEN) Loading zImage from 00000000a0000000 to 0000000097a00000-0000000097e5e740 (XEN) Allocating PPI 16 for event channel interrupt (XEN) Loading dom0 DTB to 0x0000000098000000-0x0000000098015fa7 (XEN) Scrubbing Free RAM on 1 nodes using 1 CPUs (XEN) ........done. (XEN) Initial low memory virq threshold set at 0x4000 pages. (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) ********************************************** (XEN) ******* WARNING: CONSOLE OUTPUT IS SYNCHRONOUS (XEN) ******* This option is intended to aid debugging of Xen by ensuring (XEN) ******* that all output is synchronously delivered on the serial line. (XEN) ******* However it can introduce SIGNIFICANT latencies and affect (XEN) ******* timekeeping. It is NOT recommended for production use! (XEN) ********************************************** (XEN) 3... 2... 1... (XEN) *** Serial input -> DOM0 (type 'CTRL-a' three times to switch input to Xen) (XEN) Freed 284kB init memory. (XEN) Instruction abort from kernel. regs->pc: 0x97a00000, regs->hsr.ec: 32, regs->hsr.iss=0x0000000e --------------020501080008080604040503 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --------------020501080008080604040503-- From xen-users-bounces@lists.xen.org Thu Jul 30 10:30:25 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 10:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKl5c-0002CZ-AN; Thu, 30 Jul 2015 10:29:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKl5b-0002CH-1W for xen-users@lists.xenproject.org; Thu, 30 Jul 2015 10:29:27 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 84/D6-28791-68CF9B55; Thu, 30 Jul 2015 10:29:26 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1438252165!30399196!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=1.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE, HTML_OBFUSCATE_05_10 X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16127 invoked from network); 30 Jul 2015 10:29:25 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Jul 2015 10:29:25 -0000 Received: by wibxm9 with SMTP id xm9so238167897wib.0 for ; Thu, 30 Jul 2015 03:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ja38q90ZPkX4aZu61LTsMBUXYzisvgbagrIWAIDcKCk=; b=DFb3WBhPpS3ODUkGFkEOmugZy487WRrVCnvdtr/7a2/3a008/iS1nKdzweyafsJGax UGxa2xRsdv3rYIk0rJii7dktfG0KtWFOGqV4AL6LN8X9UeTcE1g6L9nq1/GMVZ0NT5s7 ezHW/+Jwudz4BgST9k1VuGOB/uGPJv7tddNOZYKuxczbBtSQb3IALTo0RPdXShh52Z7r 0O5IjPQFeir97uzmtcejP1ZlwbWU4gf/TbV2PxNoBPTTNQCIuiJxKrPBQyr3APZBNjrQ 2WuT3zIU4KkQ/NQfCg/vfpHED6kamjFNyfxJfsjosahVxlvvATCn6WjJmK7njER2vnIp REYQ== X-Received: by 10.180.101.138 with SMTP id fg10mr5093483wib.46.1438252165031; Thu, 30 Jul 2015 03:29:25 -0700 (PDT) Received: from [192.168.0.8] (97e55056.skybroadband.com. [151.229.80.86]) by smtp.gmail.com with ESMTPSA id gw7sm29114247wib.15.2015.07.30.03.29.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 03:29:23 -0700 (PDT) From: Lars Kurth Message-Id: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> Date: Thu, 30 Jul 2015 11:29:22 +0100 To: Xen Devel , xen-users@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Xen-users] Vote for Xen talks at OpenStack summit (deadline today) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4810129993420424216==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4810129993420424216== Content-Type: multipart/alternative; boundary="Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67" --Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So far, I am aware of one talk. Note that the OpenStack summit agenda's = are determined by popular vote (which ends today). If there are others Xen related talks, feel free to add by replying to = this mail = https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation= /6150 = --Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
So far, I am aware of one talk. Note that the OpenStack summit agenda's are determined by popular vote (which ends today).

If there are others Xen related talks, feel free to add by replying to this mail
https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/6150

--Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67-- --===============4810129993420424216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4810129993420424216==-- From xen-users-bounces@lists.xen.org Thu Jul 30 10:30:25 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 10:30:25 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKl5c-0002CZ-AN; Thu, 30 Jul 2015 10:29:28 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKl5b-0002CH-1W for xen-users@lists.xenproject.org; Thu, 30 Jul 2015 10:29:27 +0000 Received: from [193.109.254.147] by server-1.bemta-14.messagelabs.com id 84/D6-28791-68CF9B55; Thu, 30 Jul 2015 10:29:26 +0000 X-Env-Sender: lars.kurth.xen@gmail.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1438252165!30399196!1 X-Originating-IP: [209.85.212.173] X-SpamReason: No, hits=1.6 required=7.0 tests=HTML_50_60,HTML_MESSAGE, HTML_OBFUSCATE_05_10 X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16127 invoked from network); 30 Jul 2015 10:29:25 -0000 Received: from mail-wi0-f173.google.com (HELO mail-wi0-f173.google.com) (209.85.212.173) by server-11.tower-27.messagelabs.com with RC4-SHA encrypted SMTP; 30 Jul 2015 10:29:25 -0000 Received: by wibxm9 with SMTP id xm9so238167897wib.0 for ; Thu, 30 Jul 2015 03:29:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=ja38q90ZPkX4aZu61LTsMBUXYzisvgbagrIWAIDcKCk=; b=DFb3WBhPpS3ODUkGFkEOmugZy487WRrVCnvdtr/7a2/3a008/iS1nKdzweyafsJGax UGxa2xRsdv3rYIk0rJii7dktfG0KtWFOGqV4AL6LN8X9UeTcE1g6L9nq1/GMVZ0NT5s7 ezHW/+Jwudz4BgST9k1VuGOB/uGPJv7tddNOZYKuxczbBtSQb3IALTo0RPdXShh52Z7r 0O5IjPQFeir97uzmtcejP1ZlwbWU4gf/TbV2PxNoBPTTNQCIuiJxKrPBQyr3APZBNjrQ 2WuT3zIU4KkQ/NQfCg/vfpHED6kamjFNyfxJfsjosahVxlvvATCn6WjJmK7njER2vnIp REYQ== X-Received: by 10.180.101.138 with SMTP id fg10mr5093483wib.46.1438252165031; Thu, 30 Jul 2015 03:29:25 -0700 (PDT) Received: from [192.168.0.8] (97e55056.skybroadband.com. [151.229.80.86]) by smtp.gmail.com with ESMTPSA id gw7sm29114247wib.15.2015.07.30.03.29.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 30 Jul 2015 03:29:23 -0700 (PDT) From: Lars Kurth Message-Id: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> Date: Thu, 30 Jul 2015 11:29:22 +0100 To: Xen Devel , xen-users@lists.xenproject.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Subject: [Xen-users] Vote for Xen talks at OpenStack summit (deadline today) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4810129993420424216==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4810129993420424216== Content-Type: multipart/alternative; boundary="Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67" --Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So far, I am aware of one talk. Note that the OpenStack summit agenda's = are determined by popular vote (which ends today). If there are others Xen related talks, feel free to add by replying to = this mail = https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation= /6150 = --Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
So far, I am aware of one talk. Note that the OpenStack summit agenda's are determined by popular vote (which ends today).

If there are others Xen related talks, feel free to add by replying to this mail
https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/6150

--Apple-Mail=_7D0872A4-6C08-44B7-969D-2717EF8D2B67-- --===============4810129993420424216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4810129993420424216==-- From xen-users-bounces@lists.xen.org Thu Jul 30 14:25:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 14:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKokd-0008A4-I6; Thu, 30 Jul 2015 14:24:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKml3-0000rd-Ju for xen-users@lists.xenproject.org; Thu, 30 Jul 2015 12:16:21 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 2B/60-02380-4951AB55; Thu, 30 Jul 2015 12:16:20 +0000 X-Env-Sender: jgross@suse.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1438258580!20563165!1 X-Originating-IP: [195.135.220.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1529 invoked from network); 30 Jul 2015 12:16:20 -0000 Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2015 12:16:20 -0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4731FAAF6; Thu, 30 Jul 2015 12:16:19 +0000 (UTC) From: Juergen Gross To: Lars Kurth , Xen Devel , xen-users@lists.xenproject.org References: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> Message-ID: <55BA1591.2020909@suse.com> Date: Thu, 30 Jul 2015 14:16:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> X-Mailman-Approved-At: Thu, 30 Jul 2015 14:24:02 +0000 Subject: Re: [Xen-users] [Xen-devel] Vote for Xen talks at OpenStack summit (deadline today) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/30/2015 12:29 PM, Lars Kurth wrote: > So far, I am aware of one talk. Note that the OpenStack summit agenda's > are determined by popular vote (which ends today). > > If there are others Xen related talks, feel free to add by replying to > this mail > https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/6150 https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/5743 Juergen _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 30 14:25:18 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 14:25:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKokd-0008A4-I6; Thu, 30 Jul 2015 14:24:03 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKml3-0000rd-Ju for xen-users@lists.xenproject.org; Thu, 30 Jul 2015 12:16:21 +0000 Received: from [85.158.139.211] by server-17.bemta-5.messagelabs.com id 2B/60-02380-4951AB55; Thu, 30 Jul 2015 12:16:20 +0000 X-Env-Sender: jgross@suse.com X-Msg-Ref: server-11.tower-206.messagelabs.com!1438258580!20563165!1 X-Originating-IP: [195.135.220.15] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1529 invoked from network); 30 Jul 2015 12:16:20 -0000 Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by server-11.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2015 12:16:20 -0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 4731FAAF6; Thu, 30 Jul 2015 12:16:19 +0000 (UTC) From: Juergen Gross To: Lars Kurth , Xen Devel , xen-users@lists.xenproject.org References: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> Message-ID: <55BA1591.2020909@suse.com> Date: Thu, 30 Jul 2015 14:16:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <920FB898-3AA4-4F5F-BABA-8A1A076319CE@gmail.com> X-Mailman-Approved-At: Thu, 30 Jul 2015 14:24:02 +0000 Subject: Re: [Xen-users] [Xen-devel] Vote for Xen talks at OpenStack summit (deadline today) X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On 07/30/2015 12:29 PM, Lars Kurth wrote: > So far, I am aware of one talk. Note that the OpenStack summit agenda's > are determined by popular vote (which ends today). > > If there are others Xen related talks, feel free to add by replying to > this mail > https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/6150 https://www.openstack.org/summit/tokyo-2015/vote-for-speakers/Presentation/5743 Juergen _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 30 14:30:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 14:30:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKoqU-0000Jp-HJ; Thu, 30 Jul 2015 14:30:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKoqT-0000Jj-3p for xen-users@lists.xen.org; Thu, 30 Jul 2015 14:30:05 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id BD/13-10715-CE43AB55; Thu, 30 Jul 2015 14:30:04 +0000 X-Env-Sender: Karl.Apsite@dornerworks.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1438266603!35132823!1 X-Originating-IP: [12.207.209.148] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5252 invoked from network); 30 Jul 2015 14:30:03 -0000 Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148) by server-4.tower-27.messagelabs.com with SMTP; 30 Jul 2015 14:30:03 -0000 Received: from [172.27.11.45] (172.27.11.45) by mail.dornerworks.com (172.27.1.90) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 30 Jul 2015 10:29:12 -0400 Message-ID: <55BA34E9.4070507@dornerworks.com> Date: Thu, 30 Jul 2015 10:30:01 -0400 From: Karl Apsite User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> In-Reply-To: <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> X-Originating-IP: [172.27.11.45] Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Pk9uIDA3LzI5LzIwMTUgMDU6MTYgUE0sIEjDpWtvbiBBbHN0YWRoZWltIHdyb3RlOgo+IAo+PiBE ZW4gMjkuIGp1bC4gMjAxNSBrbC4gMTQuNTEgc2tyZXYgV29sZiBHcm9zc2kgPHdnQG1hZ3JvLXNv ZnQuY29tPjoKPj4KPj4+IE9uIDI4LjA3LjIwMTUgMTc6NTIsIFppciBCbGF6ZXIgd3JvdGU6Cj4+ PiBQVlVTQiBnb3QgYnJva2VuIGluIGVpdGhlciBYZW4gNC40LzQuNSBpZiBJIHJlY2FsbCBjb3Jy ZWN0bHksIGFuZCBzdXBwb3NlZGx5IGl0IHdhcyBpbnRlbmRlZCB0byBiZSBiYWNrIGluIDQuNi4g SW4gdGhlIG1lYW50aW1lLCBhIHZpYWJsZSBhbHRlcm5hdGl2ZSBpcyB1c2luZyBhIFNQSUNFIGNs aWVudCAoQW5kIHNldHRpbmcgdXAgdGhlIFZNIGFjY29yZGluZ2x5KSBzbyB5b3UgY2FuIHVzZSBV U0IgUmVkaXJlY3Rpb24uCj4+Pgo+Pgo+IC4uLiBvciB1c2UgdXNiaXAuIEEgYml0IGNsdW5reSwg YnV0IHN0YWJsZSB3aXRoIGxvdyBkYXRhLXJhdGUgc3R1ZmYgaW4gbXkgZXhwZXJpZW5jZS4gRG9u J3QgdHJ5IHJ1bm5pbmcgYSBzb3VuZC1jYXJkIG92ZXIgdXNiaXAgdGhvdWdoLgoKSXNuJ3QgdGhh dCBhIHNwZWNpZmljIFhlblNlcnZlciBmdW5jdGlvbi9kcml2ZXI/ICBBcmUgdGhlcmUgaW5zdHJ1 Y3Rpb25zIHRvCmVuYWJsZSB0aGUga2VybmVsIG1vZHVsZSwgYW5kIGluc3RhbGwgdGhlIGRyaXZl ciBpbiBhIG5vbi1YZW5TZXJ2ZXIgc2V0dXA/CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Thu Jul 30 14:30:20 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 14:30:20 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKoqU-0000Jp-HJ; Thu, 30 Jul 2015 14:30:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKoqT-0000Jj-3p for xen-users@lists.xen.org; Thu, 30 Jul 2015 14:30:05 +0000 Received: from [193.109.254.147] by server-4.bemta-14.messagelabs.com id BD/13-10715-CE43AB55; Thu, 30 Jul 2015 14:30:04 +0000 X-Env-Sender: Karl.Apsite@dornerworks.com X-Msg-Ref: server-4.tower-27.messagelabs.com!1438266603!35132823!1 X-Originating-IP: [12.207.209.148] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 5252 invoked from network); 30 Jul 2015 14:30:03 -0000 Received: from unknown (HELO mail.dornerworks.com) (12.207.209.148) by server-4.tower-27.messagelabs.com with SMTP; 30 Jul 2015 14:30:03 -0000 Received: from [172.27.11.45] (172.27.11.45) by mail.dornerworks.com (172.27.1.90) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 30 Jul 2015 10:29:12 -0400 Message-ID: <55BA34E9.4070507@dornerworks.com> Date: Thu, 30 Jul 2015 10:30:01 -0400 From: Karl Apsite User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> In-Reply-To: <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> X-Originating-IP: [172.27.11.45] Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Pk9uIDA3LzI5LzIwMTUgMDU6MTYgUE0sIEjDpWtvbiBBbHN0YWRoZWltIHdyb3RlOgo+IAo+PiBE ZW4gMjkuIGp1bC4gMjAxNSBrbC4gMTQuNTEgc2tyZXYgV29sZiBHcm9zc2kgPHdnQG1hZ3JvLXNv ZnQuY29tPjoKPj4KPj4+IE9uIDI4LjA3LjIwMTUgMTc6NTIsIFppciBCbGF6ZXIgd3JvdGU6Cj4+ PiBQVlVTQiBnb3QgYnJva2VuIGluIGVpdGhlciBYZW4gNC40LzQuNSBpZiBJIHJlY2FsbCBjb3Jy ZWN0bHksIGFuZCBzdXBwb3NlZGx5IGl0IHdhcyBpbnRlbmRlZCB0byBiZSBiYWNrIGluIDQuNi4g SW4gdGhlIG1lYW50aW1lLCBhIHZpYWJsZSBhbHRlcm5hdGl2ZSBpcyB1c2luZyBhIFNQSUNFIGNs aWVudCAoQW5kIHNldHRpbmcgdXAgdGhlIFZNIGFjY29yZGluZ2x5KSBzbyB5b3UgY2FuIHVzZSBV U0IgUmVkaXJlY3Rpb24uCj4+Pgo+Pgo+IC4uLiBvciB1c2UgdXNiaXAuIEEgYml0IGNsdW5reSwg YnV0IHN0YWJsZSB3aXRoIGxvdyBkYXRhLXJhdGUgc3R1ZmYgaW4gbXkgZXhwZXJpZW5jZS4gRG9u J3QgdHJ5IHJ1bm5pbmcgYSBzb3VuZC1jYXJkIG92ZXIgdXNiaXAgdGhvdWdoLgoKSXNuJ3QgdGhh dCBhIHNwZWNpZmljIFhlblNlcnZlciBmdW5jdGlvbi9kcml2ZXI/ICBBcmUgdGhlcmUgaW5zdHJ1 Y3Rpb25zIHRvCmVuYWJsZSB0aGUga2VybmVsIG1vZHVsZSwgYW5kIGluc3RhbGwgdGhlIGRyaXZl ciBpbiBhIG5vbi1YZW5TZXJ2ZXIgc2V0dXA/CgpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpYZW4tdXNlcnMgbWFpbGluZyBsaXN0Clhlbi11c2Vyc0BsaXN0 cy54ZW4ub3JnCmh0dHA6Ly9saXN0cy54ZW4ub3JnL3hlbi11c2Vycw== From xen-users-bounces@lists.xen.org Thu Jul 30 16:12:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 16:12:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKqQR-0007w5-C0; Thu, 30 Jul 2015 16:11:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKqQP-0007w0-LM for xen-users@lists.xen.org; Thu, 30 Jul 2015 16:11:17 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 83/9E-09570-4AC4AB55; Thu, 30 Jul 2015 16:11:16 +0000 X-Env-Sender: zir_blazer@hotmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1438272665!30751767!1 X-Originating-IP: [65.55.90.82] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, FORGED_HOTMAIL_RCVD X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15742 invoked from network); 30 Jul 2015 16:11:07 -0000 Received: from snt004-omc2s7.hotmail.com (HELO SNT004-OMC2S7.hotmail.com) (65.55.90.82) by server-12.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 30 Jul 2015 16:11:07 -0000 Received: from SNT151-W3 ([65.55.90.73]) by SNT004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 30 Jul 2015 09:11:04 -0700 X-TMN: [N22Me7kRhBTr3vKR7oM3I3GA61iYcwqJR/8jYUkB25k=] X-Originating-Email: [zir_blazer@hotmail.com] Message-ID: From: Zir Blazer To: "xen-users@lists.xen.org" Date: Thu, 30 Jul 2015 13:11:04 -0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2015 16:11:04.0562 (UTC) FILETIME=[55DB9D20:01D0CAE2] Subject: [Xen-users] Xen 4.5, SeaBIOS, Radeon 5770 VGA Passthrough and Windows 10... Works. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Initially, I wasn't going to pay any attention to Windows 10 release, but coincidentally, since 3 weeks or so ago, I started to have some really annoying issues with the GPLPV NIC, which crashes near constantly on my main WXP x64 VM since I installed a game (Path of Exile). I have to disable the NIC from Network Connections and reenable it again for it to work, a disruption which makes online gaming a pain in the butt, and to add insult to the injury, the Driver crashes seems to be predictable, since usually I have a sucession of crashes that consistently happens after some elapsed time (Usually 45 minutes). I recall having had a near identical issue around a year ago or so, but got solved upgrading the GPLPV Drivers (From GPLPV 0.11.0.372 to EJBPV 1.0.1105), which I'm currently using. As the webpage of the GPLPV Drivers dissapeared some months ago and I didn't hear anything else from the author, I don't think I can get any support on this one even if I wanted to run the debug Drivers to try to track what the hell is making it crash like this. Worse yet, I also got stuck on the uninstall procedure, since even if the GPLPV Drivers gets removed and there is no /GPLPV on WXP line in boot.ini, Windows still insist on detecting unknow devices like the NIC attached to XenBus instead of the standard QEMU emulated devices, so I could not try using the Realtek RTL8139 or Intel e1000 to see if they behave the same. Setting xen_platform_pci = 0 on the DomU Config File makes WXP x64 BSOD on boot. Yet, on a fresh Windows install with xen_platform_pci = 1, it sees the QEMU emulated devices before installing the GPLPV Drivers, so it seems that it permanently changes something that makes the related PCI Devices attached to XenBus, and I didn't figured out how to revert that without doing a clean install. So, since I didn't had a clear idea about how to solve this issue, I decided to give a go to the W10 x64 RTM build... My Dom0 is still sitting on a 3 or 4 months old Arch Linux install with Xen 4.5 using qemu-xen and Linux Kernel 4.0.1, passing through the integrated Realtek Sound Card of my Supermicro X10SAT and a rather old Radeon 5770. The first try was creating a VM with OVMF Firmware, using a LVM volume for storage, and installing from the mounted Windows 10 ISO, without doing passthrough. Sucess on first try, no issues. However, after I added the pci = line with any device (I tried Video Card + Sound Card, then merely Sound Card), OVMF didn't even POST at all. It doesn't get to TianoCore splash screen, but it doesn't seem to freeze or crash, neither, since on xl list it appears on r----- status, and the time ocassionally increases. But still, after waiting several minutes, it doesn't POST. The second try was using SeaBIOS. I installed once without passthrough and again, everything works. Passing through the Realtek and Radeon produced unexpected results: Realtek worked fine, the Radeon was detected, but as soon as it install the Drivers (Either Catalyst manually or letting Windows Update download it), the SDL window became black, yet the Monitor attached to the Radeon didn't turned on. The VM seems to not have crashed since I could still hear sound from a Youtube video I was running. After rebooting a few times I still got a black screen after Windows splash screen, so I decided to format and try again from scratch. The third try was like the second, but with the devices already attached from the very first POST, so they were detected during installation. Again, installing the Catalyst killed the screen. It worked in Safe Mode with the SDL window displaying Windows 10 instead of merely a black screen, but getting to Safe Mode itself was not an easy feat. Since I was bored already, I decided to try to use my WXP x64 VM again. It outputted video on the SDL window instead of turning on the Monitor that the Radeon has, and the Radeon itslef reported a yellow exclamation mark on Device Manager (Code 43 if I recall correctly). At that point I figured out that I actually needed to restart the computer. Did so, and tried to create the Windows 10 VM as the very first thing. SUCESS. Monitor turned on, and everything working nearly as intended. A curious thing is that by default, Windows wants to use BOTH the Radeon, and the emulated Standard VGA that outputs in a SDL window on Dom0 as Extended Desktop. Disabling the Standard VGA from Device Manager doesn't actually seem to disable it at all, since Extended Desktop still works, so you have also to tell Windows to use just the Monitor attached to the Radeon. The reason why it worked on the fourth try was that I was still on the same session worth days and several restarts of the WXP x64 VM. Seems that the Windows 10 Catalyst likes to take the Radeon ONLY if I boot with it first, not if WXP x64 grabbed it first, and viceversa also applies according to my testing. Basically, if during a Dom0 session I start either Windows 10 or Windows XP x64, I have to stick with that unless I want to restart the entire computer. There is also the VM reboot behavior. WXP x64 with Catalyst 12.1 is the same as described here: http://www.gossamer-threads.com/lists/xen/users/348174 Resume: First boot perfect, second boot Radeon fixed always at max Power State, third boot perfect, fourth boot always at max Power State, and so on. It means that I have to effectively reboot the VM twice. Windows 10 with Catalyst 15.7.1 behaves sligty different. The very first boot it works with the proper Power States, EVERY reboot after the first boot uses the max one. So in this regard, it means that I have to restart the computer to get everything working as intended, while WXP SP3 and WXP x64 needed just two consecutive VM reboots. Also, since either Kernel 3.19 or 4.0, using xl create to start a VM with the Radeon attached, produces this: # xl create myvmwithradeon.cfg Parsing config from myvmwithradeon.cfg libxl: error: libxl_pci.c:1034:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0 The VM is created and works anyways. I suppose that instead of error, it should say warning. So basically, the good news is that you can get VGA Passthrough working on Windows 10 RTM. It also solved my original issue, so far, no NIC crashes from the emulated Intel e1000. If I don't send a mail ranting in 7 days, you can assume that it is still working fine. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 30 16:12:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 16:12:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKqQR-0007w5-C0; Thu, 30 Jul 2015 16:11:19 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKqQP-0007w0-LM for xen-users@lists.xen.org; Thu, 30 Jul 2015 16:11:17 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 83/9E-09570-4AC4AB55; Thu, 30 Jul 2015 16:11:16 +0000 X-Env-Sender: zir_blazer@hotmail.com X-Msg-Ref: server-12.tower-31.messagelabs.com!1438272665!30751767!1 X-Originating-IP: [65.55.90.82] X-SpamReason: No, hits=0.6 required=7.0 tests=BODY_RANDOM_LONG, FORGED_HOTMAIL_RCVD X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 15742 invoked from network); 30 Jul 2015 16:11:07 -0000 Received: from snt004-omc2s7.hotmail.com (HELO SNT004-OMC2S7.hotmail.com) (65.55.90.82) by server-12.tower-31.messagelabs.com with AES256-SHA encrypted SMTP; 30 Jul 2015 16:11:07 -0000 Received: from SNT151-W3 ([65.55.90.73]) by SNT004-OMC2S7.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 30 Jul 2015 09:11:04 -0700 X-TMN: [N22Me7kRhBTr3vKR7oM3I3GA61iYcwqJR/8jYUkB25k=] X-Originating-Email: [zir_blazer@hotmail.com] Message-ID: From: Zir Blazer To: "xen-users@lists.xen.org" Date: Thu, 30 Jul 2015 13:11:04 -0300 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 30 Jul 2015 16:11:04.0562 (UTC) FILETIME=[55DB9D20:01D0CAE2] Subject: [Xen-users] Xen 4.5, SeaBIOS, Radeon 5770 VGA Passthrough and Windows 10... Works. X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org Initially, I wasn't going to pay any attention to Windows 10 release, but coincidentally, since 3 weeks or so ago, I started to have some really annoying issues with the GPLPV NIC, which crashes near constantly on my main WXP x64 VM since I installed a game (Path of Exile). I have to disable the NIC from Network Connections and reenable it again for it to work, a disruption which makes online gaming a pain in the butt, and to add insult to the injury, the Driver crashes seems to be predictable, since usually I have a sucession of crashes that consistently happens after some elapsed time (Usually 45 minutes). I recall having had a near identical issue around a year ago or so, but got solved upgrading the GPLPV Drivers (From GPLPV 0.11.0.372 to EJBPV 1.0.1105), which I'm currently using. As the webpage of the GPLPV Drivers dissapeared some months ago and I didn't hear anything else from the author, I don't think I can get any support on this one even if I wanted to run the debug Drivers to try to track what the hell is making it crash like this. Worse yet, I also got stuck on the uninstall procedure, since even if the GPLPV Drivers gets removed and there is no /GPLPV on WXP line in boot.ini, Windows still insist on detecting unknow devices like the NIC attached to XenBus instead of the standard QEMU emulated devices, so I could not try using the Realtek RTL8139 or Intel e1000 to see if they behave the same. Setting xen_platform_pci = 0 on the DomU Config File makes WXP x64 BSOD on boot. Yet, on a fresh Windows install with xen_platform_pci = 1, it sees the QEMU emulated devices before installing the GPLPV Drivers, so it seems that it permanently changes something that makes the related PCI Devices attached to XenBus, and I didn't figured out how to revert that without doing a clean install. So, since I didn't had a clear idea about how to solve this issue, I decided to give a go to the W10 x64 RTM build... My Dom0 is still sitting on a 3 or 4 months old Arch Linux install with Xen 4.5 using qemu-xen and Linux Kernel 4.0.1, passing through the integrated Realtek Sound Card of my Supermicro X10SAT and a rather old Radeon 5770. The first try was creating a VM with OVMF Firmware, using a LVM volume for storage, and installing from the mounted Windows 10 ISO, without doing passthrough. Sucess on first try, no issues. However, after I added the pci = line with any device (I tried Video Card + Sound Card, then merely Sound Card), OVMF didn't even POST at all. It doesn't get to TianoCore splash screen, but it doesn't seem to freeze or crash, neither, since on xl list it appears on r----- status, and the time ocassionally increases. But still, after waiting several minutes, it doesn't POST. The second try was using SeaBIOS. I installed once without passthrough and again, everything works. Passing through the Realtek and Radeon produced unexpected results: Realtek worked fine, the Radeon was detected, but as soon as it install the Drivers (Either Catalyst manually or letting Windows Update download it), the SDL window became black, yet the Monitor attached to the Radeon didn't turned on. The VM seems to not have crashed since I could still hear sound from a Youtube video I was running. After rebooting a few times I still got a black screen after Windows splash screen, so I decided to format and try again from scratch. The third try was like the second, but with the devices already attached from the very first POST, so they were detected during installation. Again, installing the Catalyst killed the screen. It worked in Safe Mode with the SDL window displaying Windows 10 instead of merely a black screen, but getting to Safe Mode itself was not an easy feat. Since I was bored already, I decided to try to use my WXP x64 VM again. It outputted video on the SDL window instead of turning on the Monitor that the Radeon has, and the Radeon itslef reported a yellow exclamation mark on Device Manager (Code 43 if I recall correctly). At that point I figured out that I actually needed to restart the computer. Did so, and tried to create the Windows 10 VM as the very first thing. SUCESS. Monitor turned on, and everything working nearly as intended. A curious thing is that by default, Windows wants to use BOTH the Radeon, and the emulated Standard VGA that outputs in a SDL window on Dom0 as Extended Desktop. Disabling the Standard VGA from Device Manager doesn't actually seem to disable it at all, since Extended Desktop still works, so you have also to tell Windows to use just the Monitor attached to the Radeon. The reason why it worked on the fourth try was that I was still on the same session worth days and several restarts of the WXP x64 VM. Seems that the Windows 10 Catalyst likes to take the Radeon ONLY if I boot with it first, not if WXP x64 grabbed it first, and viceversa also applies according to my testing. Basically, if during a Dom0 session I start either Windows 10 or Windows XP x64, I have to stick with that unless I want to restart the entire computer. There is also the VM reboot behavior. WXP x64 with Catalyst 12.1 is the same as described here: http://www.gossamer-threads.com/lists/xen/users/348174 Resume: First boot perfect, second boot Radeon fixed always at max Power State, third boot perfect, fourth boot always at max Power State, and so on. It means that I have to effectively reboot the VM twice. Windows 10 with Catalyst 15.7.1 behaves sligty different. The very first boot it works with the proper Power States, EVERY reboot after the first boot uses the max one. So in this regard, it means that I have to restart the computer to get everything working as intended, while WXP SP3 and WXP x64 needed just two consecutive VM reboots. Also, since either Kernel 3.19 or 4.0, using xl create to start a VM with the Radeon attached, produces this: # xl create myvmwithradeon.cfg Parsing config from myvmwithradeon.cfg libxl: error: libxl_pci.c:1034:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device 0000:01:00.0 The VM is created and works anyways. I suppose that instead of error, it should say warning. So basically, the good news is that you can get VGA Passthrough working on Windows 10 RTM. It also solved my original issue, so far, no NIC crashes from the emulated Intel e1000. If I don't send a mail ranting in 7 days, you can assume that it is still working fine. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Thu Jul 30 22:15:13 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 22:15:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKw5Q-0004Wm-5P; Thu, 30 Jul 2015 22:14:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKw5O-0004Wh-1r for xen-users@lists.xen.org; Thu, 30 Jul 2015 22:13:58 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 41/BF-28221-5A1AAB55; Thu, 30 Jul 2015 22:13:57 +0000 X-Env-Sender: hakon@alstadheim.priv.no X-Msg-Ref: server-3.tower-27.messagelabs.com!1438294436!36616720!1 X-Originating-IP: [109.247.116.9] X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24800 invoked from network); 30 Jul 2015 22:13:56 -0000 Received: from asav22.altibox.net (HELO asav22.altibox.net) (109.247.116.9) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2015 22:13:56 -0000 Received: from localhost (localhost [127.0.0.1]) by asav22.altibox.net (Postfix) with ESMTP id 092DE200F4; Fri, 31 Jul 2015 00:13:56 +0200 (CEST) Received: from asav22.altibox.net ([127.0.0.1]) by localhost (asav22.lysetele.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A2-hRE7KmE-N; Fri, 31 Jul 2015 00:13:55 +0200 (CEST) Received: from postfix-relay.alstadheim.priv.no (178-164-66.9.3p.ntebredband.no [178.164.66.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon.alstadheim@ntebb.no) by asav22.altibox.net (Postfix) with ESMTPSA id 8B5DF200DB; Fri, 31 Jul 2015 00:13:54 +0200 (CEST) X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no Received: from smtps.alstadheim.priv.no (localhost [127.0.0.1]) by postfix-relay.alstadheim.priv.no (Postfix) with ESMTP id 8B2076801F9; Fri, 31 Jul 2015 00:13:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=alstadheim.priv.no; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=smtp; bh=4B+D9LvgTl+LIcLHTJ8e93LXqFg=; b=G9gPx5ZdfZc4EcBDQWZ1 pJML1s/FOuZmIKZlGVM4OZQB3JjRiA/d/pxyXEAD129x0NBjc3Z7JZeHbVZu5uZf e2URGKAUlgHy85QKRH7u9/gq4BlseNjtb6Tmwjl/eZKJOfpKdOUHb/YrL/6BORzK 01IyNvJqpEQoIV5rzt/Jy/0= Received: from [10.249.216.92] (93-217-11.connect.netcom.no [176.11.217.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon) by smtps.alstadheim.priv.no (Postfix) with ESMTPSA id 11B886C0116; Fri, 31 Jul 2015 00:13:20 +0200 (CEST) References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> <55BA34E9.4070507@dornerworks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <55BA34E9.4070507@dornerworks.com> Message-Id: X-Mailer: iPad Mail (12H143) From: =?utf-8?Q?H=C3=A5kon_Alstadheim?= Date: Fri, 31 Jul 2015 00:13:48 +0200 To: Karl Apsite Cc: "" Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org RGVuIDMwLiBqdWwuIDIwMTUga2wuIDE2LjMwIHNrcmV2IEthcmwgQXBzaXRlIDxLYXJsLkFwc2l0 ZUBkb3JuZXJ3b3Jrcy5jb20+OgoKPj4gT24gMDcvMjkvMjAxNSAwNToxNiBQTSwgSMOla29uIEFs c3RhZGhlaW0gd3JvdGU6Cj4+IAo+Pj4+IERlbiAyOS4ganVsLiAyMDE1IGtsLiAxNC41MSBza3Jl diBXb2xmIEdyb3NzaSA8d2dAbWFncm8tc29mdC5jb20+Ogo+Pj4+IAo+Pj4+IE9uIDI4LjA3LjIw MTUgMTc6NTIsIFppciBCbGF6ZXIgd3JvdGU6Cj4+Pj4gUFZVU0IgZ290IGJyb2tlbiBpbiBlaXRo ZXIgWGVuIDQuNC80LjUgaWYgSSByZWNhbGwgY29ycmVjdGx5LCBhbmQgc3VwcG9zZWRseSBpdCB3 YXMgaW50ZW5kZWQgdG8gYmUgYmFjayBpbiA0LjYuIEluIHRoZSBtZWFudGltZSwgYSB2aWFibGUg YWx0ZXJuYXRpdmUgaXMgdXNpbmcgYSBTUElDRSBjbGllbnQgKEFuZCBzZXR0aW5nIHVwIHRoZSBW TSBhY2NvcmRpbmdseSkgc28geW91IGNhbiB1c2UgVVNCIFJlZGlyZWN0aW9uLgo+Pj4+IAo+Pj4g Cj4+IC4uLiBvciB1c2UgdXNiaXAuIEEgYml0IGNsdW5reSwgYnV0IHN0YWJsZSB3aXRoIGxvdyBk YXRhLXJhdGUgc3R1ZmYgaW4gbXkgZXhwZXJpZW5jZS4gRG9uJ3QgdHJ5IHJ1bm5pbmcgYSBzb3Vu ZC1jYXJkIG92ZXIgdXNiaXAgdGhvdWdoLgo+IAo+IElzbid0IHRoYXQgYSBzcGVjaWZpYyBYZW5T ZXJ2ZXIgZnVuY3Rpb24vZHJpdmVyPyAgQXJlIHRoZXJlIGluc3RydWN0aW9ucyB0bwo+IGVuYWJs ZSB0aGUga2VybmVsIG1vZHVsZSwgYW5kIGluc3RhbGwgdGhlIGRyaXZlciBpbiBhIG5vbi1YZW5T ZXJ2ZXIgc2V0dXA/Cj4gCgp1c2JpcCBpcyBpbmRlcGVuZGVudCBmcm9tIHhlbiBhcyBmYXIgYXMg SSBrbm93LiBJJ20gcnVubmluZyBhIHJlZ3VsYXIga2VybmVsIGZyb20gZ2VudG9vLXNvdXJjZXMg d2hpY2ggaGFzIHRoZSByZXF1aXJlZCBtb2R1bGVzLiBHZW50b28gYWxzbyBwYWNrYWdlcyB0aGUg bmVjZXNzYXJ5IHVzZXJsYW5kIHRvb2xzLiBUaGUgInVzYmlwIiBwYWNrYWdlIGZvciB0aGUgdXNl cmxhbmQgcGFydCBzYXlzICJob21lcGFnZTogaHR0cDovL3d3dy5rZXJuZWwub3JnLyIuIFRoZSBw YWNrYWdlIGlzIG1hcmtlZCB1bnN0YWJsZSwgaGVuY2UgdGhlIGNsdW5reW5lc3MgSSBndWVzcy4g IEknbGwgbG9vayB1cCB0aGUgc3BlY2lmaWNzIHdoZW4gSSdtIGJhY2sgYXQgbXkgc3lzdGVtIGlu IGEgY291cGxlIG9mIGRheXMuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Thu Jul 30 22:15:13 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Thu, 30 Jul 2015 22:15:13 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKw5Q-0004Wm-5P; Thu, 30 Jul 2015 22:14:00 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZKw5O-0004Wh-1r for xen-users@lists.xen.org; Thu, 30 Jul 2015 22:13:58 +0000 Received: from [193.109.254.147] by server-7.bemta-14.messagelabs.com id 41/BF-28221-5A1AAB55; Thu, 30 Jul 2015 22:13:57 +0000 X-Env-Sender: hakon@alstadheim.priv.no X-Msg-Ref: server-3.tower-27.messagelabs.com!1438294436!36616720!1 X-Originating-IP: [109.247.116.9] X-SpamReason: No, hits=0.2 required=7.0 tests=MIME_QP_LONG_LINE X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24800 invoked from network); 30 Jul 2015 22:13:56 -0000 Received: from asav22.altibox.net (HELO asav22.altibox.net) (109.247.116.9) by server-3.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2015 22:13:56 -0000 Received: from localhost (localhost [127.0.0.1]) by asav22.altibox.net (Postfix) with ESMTP id 092DE200F4; Fri, 31 Jul 2015 00:13:56 +0200 (CEST) Received: from asav22.altibox.net ([127.0.0.1]) by localhost (asav22.lysetele.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id A2-hRE7KmE-N; Fri, 31 Jul 2015 00:13:55 +0200 (CEST) Received: from postfix-relay.alstadheim.priv.no (178-164-66.9.3p.ntebredband.no [178.164.66.9]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon.alstadheim@ntebb.no) by asav22.altibox.net (Postfix) with ESMTPSA id 8B5DF200DB; Fri, 31 Jul 2015 00:13:54 +0200 (CEST) X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no X-Finnesikke-B-A-I-T: finnesikke@alstadheim.priv.no Received: from smtps.alstadheim.priv.no (localhost [127.0.0.1]) by postfix-relay.alstadheim.priv.no (Postfix) with ESMTP id 8B2076801F9; Fri, 31 Jul 2015 00:13:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=alstadheim.priv.no; h= references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; s=smtp; bh=4B+D9LvgTl+LIcLHTJ8e93LXqFg=; b=G9gPx5ZdfZc4EcBDQWZ1 pJML1s/FOuZmIKZlGVM4OZQB3JjRiA/d/pxyXEAD129x0NBjc3Z7JZeHbVZu5uZf e2URGKAUlgHy85QKRH7u9/gq4BlseNjtb6Tmwjl/eZKJOfpKdOUHb/YrL/6BORzK 01IyNvJqpEQoIV5rzt/Jy/0= Received: from [10.249.216.92] (93-217-11.connect.netcom.no [176.11.217.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hakon) by smtps.alstadheim.priv.no (Postfix) with ESMTPSA id 11B886C0116; Fri, 31 Jul 2015 00:13:20 +0200 (CEST) References: <55B797D2.6050708@magro-soft.com> <55B8CC51.4060207@magro-soft.com> <18C0328B-6257-460F-964C-4F6F08FCC8F2@alstadheim.priv.no> <55BA34E9.4070507@dornerworks.com> Mime-Version: 1.0 (1.0) In-Reply-To: <55BA34E9.4070507@dornerworks.com> Message-Id: X-Mailer: iPad Mail (12H143) From: =?utf-8?Q?H=C3=A5kon_Alstadheim?= Date: Fri, 31 Jul 2015 00:13:48 +0200 To: Karl Apsite Cc: "" Subject: Re: [Xen-users] PV Guest and USB X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org RGVuIDMwLiBqdWwuIDIwMTUga2wuIDE2LjMwIHNrcmV2IEthcmwgQXBzaXRlIDxLYXJsLkFwc2l0 ZUBkb3JuZXJ3b3Jrcy5jb20+OgoKPj4gT24gMDcvMjkvMjAxNSAwNToxNiBQTSwgSMOla29uIEFs c3RhZGhlaW0gd3JvdGU6Cj4+IAo+Pj4+IERlbiAyOS4ganVsLiAyMDE1IGtsLiAxNC41MSBza3Jl diBXb2xmIEdyb3NzaSA8d2dAbWFncm8tc29mdC5jb20+Ogo+Pj4+IAo+Pj4+IE9uIDI4LjA3LjIw MTUgMTc6NTIsIFppciBCbGF6ZXIgd3JvdGU6Cj4+Pj4gUFZVU0IgZ290IGJyb2tlbiBpbiBlaXRo ZXIgWGVuIDQuNC80LjUgaWYgSSByZWNhbGwgY29ycmVjdGx5LCBhbmQgc3VwcG9zZWRseSBpdCB3 YXMgaW50ZW5kZWQgdG8gYmUgYmFjayBpbiA0LjYuIEluIHRoZSBtZWFudGltZSwgYSB2aWFibGUg YWx0ZXJuYXRpdmUgaXMgdXNpbmcgYSBTUElDRSBjbGllbnQgKEFuZCBzZXR0aW5nIHVwIHRoZSBW TSBhY2NvcmRpbmdseSkgc28geW91IGNhbiB1c2UgVVNCIFJlZGlyZWN0aW9uLgo+Pj4+IAo+Pj4g Cj4+IC4uLiBvciB1c2UgdXNiaXAuIEEgYml0IGNsdW5reSwgYnV0IHN0YWJsZSB3aXRoIGxvdyBk YXRhLXJhdGUgc3R1ZmYgaW4gbXkgZXhwZXJpZW5jZS4gRG9uJ3QgdHJ5IHJ1bm5pbmcgYSBzb3Vu ZC1jYXJkIG92ZXIgdXNiaXAgdGhvdWdoLgo+IAo+IElzbid0IHRoYXQgYSBzcGVjaWZpYyBYZW5T ZXJ2ZXIgZnVuY3Rpb24vZHJpdmVyPyAgQXJlIHRoZXJlIGluc3RydWN0aW9ucyB0bwo+IGVuYWJs ZSB0aGUga2VybmVsIG1vZHVsZSwgYW5kIGluc3RhbGwgdGhlIGRyaXZlciBpbiBhIG5vbi1YZW5T ZXJ2ZXIgc2V0dXA/Cj4gCgp1c2JpcCBpcyBpbmRlcGVuZGVudCBmcm9tIHhlbiBhcyBmYXIgYXMg SSBrbm93LiBJJ20gcnVubmluZyBhIHJlZ3VsYXIga2VybmVsIGZyb20gZ2VudG9vLXNvdXJjZXMg d2hpY2ggaGFzIHRoZSByZXF1aXJlZCBtb2R1bGVzLiBHZW50b28gYWxzbyBwYWNrYWdlcyB0aGUg bmVjZXNzYXJ5IHVzZXJsYW5kIHRvb2xzLiBUaGUgInVzYmlwIiBwYWNrYWdlIGZvciB0aGUgdXNl cmxhbmQgcGFydCBzYXlzICJob21lcGFnZTogaHR0cDovL3d3dy5rZXJuZWwub3JnLyIuIFRoZSBw YWNrYWdlIGlzIG1hcmtlZCB1bnN0YWJsZSwgaGVuY2UgdGhlIGNsdW5reW5lc3MgSSBndWVzcy4g IEknbGwgbG9vayB1cCB0aGUgc3BlY2lmaWNzIHdoZW4gSSdtIGJhY2sgYXQgbXkgc3lzdGVtIGlu IGEgY291cGxlIG9mIGRheXMuCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fClhlbi11c2VycyBtYWlsaW5nIGxpc3QKWGVuLXVzZXJzQGxpc3RzLnhlbi5vcmcK aHR0cDovL2xpc3RzLnhlbi5vcmcveGVuLXVzZXJz From xen-users-bounces@lists.xen.org Fri Jul 31 17:16:47 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 31 Jul 2015 17:16:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZLDuE-0000cg-8r; Fri, 31 Jul 2015 17:15:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZLDuD-0000cb-I9 for xen-users@lists.xen.org; Fri, 31 Jul 2015 17:15:37 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id FE/82-32641-83DABB55; Fri, 31 Jul 2015 17:15:36 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1438362935!31194199!1 X-Originating-IP: [204.29.186.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29204 invoked from network); 31 Jul 2015 17:15:35 -0000 Received: from omr-a005e.mx.aol.com (HELO omr-a005e.mx.aol.com) (204.29.186.50) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 17:15:35 -0000 Received: from mtaout-mcd01.mx.aol.com (mtaout-mcd01.mx.aol.com [172.26.223.205]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id CB797380004C; Fri, 31 Jul 2015 13:15:34 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B2B3438000087; Fri, 31 Jul 2015 13:15:33 -0400 (EDT) Message-ID: <1438363018.11183.7.camel@aol.com> From: pietrop To: Wolf Grossi Date: Fri, 31 Jul 2015 18:16:58 +0100 In-Reply-To: <55B61A12.4080200@magro-soft.com> References: <1434722648.6996.37.camel@aol.com> <55B61A12.4080200@magro-soft.com> X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1438362934; bh=rqiqhge2ZaR4LNcCd8fFUQ3Jq7lUD5+Ibglx+NT3F6U=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=wuZaq1ygHE5ItMFGsUS4+KTyOd9bH8Jn1My9E5IgNn64KO66jeS59R/hTUvakH6O2 Xe+rTWaV3wCONhg6/cEX1gODaMiH48JJ+ntKYpWPkWAOO8AV82mWlpKZMRhzZ19MXF 6lB+rylHm8cXknWADkE1MFL297FYKrsCPo/wNtsM= x-aol-sid: 3039ac1adfcd55bbad356406 X-AOL-IP: 185.25.64.249 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] USB Passthrough XEN 4.4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-27 at 13:46 +0200, Wolf Grossi wrote: > On 19.06.2015 16:04, pietrop wrote: > > Hi all, > > > > I am running XEN 4.4 and I am using the tool 'xl' to do all the needed > > common operations like start/stop/reboot virtual machines; I'd need to > > setup an USB passthrough and I am reading the related instructions from > > the page : > > > > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough > > > > Following the chapter 'Host USB in xl' it looks like the only support > > available is 'emulated USB', which as stated earlier in the same page is > > available only for HVM guest, I am pretty sure I am running a PV guest. > > > > Does that mean I can't configure USB passthrough on my system ? > > > > I have given those instructions a go but I can't see any USB > > devices/controller on my guest system. > > > > Instead I get an unable to initialize libusb: -99 > > > > am I obliged to go for a PCI passthrough ? > > > > Thanks, > > Pietro > > > > > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > > Pietro, > I'm in the same situation; > have you found a solution already or is the PCI-passthru the only option? > > Cheers, > Wolf > Hi Wolf, Unfortunately I am keep wrestling with that. As a workaround for my specific situation I am heavily relying on sshfs. Nevertheless my case is pretty straightforward since I just need to access an Android device to install some apps on it therefore a shared FS works just fine for me, anyway keep me posted if you find a solution since I would like to get it right. Cheers, Pietro _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 31 17:16:47 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 31 Jul 2015 17:16:47 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZLDuE-0000cg-8r; Fri, 31 Jul 2015 17:15:38 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZLDuD-0000cb-I9 for xen-users@lists.xen.org; Fri, 31 Jul 2015 17:15:37 +0000 Received: from [85.158.137.68] by server-11.bemta-3.messagelabs.com id FE/82-32641-83DABB55; Fri, 31 Jul 2015 17:15:36 +0000 X-Env-Sender: pulsarpietro@aol.com X-Msg-Ref: server-7.tower-31.messagelabs.com!1438362935!31194199!1 X-Originating-IP: [204.29.186.50] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29204 invoked from network); 31 Jul 2015 17:15:35 -0000 Received: from omr-a005e.mx.aol.com (HELO omr-a005e.mx.aol.com) (204.29.186.50) by server-7.tower-31.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 31 Jul 2015 17:15:35 -0000 Received: from mtaout-mcd01.mx.aol.com (mtaout-mcd01.mx.aol.com [172.26.223.205]) by omr-a005e.mx.aol.com (Outbound Mail Relay) with ESMTP id CB797380004C; Fri, 31 Jul 2015 13:15:34 -0400 (EDT) Received: from pietro-debian64.eng.citrite.net (unknown [185.25.64.249]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mtaout-mcd01.mx.aol.com (MUA/Third Party Client Interface) with ESMTPSA id B2B3438000087; Fri, 31 Jul 2015 13:15:33 -0400 (EDT) Message-ID: <1438363018.11183.7.camel@aol.com> From: pietrop To: Wolf Grossi Date: Fri, 31 Jul 2015 18:16:58 +0100 In-Reply-To: <55B61A12.4080200@magro-soft.com> References: <1434722648.6996.37.camel@aol.com> <55B61A12.4080200@magro-soft.com> X-Mailer: Evolution 3.12.9-1+b1 Mime-Version: 1.0 x-aol-global-disposition: G DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mx.aol.com; s=20150623; t=1438362934; bh=rqiqhge2ZaR4LNcCd8fFUQ3Jq7lUD5+Ibglx+NT3F6U=; h=From:To:Subject:Message-ID:Date:Mime-Version:Content-Type; b=wuZaq1ygHE5ItMFGsUS4+KTyOd9bH8Jn1My9E5IgNn64KO66jeS59R/hTUvakH6O2 Xe+rTWaV3wCONhg6/cEX1gODaMiH48JJ+ntKYpWPkWAOO8AV82mWlpKZMRhzZ19MXF 6lB+rylHm8cXknWADkE1MFL297FYKrsCPo/wNtsM= x-aol-sid: 3039ac1adfcd55bbad356406 X-AOL-IP: 185.25.64.249 Cc: xen-users@lists.xen.org Subject: Re: [Xen-users] USB Passthrough XEN 4.4 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Mon, 2015-07-27 at 13:46 +0200, Wolf Grossi wrote: > On 19.06.2015 16:04, pietrop wrote: > > Hi all, > > > > I am running XEN 4.4 and I am using the tool 'xl' to do all the needed > > common operations like start/stop/reboot virtual machines; I'd need to > > setup an USB passthrough and I am reading the related instructions from > > the page : > > > > http://wiki.xenproject.org/wiki/Xen_USB_Passthrough > > > > Following the chapter 'Host USB in xl' it looks like the only support > > available is 'emulated USB', which as stated earlier in the same page is > > available only for HVM guest, I am pretty sure I am running a PV guest. > > > > Does that mean I can't configure USB passthrough on my system ? > > > > I have given those instructions a go but I can't see any USB > > devices/controller on my guest system. > > > > Instead I get an unable to initialize libusb: -99 > > > > am I obliged to go for a PCI passthrough ? > > > > Thanks, > > Pietro > > > > > > > > > > > > _______________________________________________ > > Xen-users mailing list > > Xen-users@lists.xen.org > > http://lists.xen.org/xen-users > > > Pietro, > I'm in the same situation; > have you found a solution already or is the PCI-passthru the only option? > > Cheers, > Wolf > Hi Wolf, Unfortunately I am keep wrestling with that. As a workaround for my specific situation I am heavily relying on sshfs. Nevertheless my case is pretty straightforward since I just need to access an Android device to install some apps on it therefore a shared FS works just fine for me, anyway keep me posted if you find a solution since I would like to get it right. Cheers, Pietro _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

=

Gabriel = Queiroz

+55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
= gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www.flowecom= merce.com

=C2= =A0


2015-07-22 8:55 GMT-03:00 Gabriel Queiroz Si= lva <gabriel@flowecommerce.com>:
Thanks Ian. Will try there again.


= =C2=A0


2015-07-22 7:39 GMT-03:00 I= an Campbell <ian.campbell@citrix.com>:
On Wed, 2015-07-22 at 10:1= 8 +0000, Gabriel Queiroz Silva wrote:
> I have already asked XCP questions there before and have been
> recommended to try these lists instead.

For a pure XCP question that is probably correct, however for an
= upgrade to XenServer I think the xenserver.org resources are going to
be the most likely place you will find help.

> Anyway, if by any chance someone could point me to any material
> regarding this migration I would be extremely thankful.

I don't have anything myself.

Ian.


--001a113ede9288280b051b9da26e-- --===============2373801094052302979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2373801094052302979==-- From xen-users-bounces@lists.xen.org Fri Jul 24 11:53:23 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 11:53:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbWU-0001Id-9Z; Fri, 24 Jul 2015 11:52:18 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbWT-0001IT-4G for xen-users@lists.xen.org; Fri, 24 Jul 2015 11:52:17 +0000 Received: from [85.158.139.211] by server-15.bemta-5.messagelabs.com id C5/8B-12200-0F622B55; Fri, 24 Jul 2015 11:52:16 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-8.tower-206.messagelabs.com!1437738734!23397386!1 X-Originating-IP: [209.85.213.182] X-SpamReason: No, hits=0.3 required=7.0 tests=HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8296 invoked from network); 24 Jul 2015 11:52:15 -0000 Received: from mail-ig0-f182.google.com (HELO mail-ig0-f182.google.com) (209.85.213.182) by server-8.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 11:52:15 -0000 Received: by igk11 with SMTP id 11so3650910igk.1 for ; Fri, 24 Jul 2015 04:52:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=mWaNUf/Wxr3qJsr7hYOeE1jrJ2aLnhqcVMMtpPXHBNE=; b=WCp12HDsaZrGd1uEvpZYDmnFK5SG1usfgqI9sMau+Go2oMblSkpBlOOhnNbL4xTxEO 9E+aS5LVrVCp1nAAirMnerwed4/sfwsNgqpiq97rrylzjZ8gRgeQjEjjQ43GxLAe6zNP YXCmxNRLatsJ5ufHuIlIaOOzxFS+Qa8+Iw11HZBGChljkknW0+2wTg/E/2RMUI3qOUzM O10bMN90TK0Km56r6+cuPs5aR2snvzHhSTXgL9b1fifXms3bU1WEFL+UuQnuEW1DBR0B 5NjHqNqSt22FUmcsPSfkYCtnSAG2nR0v9y7WtoIEmTFqaIH3z08Hoe9rIRuu2bEibuJ1 NGQQ== X-Gm-Message-State: ALoCoQns3Ql3N9fwomljnrR+P1O+0aFAccUtqMtst4kA0XNmoPpsExJhkZ4ucdrZ0zk+wiyewFvC X-Received: by 10.107.11.149 with SMTP id 21mr22505072iol.103.1437738734197; Fri, 24 Jul 2015 04:52:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Fri, 24 Jul 2015 04:51:54 -0700 (PDT) In-Reply-To: References: <1437558204.8383.68.camel@citrix.com> <1437561546.12884.19.camel@citrix.com> From: Gabriel Queiroz Silva Date: Fri, 24 Jul 2015 08:51:54 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] Risks of upgrading from XCP 1.6 to XS 6.2 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2373801094052302979==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============2373801094052302979== Content-Type: multipart/alternative; boundary=001a113ede9288280b051b9da26e --001a113ede9288280b051b9da26e Content-Type: text/plain; charset=UTF-8 Just in case anyone bumps on this thread: I've gone through the upgrade and it was as simple as promised. Boot up the Xen Server 6.2 disk, upgrade from there. Took me half an hour. Cheers, *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 8:55 GMT-03:00 Gabriel Queiroz Silva : > Thanks Ian. Will try there again. > > > *Gabriel Queiroz* > > *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 > <%2B55%2061%208117-8050>* > gabriel@flowecommerce.com . www.flowecommerce.com > > > > 2015-07-22 7:39 GMT-03:00 Ian Campbell : > >> On Wed, 2015-07-22 at 10:18 +0000, Gabriel Queiroz Silva wrote: >> > I have already asked XCP questions there before and have been >> > recommended to try these lists instead. >> >> For a pure XCP question that is probably correct, however for an >> upgrade to XenServer I think the xenserver.org resources are going to >> be the most likely place you will find help. >> >> > Anyway, if by any chance someone could point me to any material >> > regarding this migration I would be extremely thankful. >> >> I don't have anything myself. >> >> Ian. >> > > --001a113ede9288280b051b9da26e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just in case anyone bumps on this thread: I've gone th= rough the upgrade and it was as simple as promised. Boot up the Xen Server = 6.2 disk, upgrade from there. Took me half an hour.

Chee= rs,

Gabriel Queiroz

= +55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www= .flowecommerce.com

=

Gabriel = Queiroz

+55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
= gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www.flowecom= merce.com

=C2= =A0


2015-07-22 8:55 GMT-03:00 Gabriel Queiroz Si= lva <gabriel@flowecommerce.com>:
Thanks Ian. Will try there again.


= =C2=A0


2015-07-22 7:39 GMT-03:00 I= an Campbell <ian.campbell@citrix.com>:
On Wed, 2015-07-22 at 10:1= 8 +0000, Gabriel Queiroz Silva wrote:
> I have already asked XCP questions there before and have been
> recommended to try these lists instead.

For a pure XCP question that is probably correct, however for an
= upgrade to XenServer I think the xenserver.org resources are going to
be the most likely place you will find help.

> Anyway, if by any chance someone could point me to any material
> regarding this migration I would be extremely thankful.

I don't have anything myself.

Ian.


--001a113ede9288280b051b9da26e-- --===============2373801094052302979== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============2373801094052302979==-- From xen-users-bounces@lists.xen.org Fri Jul 24 11:55:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 11:55:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbZX-0001ea-Ds; Fri, 24 Jul 2015 11:55:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbZV-0001eO-Gl for xen-users@lists.xen.org; Fri, 24 Jul 2015 11:55:25 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 03/7E-17254-CA722B55; Fri, 24 Jul 2015 11:55:24 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1437738922!23402042!1 X-Originating-IP: [209.85.213.176] X-SpamReason: No, hits=1.6 required=7.0 tests=HOT_NASTY,HTML_50_60, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8979 invoked from network); 24 Jul 2015 11:55:22 -0000 Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com) (209.85.213.176) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 11:55:22 -0000 Received: by igr7 with SMTP id 7so14588638igr.0 for ; Fri, 24 Jul 2015 04:55:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=9Ouh1YjpuXmbH8AuNS2shmLj7+gsaa4Sul4IK/qwBxY=; b=X5ks5MzjvB891VhNCQMizzmM5r80pWw4paZDL2Sgn1XOcOn0+zHmZBa97iHxgR8wNy LROK5IcK7jkemRMdJ0CYIXp4krOINLsWTlYhHQlBGSSeOxUgI6U5WDh/TYoGZWYcw3oT oMiShTN9lKgW917i3nRqEGC40veRemxN4i7XLz0hsY/oUrx34891O07eCSUoTCD1jLm0 bLCOJ29rbxiVO4mXWbSYaMQkFtd+AqlOW5yYQdrmIXaaTDXfmHLuo9vtyTQKjbVImWNe iWrF9GVdJx3MDCXEwoePGPieJ4bHpoB1jjMNmpdOWsfUnhU/BcwC31cl+tVvBnemjb1h rrew== X-Gm-Message-State: ALoCoQkzarGieEzDUMkTTHOeSoHygw0tGQPNAYIN2L6VYVd1TPmer5VMJ/Kqncw2W1IAGuwruW9b X-Received: by 10.107.136.160 with SMTP id s32mr21963337ioi.174.1437738921925; Fri, 24 Jul 2015 04:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Fri, 24 Jul 2015 04:55:02 -0700 (PDT) In-Reply-To: References: From: Gabriel Queiroz Silva Date: Fri, 24 Jul 2015 08:55:02 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] No network on VM after migrating to another xcp server on the same pool X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8042796926735613553==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8042796926735613553== Content-Type: multipart/alternative; boundary=001a113ecffeb8acd8051b9dadd0 --001a113ecffeb8acd8051b9dadd0 Content-Type: text/plain; charset=UTF-8 In case anyone has a similar problem in the future: In my new server, there was only one cable connected in one of the 4 ethernet card available. The active network was number 3, while i had the VMs configured to use Network 1. You can change those settings in the Networking tab of your VM. This article helped me understand what was going on: http://wiki.xenproject.org/wiki/Xen_Networking *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 9:00 GMT-03:00 Gabriel Queiroz Silva : > Hi, > > I have migrated one ubuntu VM from one XCP 1.6 server to another. After > doing this, this VM is not able to connect to the networks as before. I > have kept IP and MAC Addresses the same. > > After running ifconfig, i can see the interface as follows: > > > *eth0 Link encap:Ethernet HWaddr YYY * > * inet addr:XXXX Bcast:XXXX Mask:255.255.255.192* > * inet6 addr: XXXXXX/64 Scope:Link* > * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* > * RX packets:0 errors:0 dropped:0 overruns:0 frame:0* > * TX packets:319 errors:0 dropped:0 overruns:0 carrier:0* > * collisions:0 txqueuelen:1000 * > * RX bytes:0 (0.0 B) TX bytes:13614 (13.6 KB)* > * Interrupt:68 * > > *lo Link encap:Local Loopback * > * inet addr:127.0.0.1 Mask:255.0.0.0* > * inet6 addr: ::1/128 Scope:Host* > * UP LOOPBACK RUNNING MTU:16436 Metric:1* > * RX packets:679 errors:0 dropped:0 overruns:0 frame:0* > * TX packets:679 errors:0 dropped:0 overruns:0 carrier:0* > * collisions:0 txqueuelen:0 * > * RX bytes:3985002 <3985002> (3.9 MB) TX bytes:3985002 <3985002> > (3.9 MB)* > > > > Bringing down and up the eth0 interface works, as follows: > > > *root@xx:~# ifdown -v eth0* > *Configuring interface eth0=eth0 (inet)* > *run-parts --verbose /etc/network/if-down.d* > *run-parts: executing /etc/network/if-down.d/resolvconf* > *run-parts: executing /etc/network/if-down.d/sendmail* > *run-parts: executing /etc/network/if-down.d/upstart* > *run-parts: executing /etc/network/if-down.d/wpasupplicant* > *ip route del default via XXX metric 100 dev eth0 2>&1 1>/dev/null || > true * > *ip -4 addr flush dev eth0 label eth0* > *ip link set dev eth0 down* > *run-parts --verbose /etc/network/if-post-down.d* > *run-parts: executing /etc/network/if-post-down.d/sendmail* > *run-parts: executing /etc/network/if-post-down.d/wireless-tools* > *run-parts: executing /etc/network/if-post-down.d/wpasupplicant* > > *root@xx:~# ifup -v eth0* > *Configuring interface eth0=eth0 (inet)* > *run-parts --verbose /etc/network/if-pre-up.d* > *run-parts: executing /etc/network/if-pre-up.d/ethtool* > *run-parts: executing /etc/network/if-pre-up.d/wireless-tools* > *run-parts: executing /etc/network/if-pre-up.d/wpasupplicant* > *ip addr add XXXX/255.255.255.192 broadcast + > dev eth0 label eth0* > *ip link set dev eth0 up* > * ip route add default via XXXX metric 100 dev eth0 * > *run-parts --verbose /etc/network/if-up.d* > *run-parts: executing /etc/network/if-up.d/000resolvconf* > *run-parts: executing /etc/network/if-up.d/ethtool* > *run-parts: executing /etc/network/if-up.d/ntpdate* > *run-parts: executing /etc/network/if-up.d/openssh-server* > > > Routes seem to be in order: > > > *Destination Gateway Genmask Flags Metric Ref Use > Iface* > *0.0.0.0 XXX 0.0.0.0 UG 100 0 0 eth0* > *XXX 0.0.0.0 255.255.255.192 U 0 0 0 eth0* > > > > But i still can't start the networking service... > > > *root@xxx:~# service networking start* > *networking stop/waiting* > > > No error messages are shown anywhere. > > Is there some point to the migration i could be missing? What could differ > from one server to another to cause the networking to fail on the new host? > > Thanks, > Gabriel > --001a113ecffeb8acd8051b9dadd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case anyone has a similar problem in the future: In my = new server, there was only one cable connected in one of the 4 ethernet car= d available. The active network was number 3, while i had the VMs configure= d to use Network 1. You can change those settings in the Networking tab of = your VM.

This article helped me understand what was goin= g on:=C2=A0http:= //wiki.xenproject.org/wiki/Xen_Networking
<= /font>


Gabriel Queiroz

= +55 61 3037-2002=C2=A0/=C2=A0+55 61 8117-8050
gabriel@flowecommerce.com=C2=A0=C2=A0 . =C2=A0=C2=A0www= .flowecommerce.com

Gabriel Queiroz<= /u>

+55 61 3037-2002=C2=A0/=C2=A0+55= 61 8117-8050
gabriel@flowecommerce.com<= /a>=C2=A0=C2=A0 . =C2=A0=C2=A0www.flowecommerce.com

=C2=A0


2015-07-22 9:00 GMT-03:00 Gabriel Queiroz Si= lva <gabriel@flowecommerce.com>:
Hi,
=C2=A0
I have = migrated one ubuntu VM from one XCP 1.6 server to another. After doing this= , this VM is not able to connect to the networks as before. I have kept IP = and MAC Addresses the same.
=C2=A0
After running ifconf= ig, i can see the interface as follows:
=C2=A0
eth0 =C2=A0 =C2= =A0 =C2=A0Link encap:Ethernet =C2=A0HWaddr YYY =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet addr:XXXX =C2=A0Bcast:XXXX =C2=A0Mask:= 255.255.255.192
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 a= ddr: XXXXXX/64 Scope:Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 UP BROADCAST RUNNING MULTICAST =C2=A0MTU:1500 =C2=A0Metric:1
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:0 errors:0 dropped:0 o= verruns:0 frame:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX pa= ckets:319 errors:0 dropped:0 overruns:0 carrier:0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:1000=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:0 (0.0 B) =C2=A0TX bytes:1= 3614 (13.6 KB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interrup= t:68=C2=A0
=C2=A0
lo =C2=A0 =C2=A0 =C2=A0= =C2=A0Link encap:Local Loopback =C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet addr:127.0.0.1 =C2=A0Mask:255.0.0.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING =C2=A0MTU:1= 6436 =C2=A0Metric:1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX = packets:679 errors:0 dropped:0 overruns:0 frame:0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets:679 errors:0 dropped:0 overruns:0 ca= rrier:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 tx= queuelen:0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX byt= es:3985002<= /a> (3.9 MB) =C2=A0TX bytes:3985002 (3.9 MB)
=C2=A0
=C2=A0
Bringing down and up the eth0 interface works, as f= ollows:
=C2=A0
root@xx:~# ifdown -v eth0
Confi= guring interface eth0=3Deth0 (inet)
run-parts --verbose /e= tc/network/if-down.d
run-parts: executing /etc/network/if-= down.d/resolvconf
run-parts: executing /etc/network/if-dow= n.d/sendmail
run-parts: executing /etc/network/if-down.d/u= pstart
run-parts: executing /etc/network/if-down.d/wpasupp= licant
ip route del default via XXX metric 100 dev eth0 2&= gt;&1 1>/dev/null || true=C2=A0
ip -4 addr flush de= v eth0 label eth0
ip link set dev eth0 down
= run-parts --verbose /etc/network/if-post-down.d
run-par= ts: executing /etc/network/if-post-down.d/sendmail
run-par= ts: executing /etc/network/if-post-down.d/wireless-tools
r= un-parts: executing /etc/network/if-post-down.d/wpasupplicant
=C2=A0
root@xx:~# ifup -v eth0
Config= uring interface eth0=3Deth0 (inet)
run-parts --verbose /et= c/network/if-pre-up.d
run-parts: executing /etc/network/if= -pre-up.d/ethtool
run-parts: executing /etc/network/if-pre= -up.d/wireless-tools
run-parts: executing /etc/network/if-= pre-up.d/wpasupplicant
ip addr add XXXX/255.255.255.192 broadcast + =C2=A0 d= ev eth0 label eth0
ip link set dev eth0 =C2=A0 up
=C2=A0ip route add default via XXXX metric 100 dev eth0=C2=A0<= /div>
run-parts --verbose /etc/network/if-up.d
run-= parts: executing /etc/network/if-up.d/000resolvconf
run-pa= rts: executing /etc/network/if-up.d/ethtool
run-parts: exe= cuting /etc/network/if-up.d/ntpdate
run-parts: executing /= etc/network/if-up.d/openssh-server
=C2=A0
<= div>Routes seem to be in order:
=C2=A0
Destination =C2=A0 =C2= =A0 Gateway =C2=A0 =C2=A0 =C2=A0 =C2=A0 Genmask =C2=A0 =C2=A0 =C2=A0 =C2=A0= Flags Metric Ref =C2=A0 =C2=A0Use Iface
0.0.0.0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 XXX 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UG =C2=A0 =C2= =A0100 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
XX= X 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 255.255.255.192 U =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
=
=C2=A0
=C2=A0
But i still can't start the netw= orking service...
=C2=A0
root@xxx:~# service networking start
networking stop/waiting

No error messages are shown anywhere.

Is th= ere some point to the migration i could be missing? What could differ from = one server to another to cause the networking to fail on the new host?
=C2=A0
Thanks,
Gabriel

--001a113ecffeb8acd8051b9dadd0-- --===============8042796926735613553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8042796926735613553==-- From xen-users-bounces@lists.xen.org Fri Jul 24 11:55:31 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 11:55:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbZX-0001ea-Ds; Fri, 24 Jul 2015 11:55:27 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbZV-0001eO-Gl for xen-users@lists.xen.org; Fri, 24 Jul 2015 11:55:25 +0000 Received: from [85.158.139.211] by server-6.bemta-5.messagelabs.com id 03/7E-17254-CA722B55; Fri, 24 Jul 2015 11:55:24 +0000 X-Env-Sender: gabriel@flowecommerce.com X-Msg-Ref: server-9.tower-206.messagelabs.com!1437738922!23402042!1 X-Originating-IP: [209.85.213.176] X-SpamReason: No, hits=1.6 required=7.0 tests=HOT_NASTY,HTML_50_60, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8979 invoked from network); 24 Jul 2015 11:55:22 -0000 Received: from mail-ig0-f176.google.com (HELO mail-ig0-f176.google.com) (209.85.213.176) by server-9.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 11:55:22 -0000 Received: by igr7 with SMTP id 7so14588638igr.0 for ; Fri, 24 Jul 2015 04:55:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=9Ouh1YjpuXmbH8AuNS2shmLj7+gsaa4Sul4IK/qwBxY=; b=X5ks5MzjvB891VhNCQMizzmM5r80pWw4paZDL2Sgn1XOcOn0+zHmZBa97iHxgR8wNy LROK5IcK7jkemRMdJ0CYIXp4krOINLsWTlYhHQlBGSSeOxUgI6U5WDh/TYoGZWYcw3oT oMiShTN9lKgW917i3nRqEGC40veRemxN4i7XLz0hsY/oUrx34891O07eCSUoTCD1jLm0 bLCOJ29rbxiVO4mXWbSYaMQkFtd+AqlOW5yYQdrmIXaaTDXfmHLuo9vtyTQKjbVImWNe iWrF9GVdJx3MDCXEwoePGPieJ4bHpoB1jjMNmpdOWsfUnhU/BcwC31cl+tVvBnemjb1h rrew== X-Gm-Message-State: ALoCoQkzarGieEzDUMkTTHOeSoHygw0tGQPNAYIN2L6VYVd1TPmer5VMJ/Kqncw2W1IAGuwruW9b X-Received: by 10.107.136.160 with SMTP id s32mr21963337ioi.174.1437738921925; Fri, 24 Jul 2015 04:55:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.68.4 with HTTP; Fri, 24 Jul 2015 04:55:02 -0700 (PDT) In-Reply-To: References: From: Gabriel Queiroz Silva Date: Fri, 24 Jul 2015 08:55:02 -0300 Message-ID: To: xen-users@lists.xen.org Subject: Re: [Xen-users] No network on VM after migrating to another xcp server on the same pool X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8042796926735613553==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============8042796926735613553== Content-Type: multipart/alternative; boundary=001a113ecffeb8acd8051b9dadd0 --001a113ecffeb8acd8051b9dadd0 Content-Type: text/plain; charset=UTF-8 In case anyone has a similar problem in the future: In my new server, there was only one cable connected in one of the 4 ethernet card available. The active network was number 3, while i had the VMs configured to use Network 1. You can change those settings in the Networking tab of your VM. This article helped me understand what was going on: http://wiki.xenproject.org/wiki/Xen_Networking *Gabriel Queiroz* *+55 61 3037-2002 <%2B55%2061%203037-2002> / +55 61 8117-8050 <%2B55%2061%208117-8050>* gabriel@flowecommerce.com . www.flowecommerce.com 2015-07-22 9:00 GMT-03:00 Gabriel Queiroz Silva : > Hi, > > I have migrated one ubuntu VM from one XCP 1.6 server to another. After > doing this, this VM is not able to connect to the networks as before. I > have kept IP and MAC Addresses the same. > > After running ifconfig, i can see the interface as follows: > > > *eth0 Link encap:Ethernet HWaddr YYY * > * inet addr:XXXX Bcast:XXXX Mask:255.255.255.192* > * inet6 addr: XXXXXX/64 Scope:Link* > * UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1* > * RX packets:0 errors:0 dropped:0 overruns:0 frame:0* > * TX packets:319 errors:0 dropped:0 overruns:0 carrier:0* > * collisions:0 txqueuelen:1000 * > * RX bytes:0 (0.0 B) TX bytes:13614 (13.6 KB)* > * Interrupt:68 * > > *lo Link encap:Local Loopback * > * inet addr:127.0.0.1 Mask:255.0.0.0* > * inet6 addr: ::1/128 Scope:Host* > * UP LOOPBACK RUNNING MTU:16436 Metric:1* > * RX packets:679 errors:0 dropped:0 overruns:0 frame:0* > * TX packets:679 errors:0 dropped:0 overruns:0 carrier:0* > * collisions:0 txqueuelen:0 * > * RX bytes:3985002 <3985002> (3.9 MB) TX bytes:3985002 <3985002> > (3.9 MB)* > > > > Bringing down and up the eth0 interface works, as follows: > > > *root@xx:~# ifdown -v eth0* > *Configuring interface eth0=eth0 (inet)* > *run-parts --verbose /etc/network/if-down.d* > *run-parts: executing /etc/network/if-down.d/resolvconf* > *run-parts: executing /etc/network/if-down.d/sendmail* > *run-parts: executing /etc/network/if-down.d/upstart* > *run-parts: executing /etc/network/if-down.d/wpasupplicant* > *ip route del default via XXX metric 100 dev eth0 2>&1 1>/dev/null || > true * > *ip -4 addr flush dev eth0 label eth0* > *ip link set dev eth0 down* > *run-parts --verbose /etc/network/if-post-down.d* > *run-parts: executing /etc/network/if-post-down.d/sendmail* > *run-parts: executing /etc/network/if-post-down.d/wireless-tools* > *run-parts: executing /etc/network/if-post-down.d/wpasupplicant* > > *root@xx:~# ifup -v eth0* > *Configuring interface eth0=eth0 (inet)* > *run-parts --verbose /etc/network/if-pre-up.d* > *run-parts: executing /etc/network/if-pre-up.d/ethtool* > *run-parts: executing /etc/network/if-pre-up.d/wireless-tools* > *run-parts: executing /etc/network/if-pre-up.d/wpasupplicant* > *ip addr add XXXX/255.255.255.192 broadcast + > dev eth0 label eth0* > *ip link set dev eth0 up* > * ip route add default via XXXX metric 100 dev eth0 * > *run-parts --verbose /etc/network/if-up.d* > *run-parts: executing /etc/network/if-up.d/000resolvconf* > *run-parts: executing /etc/network/if-up.d/ethtool* > *run-parts: executing /etc/network/if-up.d/ntpdate* > *run-parts: executing /etc/network/if-up.d/openssh-server* > > > Routes seem to be in order: > > > *Destination Gateway Genmask Flags Metric Ref Use > Iface* > *0.0.0.0 XXX 0.0.0.0 UG 100 0 0 eth0* > *XXX 0.0.0.0 255.255.255.192 U 0 0 0 eth0* > > > > But i still can't start the networking service... > > > *root@xxx:~# service networking start* > *networking stop/waiting* > > > No error messages are shown anywhere. > > Is there some point to the migration i could be missing? What could differ > from one server to another to cause the networking to fail on the new host? > > Thanks, > Gabriel > --001a113ecffeb8acd8051b9dadd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In case anyone has a similar problem in the future: In my = new server, there was only one cable connected in one of the 4 ethernet car= d available. The active network was number 3, while i had the VMs configure= d to use Network 1. You can change those settings in the Networking tab of = your VM.

This article helped me understand what was goin= g on:=C2=A0http:= //wiki.xenproject.org/wiki/Xen_Networking
<= /font>


2015-07-22 9:00 GMT-03:00 Gabriel Queiroz Si= lva <gabriel@flowecommerce.com>:
Hi,
=C2=A0
I have = migrated one ubuntu VM from one XCP 1.6 server to another. After doing this= , this VM is not able to connect to the networks as before. I have kept IP = and MAC Addresses the same.
=C2=A0
After running ifconf= ig, i can see the interface as follows:
=C2=A0
eth0 =C2=A0 =C2= =A0 =C2=A0Link encap:Ethernet =C2=A0HWaddr YYY =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet addr:XXXX =C2=A0Bcast:XXXX =C2=A0Mask:= 255.255.255.192
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 a= ddr: XXXXXX/64 Scope:Link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 UP BROADCAST RUNNING MULTICAST =C2=A0MTU:1500 =C2=A0Metric:1
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX packets:0 errors:0 dropped:0 o= verruns:0 frame:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX pa= ckets:319 errors:0 dropped:0 overruns:0 carrier:0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 txqueuelen:1000=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX bytes:0 (0.0 B) =C2=A0TX bytes:1= 3614 (13.6 KB)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interrup= t:68=C2=A0
=C2=A0
lo =C2=A0 =C2=A0 =C2=A0= =C2=A0Link encap:Local Loopback =C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 inet addr:127.0.0.1 =C2=A0Mask:255.0.0.0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 addr: ::1/128 Scope:Host
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UP LOOPBACK RUNNING =C2=A0MTU:1= 6436 =C2=A0Metric:1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX = packets:679 errors:0 dropped:0 overruns:0 frame:0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 TX packets:679 errors:0 dropped:0 overruns:0 ca= rrier:0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collisions:0 tx= queuelen:0=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RX byt= es:3985002<= /a> (3.9 MB) =C2=A0TX bytes:3985002 (3.9 MB)
=C2=A0
=C2=A0
Bringing down and up the eth0 interface works, as f= ollows:
=C2=A0
root@xx:~# ifdown -v eth0
Confi= guring interface eth0=3Deth0 (inet)
run-parts --verbose /e= tc/network/if-down.d
run-parts: executing /etc/network/if-= down.d/resolvconf
run-parts: executing /etc/network/if-dow= n.d/sendmail
run-parts: executing /etc/network/if-down.d/u= pstart
run-parts: executing /etc/network/if-down.d/wpasupp= licant
ip route del default via XXX metric 100 dev eth0 2&= gt;&1 1>/dev/null || true=C2=A0
ip -4 addr flush de= v eth0 label eth0
ip link set dev eth0 down
= run-parts --verbose /etc/network/if-post-down.d
run-par= ts: executing /etc/network/if-post-down.d/sendmail
run-par= ts: executing /etc/network/if-post-down.d/wireless-tools
r= un-parts: executing /etc/network/if-post-down.d/wpasupplicant
=C2=A0
root@xx:~# ifup -v eth0
Config= uring interface eth0=3Deth0 (inet)
run-parts --verbose /et= c/network/if-pre-up.d
run-parts: executing /etc/network/if= -pre-up.d/ethtool
run-parts: executing /etc/network/if-pre= -up.d/wireless-tools
run-parts: executing /etc/network/if-= pre-up.d/wpasupplicant
ip addr add XXXX/255.255.255.192 broadcast + =C2=A0 d= ev eth0 label eth0
ip link set dev eth0 =C2=A0 up
=C2=A0ip route add default via XXXX metric 100 dev eth0=C2=A0<= /div>
run-parts --verbose /etc/network/if-up.d
run-= parts: executing /etc/network/if-up.d/000resolvconf
run-pa= rts: executing /etc/network/if-up.d/ethtool
run-parts: exe= cuting /etc/network/if-up.d/ntpdate
run-parts: executing /= etc/network/if-up.d/openssh-server
=C2=A0
<= div>Routes seem to be in order:
=C2=A0
Destination =C2=A0 =C2= =A0 Gateway =C2=A0 =C2=A0 =C2=A0 =C2=A0 Genmask =C2=A0 =C2=A0 =C2=A0 =C2=A0= Flags Metric Ref =C2=A0 =C2=A0Use Iface
0.0.0.0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 XXX 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UG =C2=A0 =C2= =A0100 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
XX= X 0.0.0.0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 255.255.255.192 U =C2=A0 =C2=A0 0 =C2= =A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A00 eth0
=
=C2=A0
=C2=A0
But i still can't start the netw= orking service...
=C2=A0
root@xxx:~# service networking start
networking stop/waiting

No error messages are shown anywhere.

Is th= ere some point to the migration i could be missing? What could differ from = one server to another to cause the networking to fail on the new host?
=C2=A0
Thanks,
Gabriel

--001a113ecffeb8acd8051b9dadd0-- --===============8042796926735613553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============8042796926735613553==-- From xen-users-bounces@lists.xen.org Fri Jul 24 12:15:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 12:15:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbsB-0004Vo-SV; Fri, 24 Jul 2015 12:14:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbsA-0004Vc-Og for xen-users@lists.xen.org; Fri, 24 Jul 2015 12:14:42 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 3F/67-21947-23C22B55; Fri, 24 Jul 2015 12:14:42 +0000 X-Env-Sender: gcxenlist@crowie.net X-Msg-Ref: server-2.tower-206.messagelabs.com!1437740078!23412547!1 X-Originating-IP: [115.70.75.133] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7556 invoked from network); 24 Jul 2015 12:14:41 -0000 Received: from 133.75.70.115.static.exetel.com.au (HELO ext.crowie.net) (115.70.75.133) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jul 2015 12:14:41 -0000 Received: from [192.168.132.10] (vpn2.crowie.net [192.168.132.10]) by ext.crowie.net (8.14.7/8.14.7) with ESMTP id t6OCEXI0009540; Fri, 24 Jul 2015 22:14:34 +1000 Message-ID: <55B22C24.6010406@crowie.net> Date: Fri, 24 Jul 2015 22:14:28 +1000 From: G Crowe User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alan Lam , "xen-users@lists.xen.org" References: In-Reply-To: Subject: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: gcxenlist@crowie.net List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I installed the PV drivers in some windows PVs as I thought it would improve performance, but the systems then became painfully slow to use. I ran some tests on hard disc performance on a newly installed Win7 32 bit system before and after installing the PV drivers from univention.de (version 0.11.0.373) as the other sites appear to be offline. The host machine is running Fedora 21 with kernel 3.19.3. Without the PV drivers (with QEMU hardware) hard disc performance was 4409 I/O per second and 9.03Mbps. With the PV drivers installed this dropped to 207 I/O per second and 0.43Mbps. Without the PV drivers, the remote desktop screen would refresh almost instantly, but with the PV drivers it could take up to 10 seconds just to refresh the screen. I don't understand this, as I though that the sole purpose of the PV drivers was to improve I/O performance, yet they have made the system so slow that it is virtually unusable. Am I doing something wrong here? Thanks GC _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 24 12:15:45 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 12:15:45 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbsB-0004Vo-SV; Fri, 24 Jul 2015 12:14:43 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIbsA-0004Vc-Og for xen-users@lists.xen.org; Fri, 24 Jul 2015 12:14:42 +0000 Received: from [85.158.139.211] by server-5.bemta-5.messagelabs.com id 3F/67-21947-23C22B55; Fri, 24 Jul 2015 12:14:42 +0000 X-Env-Sender: gcxenlist@crowie.net X-Msg-Ref: server-2.tower-206.messagelabs.com!1437740078!23412547!1 X-Originating-IP: [115.70.75.133] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7556 invoked from network); 24 Jul 2015 12:14:41 -0000 Received: from 133.75.70.115.static.exetel.com.au (HELO ext.crowie.net) (115.70.75.133) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jul 2015 12:14:41 -0000 Received: from [192.168.132.10] (vpn2.crowie.net [192.168.132.10]) by ext.crowie.net (8.14.7/8.14.7) with ESMTP id t6OCEXI0009540; Fri, 24 Jul 2015 22:14:34 +1000 Message-ID: <55B22C24.6010406@crowie.net> Date: Fri, 24 Jul 2015 22:14:28 +1000 From: G Crowe User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Alan Lam , "xen-users@lists.xen.org" References: In-Reply-To: Subject: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: gcxenlist@crowie.net List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org I installed the PV drivers in some windows PVs as I thought it would improve performance, but the systems then became painfully slow to use. I ran some tests on hard disc performance on a newly installed Win7 32 bit system before and after installing the PV drivers from univention.de (version 0.11.0.373) as the other sites appear to be offline. The host machine is running Fedora 21 with kernel 3.19.3. Without the PV drivers (with QEMU hardware) hard disc performance was 4409 I/O per second and 9.03Mbps. With the PV drivers installed this dropped to 207 I/O per second and 0.43Mbps. Without the PV drivers, the remote desktop screen would refresh almost instantly, but with the PV drivers it could take up to 10 seconds just to refresh the screen. I don't understand this, as I though that the sole purpose of the PV drivers was to improve I/O performance, yet they have made the system so slow that it is virtually unusable. Am I doing something wrong here? Thanks GC _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 24 13:36:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 13:36:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZId8S-00082M-76; Fri, 24 Jul 2015 13:35:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZId8Q-00082D-Nz for xen-users@lists.xen.org; Fri, 24 Jul 2015 13:35:34 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 7B/1E-32406-62F32B55; Fri, 24 Jul 2015 13:35:34 +0000 X-Env-Sender: prvs=6401e7af6=Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1437744931!28956680!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13650 invoked from network); 24 Jul 2015 13:35:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 13:35:32 -0000 X-IronPort-AV: E=Sophos;i="5.15,538,1432598400"; d="scan'208";a="287266845" Message-ID: <1437744928.24746.96.camel@citrix.com> From: Ian Campbell To: , Alan Lam , "xen-users@lists.xen.org" Date: Fri, 24 Jul 2015 14:35:28 +0100 In-Reply-To: <55B22C24.6010406@crowie.net> References: <55B22C24.6010406@crowie.net> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: > I installed the PV drivers in some windows PVs as I thought it would > improve performance, but the systems then became painfully slow to use. > > I ran some tests on hard disc performance on a newly installed Win7 32 > bit system before and after installing the PV drivers from univention.de > (version 0.11.0.373) as the other sites appear to be offline. The host > machine is running Fedora 21 with kernel 3.19.3. > Without the PV drivers (with QEMU hardware) hard disc performance was > 4409 I/O per second and 9.03Mbps. > With the PV drivers installed this dropped to 207 I/O per second and > 0.43Mbps. > > Without the PV drivers, the remote desktop screen would refresh almost > instantly, but with the PV drivers it could take up to 10 seconds just > to refresh the screen. > > I don't understand this, as I though that the sole purpose of the PV > drivers was to improve I/O performance, Your expectation here is correct. > yet they have made the system so > slow that it is virtually unusable. > > Am I doing something wrong here? It seems unlikely, I don't think there is much you can have done wrong, it's supposed to just work ;-) more likely some sort of bad interaction between some (possibly buggy) component and another. I don't know much about the Windows PV drivers, so hopefully someone else can chip in with some tips/knowledge. Seeing your guest cfg file and any relevant logs from /var/log/xen might have some sort of clue. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 24 13:36:33 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 13:36:33 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZId8S-00082M-76; Fri, 24 Jul 2015 13:35:36 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZId8Q-00082D-Nz for xen-users@lists.xen.org; Fri, 24 Jul 2015 13:35:34 +0000 Received: from [85.158.137.68] by server-4.bemta-3.messagelabs.com id 7B/1E-32406-62F32B55; Fri, 24 Jul 2015 13:35:34 +0000 X-Env-Sender: prvs=6401e7af6=Ian.Campbell@citrix.com X-Msg-Ref: server-10.tower-31.messagelabs.com!1437744931!28956680!1 X-Originating-IP: [66.165.176.63] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogNjYuMTY1LjE3Ni42MyA9PiAzMDYwNDg=\n, received_headers: No Received headers X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13650 invoked from network); 24 Jul 2015 13:35:32 -0000 Received: from smtp02.citrix.com (HELO SMTP02.CITRIX.COM) (66.165.176.63) by server-10.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 13:35:32 -0000 X-IronPort-AV: E=Sophos;i="5.15,538,1432598400"; d="scan'208";a="287266845" Message-ID: <1437744928.24746.96.camel@citrix.com> From: Ian Campbell To: , Alan Lam , "xen-users@lists.xen.org" Date: Fri, 24 Jul 2015 14:35:28 +0100 In-Reply-To: <55B22C24.6010406@crowie.net> References: <55B22C24.6010406@crowie.net> X-Mailer: Evolution 3.16.3-1 MIME-Version: 1.0 X-DLP: MIA2 Subject: Re: [Xen-users] Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: > I installed the PV drivers in some windows PVs as I thought it would > improve performance, but the systems then became painfully slow to use. > > I ran some tests on hard disc performance on a newly installed Win7 32 > bit system before and after installing the PV drivers from univention.de > (version 0.11.0.373) as the other sites appear to be offline. The host > machine is running Fedora 21 with kernel 3.19.3. > Without the PV drivers (with QEMU hardware) hard disc performance was > 4409 I/O per second and 9.03Mbps. > With the PV drivers installed this dropped to 207 I/O per second and > 0.43Mbps. > > Without the PV drivers, the remote desktop screen would refresh almost > instantly, but with the PV drivers it could take up to 10 seconds just > to refresh the screen. > > I don't understand this, as I though that the sole purpose of the PV > drivers was to improve I/O performance, Your expectation here is correct. > yet they have made the system so > slow that it is virtually unusable. > > Am I doing something wrong here? It seems unlikely, I don't think there is much you can have done wrong, it's supposed to just work ;-) more likely some sort of bad interaction between some (possibly buggy) component and another. I don't know much about the Windows PV drivers, so hopefully someone else can chip in with some tips/knowledge. Seeing your guest cfg file and any relevant logs from /var/log/xen might have some sort of clue. Ian. _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users From xen-users-bounces@lists.xen.org Fri Jul 24 14:29:22 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 14:29:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIdxP-0007Qi-CX; Fri, 24 Jul 2015 14:28:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIdxO-0007Qd-Bq for xen-users@lists.xen.org; Fri, 24 Jul 2015 14:28:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id D4/59-03496-D7B42B55; Fri, 24 Jul 2015 14:28:13 +0000 X-Env-Sender: ghormoon@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1437748092!28979904!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29672 invoked from network); 24 Jul 2015 14:28:12 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 14:28:12 -0000 Received: by wibxm9 with SMTP id xm9so30495386wib.1 for ; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TXo16DutwUIccLdFxkoliNwq6EEPS6BQJe2SxsdyM70=; b=Qc14Llu+5bYmdT5J2jDkOS1uR1zwnOTbd5h8sPI/uY5EaHFF+wWhLYqB1bDpxdSj5O HzpknjADn9aPybLVYHlR8ycOVrEgX0ImA3tzxKAt/Ouc5BxUrgewYor3pgC23yw7dFn7 meYPRge0a78ZGTGaVVjGNW1rPfBmHsZVWUUy+K9ISY3lwIs/k6PW4sLpvZ98Vmw/o6HA 6l6vVK20sSuAJlk+jeTffVsrO1EHMBgSRRnPn20C9joThTHcC8QvGY0Mt+ZNE1gB7Kas 7grgsTrUt/HICuOZCwhIEt8tPWDkDqQodSbuDE992wXsMcytR8DlBISZ+iEWLYoRKuSc bb6g== MIME-Version: 1.0 X-Received: by 10.180.24.40 with SMTP id r8mr8201528wif.13.1437748092327; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) Received: by 10.28.154.7 with HTTP; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) Received: by 10.28.154.7 with HTTP; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) In-Reply-To: References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> Date: Fri, 24 Jul 2015 16:28:12 +0200 Message-ID: From: Ghormoon To: xen-users@lists.xen.org Subject: [Xen-users] Fwd: Re: Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1226858966363686421==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1226858966363686421== Content-Type: multipart/alternative; boundary=f46d043c805a51de60051b9fd00d --f46d043c805a51de60051b9fd00d Content-Type: text/plain; charset=UTF-8 Sorry to Ian, I didn't notice my phone decided to send it as pm only, resending to the list. > Hi, > Not sure if this may help, but when I've tried installing pv drivers like a year back and it happened to me, that the windows machine updated at the same time. That went seriosly bad. > When i've restored older snapshot, updated it, rebooted, installed pv, rebooted again, it went flawlessly. (I've been using rdesktop to access kit most time). > If you have the option of retrying from snapshot, give it a shot and check. I was not able to fix the machine by uninstalling/reinstalling them back then. Too bad I likely don't have that old log to compare. > Regards, > Ghor > > On Jul 24, 2015 3:39 PM, "Ian Campbell" wrote: >> >> On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: >> > I installed the PV drivers in some windows PVs as I thought it would >> > improve performance, but the systems then became painfully slow to use. >> > >> > I ran some tests on hard disc performance on a newly installed Win7 32 >> > bit system before and after installing the PV drivers from univention.de >> >> > (version 0.11.0.373) as the other sites appear to be offline. The host >> > machine is running Fedora 21 with kernel 3.19.3. >> > Without the PV drivers (with QEMU hardware) hard disc performance was >> > 4409 I/O per second and 9.03Mbps. >> > With the PV drivers installed this dropped to 207 I/O per second and >> > 0.43Mbps. >> > >> > Without the PV drivers, the remote desktop screen would refresh almost >> > instantly, but with the PV drivers it could take up to 10 seconds just >> > to refresh the screen. >> > >> > I don't understand this, as I though that the sole purpose of the PV >> > drivers was to improve I/O performance, >> >> Your expectation here is correct. >> >> > yet they have made the system so >> > slow that it is virtually unusable. >> > >> > Am I doing something wrong here? >> >> It seems unlikely, I don't think there is much you can have done wrong, >> it's supposed to just work ;-) more likely some sort of bad interaction >> between some (possibly buggy) component and another. >> >> I don't know much about the Windows PV drivers, so hopefully someone else >> can chip in with some tips/knowledge. >> >> Seeing your guest cfg file and any relevant logs from /var/log/xen might >> have some sort of clue. >> >> Ian. >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users --f46d043c805a51de60051b9fd00d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry to Ian, I didn't notice my phone decided to send i= t as pm only, resending to the list.
> Hi,
> Not sure if this may help, but when I've tried installing pv drive= rs like a year back and it happened to me, that the windows machine updated= at the same time. That went seriosly bad.
> When i've restored older snapshot, updated it, rebooted, installed= pv, rebooted again, it went flawlessly. (I've been using rdesktop to a= ccess kit most time).
> If you have the option of retrying from snapshot, give it a shot and c= heck. I was not able to fix the machine by uninstalling/reinstalling them b= ack then. Too bad I likely don't have that old log to compare.
> Regards,
> Ghor
>
> On Jul 24, 2015 3:39 PM, "Ian Campbell" <ian.campbell@citrix.com> wrote:
>>
>> On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote:
>> > I installed the PV drivers in some windows PVs as I thought i= t would
>> > improve performance, but the systems then became painfully sl= ow to use.
>> >
>> > I ran some tests on hard disc performance on a newly installe= d Win7 32
>> > bit system before and after installing the PV drivers from univention.de
>>
>> > (version 0.11.0.373) as the other sites appear to be offline.= The host
>> > machine is running Fedora 21 with kernel 3.19.3.
>> > Without the PV drivers (with QEMU hardware) hard disc perform= ance was
>> > 4409 I/O per second and 9.03Mbps.
>> > With the PV drivers installed this dropped to 207 I/O per sec= ond and
>> > 0.43Mbps.
>> >
>> > Without the PV drivers, the remote desktop screen would refre= sh almost
>> > instantly, but with the PV drivers it could take up to 10 sec= onds just
>> > to refresh the screen.
>> >
>> > I don't understand this, as I though that the sole purpos= e of the PV
>> > drivers was to improve I/O performance,
>>
>> Your expectation here is correct.
>>
>> >=C2=A0 yet they have made the system so
>> > slow that it is virtually unusable.
>> >
>> > Am I doing something wrong here?
>>
>> It seems unlikely, I don't think there is much you can have do= ne wrong,
>> it's supposed to just work ;-) more likely some sort of bad in= teraction
>> between some (possibly buggy) component and another.
>>
>> I don't know much about the Windows PV drivers, so hopefully s= omeone else
>> can chip in with some tips/knowledge.
>>
>> Seeing your guest cfg file and any relevant logs from /var/log/xen= might
>> have some sort of clue.
>>
>> Ian.
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org=
>> http://lists.xen.org/xe= n-users

--f46d043c805a51de60051b9fd00d-- --===============1226858966363686421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1226858966363686421==-- From xen-users-bounces@lists.xen.org Fri Jul 24 14:29:22 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Fri, 24 Jul 2015 14:29:22 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIdxP-0007Qi-CX; Fri, 24 Jul 2015 14:28:15 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZIdxO-0007Qd-Bq for xen-users@lists.xen.org; Fri, 24 Jul 2015 14:28:14 +0000 Received: from [85.158.137.68] by server-5.bemta-3.messagelabs.com id D4/59-03496-D7B42B55; Fri, 24 Jul 2015 14:28:13 +0000 X-Env-Sender: ghormoon@gmail.com X-Msg-Ref: server-2.tower-31.messagelabs.com!1437748092!28979904!1 X-Originating-IP: [209.85.212.170] X-SpamReason: No, hits=1.7 required=7.0 tests=BODY_RANDOM_LONG, HTML_20_30,HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29672 invoked from network); 24 Jul 2015 14:28:12 -0000 Received: from mail-wi0-f170.google.com (HELO mail-wi0-f170.google.com) (209.85.212.170) by server-2.tower-31.messagelabs.com with RC4-SHA encrypted SMTP; 24 Jul 2015 14:28:12 -0000 Received: by wibxm9 with SMTP id xm9so30495386wib.1 for ; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TXo16DutwUIccLdFxkoliNwq6EEPS6BQJe2SxsdyM70=; b=Qc14Llu+5bYmdT5J2jDkOS1uR1zwnOTbd5h8sPI/uY5EaHFF+wWhLYqB1bDpxdSj5O HzpknjADn9aPybLVYHlR8ycOVrEgX0ImA3tzxKAt/Ouc5BxUrgewYor3pgC23yw7dFn7 meYPRge0a78ZGTGaVVjGNW1rPfBmHsZVWUUy+K9ISY3lwIs/k6PW4sLpvZ98Vmw/o6HA 6l6vVK20sSuAJlk+jeTffVsrO1EHMBgSRRnPn20C9joThTHcC8QvGY0Mt+ZNE1gB7Kas 7grgsTrUt/HICuOZCwhIEt8tPWDkDqQodSbuDE992wXsMcytR8DlBISZ+iEWLYoRKuSc bb6g== MIME-Version: 1.0 X-Received: by 10.180.24.40 with SMTP id r8mr8201528wif.13.1437748092327; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) Received: by 10.28.154.7 with HTTP; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) Received: by 10.28.154.7 with HTTP; Fri, 24 Jul 2015 07:28:12 -0700 (PDT) In-Reply-To: References: <55B22C24.6010406@crowie.net> <1437744928.24746.96.camel@citrix.com> Date: Fri, 24 Jul 2015 16:28:12 +0200 Message-ID: From: Ghormoon To: xen-users@lists.xen.org Subject: [Xen-users] Fwd: Re: Windows PV drivers destroying performance X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1226858966363686421==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============1226858966363686421== Content-Type: multipart/alternative; boundary=f46d043c805a51de60051b9fd00d --f46d043c805a51de60051b9fd00d Content-Type: text/plain; charset=UTF-8 Sorry to Ian, I didn't notice my phone decided to send it as pm only, resending to the list. > Hi, > Not sure if this may help, but when I've tried installing pv drivers like a year back and it happened to me, that the windows machine updated at the same time. That went seriosly bad. > When i've restored older snapshot, updated it, rebooted, installed pv, rebooted again, it went flawlessly. (I've been using rdesktop to access kit most time). > If you have the option of retrying from snapshot, give it a shot and check. I was not able to fix the machine by uninstalling/reinstalling them back then. Too bad I likely don't have that old log to compare. > Regards, > Ghor > > On Jul 24, 2015 3:39 PM, "Ian Campbell" wrote: >> >> On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote: >> > I installed the PV drivers in some windows PVs as I thought it would >> > improve performance, but the systems then became painfully slow to use. >> > >> > I ran some tests on hard disc performance on a newly installed Win7 32 >> > bit system before and after installing the PV drivers from univention.de >> >> > (version 0.11.0.373) as the other sites appear to be offline. The host >> > machine is running Fedora 21 with kernel 3.19.3. >> > Without the PV drivers (with QEMU hardware) hard disc performance was >> > 4409 I/O per second and 9.03Mbps. >> > With the PV drivers installed this dropped to 207 I/O per second and >> > 0.43Mbps. >> > >> > Without the PV drivers, the remote desktop screen would refresh almost >> > instantly, but with the PV drivers it could take up to 10 seconds just >> > to refresh the screen. >> > >> > I don't understand this, as I though that the sole purpose of the PV >> > drivers was to improve I/O performance, >> >> Your expectation here is correct. >> >> > yet they have made the system so >> > slow that it is virtually unusable. >> > >> > Am I doing something wrong here? >> >> It seems unlikely, I don't think there is much you can have done wrong, >> it's supposed to just work ;-) more likely some sort of bad interaction >> between some (possibly buggy) component and another. >> >> I don't know much about the Windows PV drivers, so hopefully someone else >> can chip in with some tips/knowledge. >> >> Seeing your guest cfg file and any relevant logs from /var/log/xen might >> have some sort of clue. >> >> Ian. >> >> _______________________________________________ >> Xen-users mailing list >> Xen-users@lists.xen.org >> http://lists.xen.org/xen-users --f46d043c805a51de60051b9fd00d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Sorry to Ian, I didn't notice my phone decided to send i= t as pm only, resending to the list.
> Hi,
> Not sure if this may help, but when I've tried installing pv drive= rs like a year back and it happened to me, that the windows machine updated= at the same time. That went seriosly bad.
> When i've restored older snapshot, updated it, rebooted, installed= pv, rebooted again, it went flawlessly. (I've been using rdesktop to a= ccess kit most time).
> If you have the option of retrying from snapshot, give it a shot and c= heck. I was not able to fix the machine by uninstalling/reinstalling them b= ack then. Too bad I likely don't have that old log to compare.
> Regards,
> Ghor
>
> On Jul 24, 2015 3:39 PM, "Ian Campbell" <ian.campbell@citrix.com> wrote:
>>
>> On Fri, 2015-07-24 at 22:14 +1000, G Crowe wrote:
>> > I installed the PV drivers in some windows PVs as I thought i= t would
>> > improve performance, but the systems then became painfully sl= ow to use.
>> >
>> > I ran some tests on hard disc performance on a newly installe= d Win7 32
>> > bit system before and after installing the PV drivers from univention.de
>>
>> > (version 0.11.0.373) as the other sites appear to be offline.= The host
>> > machine is running Fedora 21 with kernel 3.19.3.
>> > Without the PV drivers (with QEMU hardware) hard disc perform= ance was
>> > 4409 I/O per second and 9.03Mbps.
>> > With the PV drivers installed this dropped to 207 I/O per sec= ond and
>> > 0.43Mbps.
>> >
>> > Without the PV drivers, the remote desktop screen would refre= sh almost
>> > instantly, but with the PV drivers it could take up to 10 sec= onds just
>> > to refresh the screen.
>> >
>> > I don't understand this, as I though that the sole purpos= e of the PV
>> > drivers was to improve I/O performance,
>>
>> Your expectation here is correct.
>>
>> >=C2=A0 yet they have made the system so
>> > slow that it is virtually unusable.
>> >
>> > Am I doing something wrong here?
>>
>> It seems unlikely, I don't think there is much you can have do= ne wrong,
>> it's supposed to just work ;-) more likely some sort of bad in= teraction
>> between some (possibly buggy) component and another.
>>
>> I don't know much about the Windows PV drivers, so hopefully s= omeone else
>> can chip in with some tips/knowledge.
>>
>> Seeing your guest cfg file and any relevant logs from /var/log/xen= might
>> have some sort of clue.
>>
>> Ian.
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@lists.xen.org=
>> http://lists.xen.org/xe= n-users

--f46d043c805a51de60051b9fd00d-- --===============1226858966363686421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============1226858966363686421==-- From xen-users-bounces@lists.xen.org Sat Jul 25 01:03:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 01:03:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZInqY-0002Sz-BT; Sat, 25 Jul 2015 01:01:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZInqX-0002DE-5U for xen-users@lists.xen.org; Sat, 25 Jul 2015 01:01:49 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 69/A3-20690-CFFD2B55; Sat, 25 Jul 2015 01:01:48 +0000 X-Env-Sender: tlviewer@yahoo.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437786106!18122090!1 X-Originating-IP: [216.109.115.174] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6015 invoked from network); 25 Jul 2015 01:01:47 -0000 Received: from nm48-vm7.bullet.mail.bf1.yahoo.com (HELO nm48-vm7.bullet.mail.bf1.yahoo.com) (216.109.115.174) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Jul 2015 01:01:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437786106; bh=tHoeZE+MqV9mx/LMgquXzOxIeojM/vBGUFCgukRn/Sg=; h=Date:From:Reply-To:To:Subject:From:Subject; b=qGUSYOuMzU9a8MKnlMQJhZq8YWemRckWaQE0w2l6UTK8pgfM0I5oip3aP4YlNQ427hRZnvoyxVLFeSBOm6hTYQNtzk5EytsgHB9gWAWZdlU4Yr/IDV3P9kLR/f2rZOZE8QoUygX0L+uV+Tr1n5D1UYRpYDKSnOadWr185IlFIbFC66kQYLymrbnmxWLGK8cSTxpqWsrmpNivlvW8PvogCHUH5HQi0t1NDBpKMcF/urozjh/zt+I/thKFySsnMOS88VvMGWzxO3gwDo07xnr0GKcBz71yQUhK85ok70x1ajP2wU7eLrTQWPP0tcJuyBDawEXzJlLKNu6XsnjaW7otxQ== Received: from [66.196.81.172] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 Received: from [98.139.212.192] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 191984.20491.bm@omp1001.mail.bf1.yahoo.com X-YMail-OSG: xsMQ_KYVM1lmR0W.7A.3zwd._Q_bC.FMDS0fIlSuh7K_Hn5Mlh0pFwd4EjJeiw1 BGLPdYlhCE7bgGxrWXy9ltkqaY1VdM1UNA3Lfijsi9Z833M9Gq7mPnZn2qnrsTM7CA0A6GI1CUnG wWqQV3LwyxlebWbYC1Wryy5U4W.Ma0mFGbKidjnelIeMtT6r7hTSopUzlczEubI4xAL_GJacYM7u dSJsPcjIjhJjLQEqdI09ETstD9h1P.TojtAKN05pP0zyHEYixtNZ_8ZMazm_bTbC1C81tqy0tf73 zgn0aRnyHS0k4XfO9bV8IWcVV1IQDgkfp05hogIB_ew86h3XR3VJh1WNsww9z.c7eAtsjOJntFhY r1RvdLMHarnTrI1yR5pUCKUWmcMPBM6Wzno4GOAHJRSpL81Gr0No0K8JOWbw0bvIkAf55cLyU10w Z_fapJuoyPGgpXmI0lrTXDHFbFKOY4pbpvoPOJYMgogcaP7mFPJjT6bWpcH3BOYws9JspQGbWv8I Z2FE7SJ4- Received: by 76.13.27.55; Sat, 25 Jul 2015 01:01:45 +0000 Date: Sat, 25 Jul 2015 01:01:45 +0000 (UTC) From: Mark Pryor To: Xen-users Message-ID: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 2181 Subject: [Xen-users] Request backport from staging to stable-4.5 2d70c9ce79d0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Mark Pryor List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4110564550285854196==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4110564550285854196== Content-Type: multipart/alternative; boundary="----=_Part_2317774_1210723736.1437786105532" Content-Length: 1693 ------=_Part_2317774_1210723736.1437786105532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Xen, git checkout staging git show 2d70c9ce79d0 --format=fuller the above patch will fix the linking errors when building xen-4.5.x in Vivid 15.04 with systemd & ocamltools support. Please backport this patch to stable-4.5 cheers,PryMar56 ------=_Part_2317774_1210723736.1437786105532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Xen,

git checkout staging
= git show 2d70c9ce79d0 --format=3Dfuller

the above patch will fix the linking errors when building xen= -4.5.x in Vivid 15.04 with
systemd & ocamlto= ols support.
<= br>
Please bac= kport this patch to stable-4.5

cheers,
PryMar56


<= div id=3D"yui_3_16_0_1_1437785864286_4779">
------=_Part_2317774_1210723736.1437786105532-- --===============4110564550285854196== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users --===============4110564550285854196==-- From xen-users-bounces@lists.xen.org Sat Jul 25 01:03:04 2015 Return-path: Envelope-to: archives@lists.xen.org Delivery-date: Sat, 25 Jul 2015 01:03:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZInqY-0002Sz-BT; Sat, 25 Jul 2015 01:01:50 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZInqX-0002DE-5U for xen-users@lists.xen.org; Sat, 25 Jul 2015 01:01:49 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 69/A3-20690-CFFD2B55; Sat, 25 Jul 2015 01:01:48 +0000 X-Env-Sender: tlviewer@yahoo.com X-Msg-Ref: server-14.tower-206.messagelabs.com!1437786106!18122090!1 X-Originating-IP: [216.109.115.174] X-SpamReason: No, hits=0.9 required=7.0 tests=FORGED_YAHOO_RCVD, HTML_MESSAGE,RCVD_BY_IP X-StarScan-Received: X-StarScan-Version: 6.13.16; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6015 invoked from network); 25 Jul 2015 01:01:47 -0000 Received: from nm48-vm7.bullet.mail.bf1.yahoo.com (HELO nm48-vm7.bullet.mail.bf1.yahoo.com) (216.109.115.174) by server-14.tower-206.messagelabs.com with RC4-SHA encrypted SMTP; 25 Jul 2015 01:01:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1437786106; bh=tHoeZE+MqV9mx/LMgquXzOxIeojM/vBGUFCgukRn/Sg=; h=Date:From:Reply-To:To:Subject:From:Subject; b=qGUSYOuMzU9a8MKnlMQJhZq8YWemRckWaQE0w2l6UTK8pgfM0I5oip3aP4YlNQ427hRZnvoyxVLFeSBOm6hTYQNtzk5EytsgHB9gWAWZdlU4Yr/IDV3P9kLR/f2rZOZE8QoUygX0L+uV+Tr1n5D1UYRpYDKSnOadWr185IlFIbFC66kQYLymrbnmxWLGK8cSTxpqWsrmpNivlvW8PvogCHUH5HQi0t1NDBpKMcF/urozjh/zt+I/thKFySsnMOS88VvMGWzxO3gwDo07xnr0GKcBz71yQUhK85ok70x1ajP2wU7eLrTQWPP0tcJuyBDawEXzJlLKNu6XsnjaW7otxQ== Received: from [66.196.81.172] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 Received: from [98.139.212.192] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 Received: from [127.0.0.1] by omp1001.mail.bf1.yahoo.com with NNFMP; 25 Jul 2015 01:01:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 191984.20491.bm@omp1001.mail.bf1.yahoo.com X-YMail-OSG: xsMQ_KYVM1lmR0W.7A.3zwd._Q_bC.FMDS0fIlSuh7K_Hn5Mlh0pFwd4EjJeiw1 BGLPdYlhCE7bgGxrWXy9ltkqaY1VdM1UNA3Lfijsi9Z833M9Gq7mPnZn2qnrsTM7CA0A6GI1CUnG wWqQV3LwyxlebWbYC1Wryy5U4W.Ma0mFGbKidjnelIeMtT6r7hTSopUzlczEubI4xAL_GJacYM7u dSJsPcjIjhJjLQEqdI09ETstD9h1P.TojtAKN05pP0zyHEYixtNZ_8ZMazm_bTbC1C81tqy0tf73 zgn0aRnyHS0k4XfO9bV8IWcVV1IQDgkfp05hogIB_ew86h3XR3VJh1WNsww9z.c7eAtsjOJntFhY r1RvdLMHarnTrI1yR5pUCKUWmcMPBM6Wzno4GOAHJRSpL81Gr0No0K8JOWbw0bvIkAf55cLyU10w Z_fapJuoyPGgpXmI0lrTXDHFbFKOY4pbpvoPOJYMgogcaP7mFPJjT6bWpcH3BOYws9JspQGbWv8I Z2FE7SJ4- Received: by 76.13.27.55; Sat, 25 Jul 2015 01:01:45 +0000 Date: Sat, 25 Jul 2015 01:01:45 +0000 (UTC) From: Mark Pryor To: Xen-users Message-ID: <1548443333.2317775.1437786105535.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Length: 2181 Subject: [Xen-users] Request backport from staging to stable-4.5 2d70c9ce79d0 X-BeenThere: xen-users@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Mark Pryor List-Id: Xen user discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4110564550285854196==" Sender: xen-users-bounces@lists.xen.org Errors-To: xen-users-bounces@lists.xen.org --===============4110564550285854196== Content-Type: multipart/alternative; boundary="----=_Part_2317774_1210723736.1437786105532" Content-Length: 1693 ------=_Part_2317774_1210723736.1437786105532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Xen, git checkout staging git show 2d70c9ce79d0 --format=fuller the above patch will fix the linking errors when building xen-4.5.x in Vivid 15.04 with systemd & ocamltools support. Please backport this patch to stable-4.5 cheers,PryMar56 ------=_Part_2317774_1210723736.1437786105532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Xen,

git checkout staging
= git show 2d70c9ce79d0 --format=3Dfuller

the above patch will fix the linking errors when building xen= -4.5.x in Vivid 15.04 with
systemd & ocamlto= ols support.
<= br>
Please bac= kport this patch to stable-4.5

cheers,
PryMar56


<= div id=3D"yui_3_16_0_1_1437785864286_4779">